This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

classification
Title: posix.readlink doesn't use filesystemencoding
Type: Stage:
Components: Extension Modules Versions: Python 2.6
process
Status: closed Resolution: accepted
Dependencies: Superseder:
Assigned To: ronaldoussoren Nosy List: georg.brandl, loewis, ronaldoussoren
Priority: normal Keywords: patch

Created on 2006-10-19 17:12 by ronaldoussoren, last changed 2022-04-11 14:56 by admin. This issue is now closed.

Files
File name Uploaded Description Edit
readlink.patch ronaldoussoren, 2006-10-19 17:12
readlink2.patch ronaldoussoren, 2006-10-22 09:29 Updated patch
Messages (8)
msg51266 - (view) Author: Ronald Oussoren (ronaldoussoren) * (Python committer) Date: 2006-10-19 17:12
Unlink most (all?) other functions in posixmodule posix.readlink doesn't 
encode unicode arguments using the default filesystem encoding but 
using the default system encoding.

This patch files that. The reason I haven't  applied this yet is that this 
patch also changes the return type: if the argument of readlink is a 
unicode string the result will also be one, just like with os.listdir.

msg51267 - (view) Author: Martin v. Löwis (loewis) * (Python committer) Date: 2006-10-20 07:56
Logged In: YES 
user_id=21627

The patch looks right in principle (although the duplicate
parsing seems overkill; checking whether the first tuple
element (if any) is a Unicode object should do just as well).

The change in return type still needs to be documented,
though (with \versionchanged).
msg51268 - (view) Author: Ronald Oussoren (ronaldoussoren) * (Python committer) Date: 2006-10-20 08:50
Logged In: YES 
user_id=580910

The type check and unicode conversion of the result were copied from listdir.

I agree that calling PyArg_ParseTuple just to check if an argument is unicode 
is overkill. I'll change the check to a plain PyUnicode_Check of the first 
argument and add the documentation update.

BTW. Is this change valid for backporting to 2.5.1? The reason I looked into 
this is that os.path.realpath is broken when a unicode argument is used with 
non-ascii characters and there is a symlink during resolving the path.
msg51269 - (view) Author: Martin v. Löwis (loewis) * (Python committer) Date: 2006-10-20 17:48
Logged In: YES 
user_id=21627

This should be discussed on python-dev. I don't think the
change in return type should be backported - it has a real
chance of breaking applications (which suddenly start seeing
Unicode strings where none were before).

Always using the file system encoding (instead of the
default encoding) but leaving the return type might be
considered a bug fix. It also might be considered a new
feature: you can now do things you couldn't before.
msg51270 - (view) Author: Ronald Oussoren (ronaldoussoren) * (Python committer) Date: 2006-10-22 09:29
Logged In: YES 
user_id=580910

readlink2.patch cleans up the unicode check and adds a documentation update.
msg51271 - (view) Author: Martin v. Löwis (loewis) * (Python committer) Date: 2006-10-22 10:37
Logged In: YES 
user_id=21627

The patch is fine, please apply.
msg51272 - (view) Author: Ronald Oussoren (ronaldoussoren) * (Python committer) Date: 2006-10-22 10:46
Logged In: YES 
user_id=580910

Applied to the trunk in revision 52415.

I'm keeping this patch open while waiting for feedback on the backport question 
that I posted on python-dev.
msg51273 - (view) Author: Georg Brandl (georg.brandl) * (Python committer) Date: 2007-03-13 18:20
In light of the recent issue with glob.py, I think that this is better not backported to 2.5.

Closing now.
History
Date User Action Args
2022-04-11 14:56:20adminsetgithub: 44145
2006-10-19 17:12:01ronaldoussorencreate