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/)
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4