[Python-Dev] bytes.from_hex() [Was: PEP 332 revival in coordination with pep 349?] (original) (raw)
M.-A. Lemburg mal at egenix.com
Sat Feb 18 20:38:21 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()
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Martin v. Löwis wrote:
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?
Somewhere in the python-dev mailing list archives ;-)
Seriously, we should probably add this to the documentation.
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.
No.
As I've said before: the .encode() and .decode() methods are convenience methods to interface to codecs which take string/Unicode on input and create string/Unicode output.
What's the point of first allowing a wide interface, and then narrowing it?
The codec interface is an abstract interface. It is a flexible enough to allow codecs to define possible input and output types while being strict about the method names and signatures.
Much like the file interface in Python, the copy protocol or the pickle interface.
Also, if type inference is the goal, what is the point in allowing two result types?
I'm not sure I understand the question: type inference is about being able to infer the types of (among other things) function return objects. This is what the restriction guarantees - much like int() guarantees that you get either an integer or a long.
-- Marc-Andre Lemburg eGenix.com
Professional Python Services directly from the Source (#1, Feb 18 2006)
Python/Zope Consulting and Support ... http://www.egenix.com/ mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
- Previous message: [Python-Dev] bytes.from_hex() [Was: PEP 332 revival in coordination with pep 349?]
- Next message: [Python-Dev] bytes.from_hex()
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]