[Martin von Lupsidedownquestionmarkwis] > This is the problem. Python source code is not in Latin-1; bytes; > inside strings and comments are "as-is". The latter is a platform-dependent accident -- the ref man says Python source is 7-bit ASCII, and that was the intent. That C's ctype functions later grew locale-dependent behavior accounts for why Python did too, but even according to the C standard you can't count on transporting C text-mode files across platforms unless they avoid that stuff. > 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. [Jack] > Is this an "official" policy? My policy is that Python source in the *distribution* adheres to the restrictions of the C std for C text-mode files, until such time as Python changes to read and write them in C binary mode, or stops using C stdio altogether. And that's as official as I am <wink>. > As such I disagree with it. Either all Python source should be 7-bit > clean or the source should be converted to the local convention, even > for strings and comments. But if it is an official policy I'd > like to hear it (who wants to channel Guido here?), because > there's heaps of MacPython stuff that'll have to be converted back > (I did the forward conversion a couple of months ago). Sorry, I don't know what "forward" and "back" mean to you.
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