On 2/16/06, Paul Moore <[EMAIL PROTECTED]> wrote: > On 2/16/06, Guido van Rossum <[EMAIL PROTECTED]> wrote: > > On 2/16/06, Nick Coghlan <[EMAIL PROTECTED]> 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/) _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
