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

[SourceForge.net]

Patches item #1580674, was opened at 2006-10-19 17:12
Message generated for change (Comment added) made by gbrandl
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: Closed
Resolution: Accepted
Priority: 5
Private: No
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: Georg Brandl (gbrandl)
Date: 2007-03-13 18:20

Message:
Logged In: YES 
user_id=849994
Originator: NO

In light of the recent issue with glob.py, I think that this is better not
backported to 2.5.

Closing now.

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

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

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

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

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

Message:
Logged In: YES 
user_id=21627

The patch is fine, please apply.

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

Comment By: Ronald Oussoren (ronaldoussoren)
Date: 2006-10-22 09: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 17: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 08: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 07: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