[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(".")

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.


More information about the Python-Dev mailing list