Nick Coghlan writes: > - even if there is a test suite, sufficiently pervasive [str/bytes] > type ambiguity may make it difficult to use for fault isolation
Difficult yes, but I would argue that that difficuly is inherent[1]. Ie, if it's pervasive, the fault should be isolated to the whole module. Such a fault *will* regress, often in the exact same place, but if not there, elsewhere due to the same ambiguity. That was my experience in both GNU Emacs and Mailman. In GNU Emacs's case there's a paired, much more successful (in respect of encoding problems) experience with XEmacs to compare.[2] We'll see how things go in Mailman 3 (which uses a nearly completely rewritten email package), but I'll bet the experience there is even more successful.[3] If you're looking for a band-aid that will get you back running asap, then you're better off bisecting the change history than going through a slew of warnings one-by-one, as a recent error is likely due to a recent change. If Neil still wants to go ahead, more power to him. I don't know everything. It's just that my experience in this area is sufficiently extensive and sufficiently bad that it's worth repeating (just this once!) Footnotes: [1] Or as Brooks would have said, "of the essence". [2] GNU Emacs has a multilingualization specialist in Ken Handa whose day job is writing multiligualization libraries, so their encoding detection, accuracy of implementation, and codec coverage is and always was better than XEmacs's. I'm referring here to internal bugs in the Lisp primitives dealing with text, as well as the difficulty of writing applications that handled both internal text and external bytes without confusing them. [3] Though not strictly comparable to the XEmacs experience, due to (1) being a second implementation, not a parallel implementation, and (2) the Internet environment being much more standard conformant, even in email, these days. _______________________________________________ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
