martin at v
Oct 7, 2008, 1:06 PM
Post #1 of 4
(159 views)
Permalink
|
|
Python3UnicodeDecodeError (Was: Proposed Python 3.0 schedule)
|
|
> First of all, please read my document:
> http://wiki.python.org/moin/Python3UnicodeDecodeError
I have problems understanding that document. Is it supposed to
be a PEP (i.e. a proposal to enhance Python), or is it a description
of the status quo?
If it is a PEP, it should clearly separate status quo, specification,
and rationale (in any order that you find reasonable). It should also
have an "open issues" section, explicitly listing the questions that
haven't been resolved, and it should record objections to the proposal.
I think I would object to the specification (perhaps to the degree
of proposing a counter-PEP), but to do so, I first need a specification
to object to.
In terms of time-line, I think any such PEP is *clearly* out of scope
for Python 3.0. All the remaining issues should deferred to 3.1.
That the approach "we can use bytes in the file system API" was so
rushed into the code base is already unfortunate, but I can understand
the motivation - people want to write backup programs in Python.
If I take the text as if it was a specification, here are some of my
objections:
- Default encoding:
a) seems irrelevant for the PEP. The default encoding doesn't nearly
have the role anymore that it had in 2.x, and shouldn't have any
effect on how file names are treated.
b) I would propose that the notion of a default encoding is entirely
eliminated from Python, along with sys.(get|set)defaultencoding
- argv and environ: are you suggesting that the behavior described
in the PEP is desirable? I don't think it is (but I don't think it
should change for 3.0, either, only for 3.1)
Regards,
Martin
_______________________________________________
Python-Dev mailing list
Python-Dev[at]python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/list-python-dev%40lists.gossamer-threads.com
|
