On 31/10/2011 8:39 AM, Victor Stinner wrote: > Le 29/10/2011 07:47, Mark Hammond a écrit : >> When previously discussing this issue, I was under the impression that >> the problem was unencodable bytes passed from the Python code to Windows >> - but the reverse is true - only the data coming back from Windows isn't >> encodable. > > The undecodable filenames issue occurs mostly on os.listdir(bytes) and > os.getcwdb(). > > Unencodable filenames issue occurs on the rest of my function list. > >> As the data came externally, the only solution the programmer >> has is to change to the unicode version of the api >> - so we recommend the bytes version not be used by anyone, >> anytime - which means it is conceptually deprecated already. > > I proposed to raise a Unicode error on undecodable filenames, instead of > returning invalid filenames (with question marks), to force the > developer to move to the Unicode API. But as I explained in my previous > message, you have to wait for an user having the problem to be noticied > of the problem. > > Terry J. Reedy is also concerned about backward compatibility (3.2 -> > 3.3). Emiting a warning, disabled by default, is a softer solution :-) Right - and just to be clear, we are all now agreeing that the UnicodeDecodeError isn't appropriate and a warning will be issued instead? > >> Therefore, as you imply, I think the solution to this issue is to start >> the process of deprecating the bytes version of the api in py3k with a >> view to removing it completely - possibly with a less aggressive >> timeline than normal. > > If there is a warning, I don't really care of removing the bytes API > before Python 4. Agreed - I was trying to say that I think we should start the deprecation process of the bytes API, so a [Pending]DeprecationWarning would then be appropriate. The actual timing of the removal isn't important. > > PendingDeprecationgWarning can be used, or maybe a DeprecationWarning > mentioning that the code will stay for long time. > >> In Python 2.7, I think documenting the issue and a >> recommendation to always use unicode is sufficient (ie, we can't >> deprecate it and a new BytesWarning seems gratuitous.) > > Sorry, I don't understand "gratuitous" here: do you mean that a new > warning would annoying, and that it is cheap and useful to add it to > Python 2.7.x? I mean "Uncalled for; lacking good reason; unwarranted." IOW, I don't think we need to take any action for 2.7, apart from possibly documentation changes. Mark
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4