Fredrik Lundh wrote: > > mal wrote: > > > Ok. Please show me how that would work. More precisely, please write a > > > PEP describing the rationale for this feature, including use case > > > examples and precise semantics of the proposed addition. > > > > There's no need for a PEP. This addition is much too simple > > to require a PEP on its own. > > we'd been better off if you'd written a PEP before you started > adding decode and encode stuff. what's currently implemented > is ugly enough; adding more warts won't make it any prettier. Could you please be more specific about what is "ugly" in the current implementation ? The .encode/.decode methods are a direct interface to the codecs encoder and decoder APIs. I can't find anything ugly about this in general except maybe some of the constraints which were originally put into these interface on the grounds of using them for string/Unicode conversions -- I have already removed most of these and would like to clean this up completely before 2.2 gets out. > -1 on anything except a PEP that covers *all* aspects of > encode/decode (including things that are already implemented) Gee, Guido starts breaking code and nobody objects; I try to clean up some left-overs in the Unicode implementation and people start huge discussions about it. Something is backwards here... -- Marc-Andre Lemburg CEO eGenix.com Software GmbH ______________________________________________________________________ Company & Consulting: http://www.egenix.com/ Python Software: http://www.lemburg.com/python/
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