[Python-Dev] a suggestion ... Re: PEP 383 (again)
"Martin v. Löwis"
martin at v.loewis.de
Thu Apr 30 07:17:38 CEST 2009
> I don't understand the proposal and issues. I see a lot of people
> claiming that they do, and then spending all their time either
> talking past each other, or disagreeing. If everyone who claims they
> understand the issues actually does, why is it so hard to reach a
> consensus?
Because the problem is difficult, and any solution has trade-offs.
People disagree on which trade-offs are worse than others.
> I'd like to see some real examples of how things can break in the
> current system
Suppose I create a new directory, and run the following script
in 3.x:
py> open("x","w").close()
py> open(b"\xff","w").close()
py> os.listdir(".")
['x']
If I quit Python, I can now do
martin at mira:~/work/3k/t$ ls
? x
martin at mira:~/work/3k/t$ ls -b
\377 x
As you can see, there are two files in the current directory, but
only one of them is reported by os.listdir. The same happens to
command line arguments and environment variables: Python might swallow
some of them.
> and I'd like any potential solution to be made
> available as a third-party package before it goes into the standard
> library (if possible).
Unfortunately, at least for my solution, this isn't possible. I need
to change the implementation of the existing file IO APIs.
> Currently, we're reduced to trying to predict
> the consequences of implementing the PEP, instead of being able to
> try it out and see.
In a sense, this is one of the primary points of the PEP process:
to discuss a specification before the effort to produce an
implementation is started.
> Even something like a test suite would be useful: here are a bunch of
> malformed file names, and this is what happens when you try to work
> with them. Please, let's see some code we can run, not more words.
Just try my example above, on a Linux system, in a UTF-8 locale.
Regards,
Martin
More information about the Python-Dev
mailing list