Issue 1580674: posix.readlink doesn't use filesystemencoding (original) (raw)

This issue has been migrated to GitHub: https://github.com/python/cpython/issues/44145

classification

process

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

Messages (8)
msg51266 - (view)	Author: Ronald Oussoren (ronaldoussoren) *	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) *	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) *	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) *	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) *	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) *	Date: 2006-10-22 10:37
Logged In: YES user_id=21627 The patch is fine, please apply.
msg51272 - (view)	Author: Ronald Oussoren (ronaldoussoren) *	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) *	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.