> > I think test_quopri is too latin-1 centric. > > Strictly speaking, there is nothing latin-1 centric in test_quopri.py > whatsoever. > > > For instance, on my Mac, Python source is in MacRoman encoding. CVS > > knows all about this, so it happily converts the > > latin-1-upsidedown-exclam to a macroman-upsidedown-exclam, and if I > > look at the source code I see the same glyph as I see on Unix. > > This is the problem. Python source code is not in Latin-1; bytes > inside strings and comments are "as-is". So the CVS "binary" mode > would come closer as to how python files should be treated, although > you'd still would want to convert line-endings. > > > I'm surprised the test doesn't fail on Windows as well, or do > > Windows pythonistas generally work with source in latin1? > > Most of these people probably use code page 1252, which is identical > to latin-1 except in the range 0x80 to 0x9f. > > For test_quopri.py, the best thing would be to replace the characters > outside range(128) to \x escaped ones, to avoid the problem with Mac > CVS (which really is the problem here - if you unpack Python from the > source distribution, the test should pass fine on your system). Well, exactly because Python source code is not in Latin-1, the test_quopri.py file is wrong IMO, because it uses non-ASCII characters. So please go ahead and change it into hex constants... (This doesn't occur on Windows because, I'm assuming, the Windows CVS client isn't as "smart" as the Mac CVS client.) --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