Stephen J. Turnbull wrote: > Fredrik> PEP 263 implements the same model, minus UTF-16, and with > Fredrik> a two-phase implementation plan. >=20 > It does not. That wasn't an opinion, that was a statement of fact. If you don't understand this, you're either not understanding the PEP, the Python language specification (and how Python's parser and unicode system works in real life), the XML specification (and how XML parsers work in real life), or you're just trying to keep the argument going. Try resetting your brain, study my statement and Martin's reply = carefully, and then read everything in the PEP *except* for the implementation section. If necessary, check the Python language reference as well. When you do get it, please tell us what we need to clarify. Arguing that if you don't get it, it has to be *conceptually* wrong, won't get us anywhere. (as googling for "mule is evil" or "naggum on mule" shows, you should know this from your work on emacs). > True. But the historical antecedent for PEP 263 is much closer to > Emacs/Mule That's a strange statement, given that most about everyone involved in what led up to the PEP qualify as XML experts, and I don't think any = of them has been involved in Mule. > which comes down on the PEP 263 side of both the issues > identified above, than to XML. I know XML's encoding model well (and the same goes for everyone = involved in what led up to the PEP), and I see nothing in the PEP that doesn't = match how things are done in XML, in real life. You know Mule well, and argue = that the PEP has to be changed. And then you argue that the PEP, as it = stands, is closer to Mule than to XML !? Sorry the five minutes is up. If you want me to go on arguing, you'll have to pay for another five = minutes. </F>
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