Reject bytearray filename in Python 3.2
Hi, About my work on unicode surrogates, I would like to reject bytearray filename, especially in the PyUnicode_FSConverter function. As explained in issue #8485, support bytearray requires to test the result type, acquire/release a lock, the API is more complex, etc. I don't know real world usecase of bytearray filename. The os.path module doesn't support it and no Python 3.0 or 3.1 user noticed that. Support of bytearray in not documentation in PyUnicode_FSConverter() comment (Include/unicodeobject.h). Martin Loewis, the author of PEP 383, created PyUnicode_FSConverter() and he agree to drop support of bytearray filename. But he asked me to ask on this mailing list if anyone would prefer to mark bytearray filename as deprecated in 3.2 and reject them in 3.3. I will be very sad if someone ask me to keep bytearray filename support in 3.2 because I opened a lot of issues about surrogates and I would make my work more diffcult :-( -- Victor Stinner http://www.haypocalc.com/
Victor Stinner wrote:
I will be very sad if someone ask me to keep bytearray filename support in 3.2 because I opened a lot of issues about surrogates and I would make my work more diffcult :-(
I don't have an opinion one way or the other regarding bytearray, but even if you deprecated it rather than dropping it, couldn't you just add the surrogate support for the Unicode path and leave the bytecode path with the legacy behaviour? Cheers, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia ---------------------------------------------------------------
Le jeudi 22 avril 2010 00:21:02, vous avez écrit :
Victor Stinner wrote:
I will be very sad if someone ask me to keep bytearray filename support in 3.2 because I opened a lot of issues about surrogates and I would make my work more diffcult :-(
I don't have an opinion one way or the other regarding bytearray, but even if you deprecated it rather than dropping it, couldn't you just add the surrogate support for the Unicode path and leave the bytecode path with the legacy behaviour?
Yes, we can do everything. But does it really have a sense? No Python function using filenames return a bytearray object. Example: os.listdir() and os.walk() result type is bytes or str. Changing PyUnicode_FSConverter() is trivial, but the problem is in the function calling PyUnicode_FSConverter(). The caller have to support byte and bytearray. Antoine proposed to convert bytearray to bytes to ensure that PyUnicode_FSConverter() result is a bytes object. But in this case, we still need also to fix ntpath, ,posixpath and macpath modules to support bytearray. -- Victor Stinner http://www.haypocalc.com/
Victor Stinner wrote:
Le jeudi 22 avril 2010 00:21:02, vous avez écrit :
I will be very sad if someone ask me to keep bytearray filename support in 3.2 because I opened a lot of issues about surrogates and I would make my work more diffcult :-( I don't have an opinion one way or the other regarding bytearray, but even if you deprecated it rather than dropping it, couldn't you just add
Victor Stinner wrote: the surrogate support for the Unicode path and leave the bytecode path with the legacy behaviour?
Yes, we can do everything. But does it really have a sense? No Python function using filenames return a bytearray object. Example: os.listdir() and os.walk() result type is bytes or str.
Oh, never mind then, I misunderstood the question ('bytearray' flipped to 'bytes' in my brain). I don't see the point in allowing a mutable argument either. Cheers, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia ---------------------------------------------------------------
participants (2)
-
Nick Coghlan
-
Victor Stinner