[Python-Dev] a suggestion ... Re: PEP 383 (again) (original) (raw)

"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