[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 (Comment added) made by ronaldoussoren
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: None
Priority: 5
Submitted By: Ronald Oussoren (ronaldoussoren)
Assigned to: Nobody/Anonymous (nobody)
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: 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