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-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 _______________________________________________ Patches mailing list [email protected] http://mail.python.org/mailman/listinfo/patches
