Greg Ewing writes: > I don't think of my viewpoint as being PBP. That term > assumes there is purity there to be beaten. To my mind, > any notion of purity with respect to bytes objects > went out the window as soon as it was given a pile > of text methods -- together with a text-like literal > syntax and default repr(), even though at least half > the time they're completely inappropriate! Isn't an analogous statement true of every programming language taken as a whole? Does that mean that, because Python 1 text handling was unavoidably "practical", adding the "purist" unicode type in Python 2 was a mistake? Python 3's sacrifice of Python 2 compatibility seems positively degenerate by your standard! To be less contentious, surely the concept of "purity" includes "purification" (even if that doesn't apply to some subdivisions of purity)? In any case, taking your statement at face value, I consider adding the methods to have been a mistake and the literal syntax and repr to be compact abbreviations that are frequently convenient. Byte sequences that can be considered to serializations of objects including ASCII text, so that some subsequences of bytes in the range 0-127 can be usefully considered as a text representation are very common. But I think that they're important enough that their representation in Python deserves a type (maybe more than one) that tries to enforce what regularities there are in such streams. The purity position is probably going to lose in the end, since Guido is clearly in the PBP camp at this point, and that's a strong indicator (especially since Nick has given up on convincing python-dev). But that does not mean it's entirely invalid.
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