[Python-Dev] Emit a BytesWarning on bytes filenames on Windows

Mark Hammond skippy.hammond at gmail.com
Mon Oct 31 03:51:28 CET 2011


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


More information about the Python-Dev mailing list