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
_______________________________________________
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
