[Python-Dev] PEP 338 issue finalisation (was Re: 2.5 PEP) (original) (raw)
Paul Moore p.f.moore at gmail.com
Thu Feb 16 16:39:30 CET 2006
- Previous message: [Python-Dev] PEP 338 issue finalisation (was Re: 2.5 PEP)
- Next message: [Python-Dev] PEP 338 issue finalisation (was Re: 2.5 PEP)
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
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 getdata(), 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.
Regardless, the PEP should be clarified. I'll make the change once agreement is reached.
Paul.
- Previous message: [Python-Dev] PEP 338 issue finalisation (was Re: 2.5 PEP)
- Next message: [Python-Dev] PEP 338 issue finalisation (was Re: 2.5 PEP)
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]