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 :-)

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.

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?

Victor
_______________________________________________
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Reply via email to