[Python-Dev] PEP 338 issue finalisation (was Re: 2.5 PEP)

[Guido van Rossum]

On 2/16/06, Paul Moore <p.f.moore at gmail.com> wrote:
> On 2/16/06, Guido van Rossum <guido at python.org> wrote:
> > On 2/16/06, Nick Coghlan <ncoghlan at gmail.com> wrote:
>
> > > The PEP itself requests that a string be returned from get_data(), but doesn't
> > > require that the file be opened in text mode. Perhaps the PEP 302 emulation
> > > should use binary mode here? Otherwise there could be strange data corruption
> > > bugs on Windows.
> >
> > But PEP 302 shows as its only example reading from a file with a .txt
> > extension. Adding spurious \r characters is also data corruption. We
> > should probably post to python-dev a request for clarification of PEP
> > 302, but in the mean time I vote for text mode.
>
> FWIW, the .txt example was just a toy example. I'd say that binary
> mode makes sense, as I can imagine using the get_data interface to
> load image files, for example. It makes getting text files a bit
> harder (you have to munge CRLF manually) but at least you have the
> *option* of getting binary files.
>
> On reflection, get_data should probably have been given a mode
> argument. But given that it didn't, binary seems safest.
>
> OTOH, I don't know who actually *uses* get_data for real (PJE, for
> eggs? py2exe?). Their opinions are likely to be of more importance.
>
> On the third hand, doing whatever the zipimport module does is likely
> to be right, as that's the key bit of prior art.

It doesn't do any CRLF -> LF translation so this supports the binary theory.

> Regardless, the PEP should be clarified. I'll make the change once
> agreement is reached.

Thanks. Based on the zipimport precedent I propose to make it binary.
The example could be changed to read a GIF image.

--
--Guido van Rossum (home page: http://www.python.org/~guido/)