Martin v. Löwis wrote: > M.-A. Lemburg wrote: > >> It is if you stick to writing your binary data using an ASCII >> compatible encoding -- I wouldn't expect any other encoding for >> binary data anyway. The most common are ASCII + escape sequences, >> base64 or hex, all of which are ASCII compatible. > > > We probably have a different notion of "ASCII compatible" then. > I would define it as: > > An encoding E is "ASCII compatbible" if strings that only consist > of ASCII characters use the same byte representation in E that > they use in ASCII. > > In that sense, ISO-8859-1 and UTF-8 are also ASCII compatible. Notice > that this is also the definition that PEP 263 assumes. Sorry, wrong wording on my part: I meant a string literal that only uses ASCII characters for the literal definition, i.e. literaldefinition.decode('ascii').encode('ascii') == literaldefinition. > However, byte strings used in source code are not "safe" if they > are encoded in ISO-8859-1 under recoding: If the source code is > converted to UTF-8 (including the encoding declaration), then > the length of the strings changes, as do the byte values inside > the string. Agreed. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Aug 17 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
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