[Patches] [ python-Patches-1580674 ] posix.readlink doesn't use filesystemencoding

[SourceForge.net]

Patches item #1580674, was opened at 2006-10-19 19:12
Message generated for change (Settings changed) made by loewis
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1580674&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Modules
Group: Python 2.6
Status: Open
Resolution: Accepted
Priority: 5
Submitted By: Ronald Oussoren (ronaldoussoren)
>Assigned to: Ronald Oussoren (ronaldoussoren)
Summary: posix.readlink doesn't use filesystemencoding

Initial Comment:
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.



----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2006-10-22 12:37

Message:
Logged In: YES 
user_id=21627

The patch is fine, please apply.

----------------------------------------------------------------------

Comment By: Ronald Oussoren (ronaldoussoren)
Date: 2006-10-22 11:29

Message:
Logged In: YES 
user_id=580910

readlink2.patch cleans up the unicode check and adds a documentation update.

----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2006-10-20 19:48

Message:
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.

----------------------------------------------------------------------

Comment By: Ronald Oussoren (ronaldoussoren)
Date: 2006-10-20 10:50

Message:
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.

----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2006-10-20 09:56

Message:
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).

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1580674&group_id=5470