[Python-Dev] bytes.from_hex() [Was: PEP 332 revival in coordination with pep 349?]
"Martin v. Löwis"
martin at v.loewis.de
Sat Feb 18 19:19:55 CET 2006
More information about the Python-Dev mailing list
Sat Feb 18 19:19:55 CET 2006
- Previous message: [Python-Dev] bytes.from_hex() [Was: PEP 332 revival in coordination with pep 349?]
- Next message: [Python-Dev] bytes.from_hex() [Was: PEP 332 revival in coordination with pep 349?]
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
M.-A. Lemburg wrote: >>>True. However, note that the .encode()/.decode() methods on >>>strings and Unicode narrow down the possible return types. >>>The corresponding .bytes methods should only allow bytes and >>>Unicode. >> >>I forgot that: what is the rationale for that restriction? > > > To assure that only those types can be returned from those > methods, ie. instances of basestring, which in return permits > type inference for those methods. Hmm. So it for type inference???? Where is that documented? This looks pretty inconsistent. Either codecs can give arbitrary return types, then .encode/.decode should also be allowed to give arbitrary return types, or codecs should be restricted. What's the point of first allowing a wide interface, and then narrowing it? Also, if type inference is the goal, what is the point in allowing two result types? Regards, Martin
- Previous message: [Python-Dev] bytes.from_hex() [Was: PEP 332 revival in coordination with pep 349?]
- Next message: [Python-Dev] bytes.from_hex() [Was: PEP 332 revival in coordination with pep 349?]
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
More information about the Python-Dev mailing list