[Python-Dev] PEP 3144 review.

[R. David Murray]

On Mon, 28 Sep 2009 at 13:43, Guido van Rossum wrote:
> On Mon, Sep 28, 2009 at 1:36 PM, R. David Murray <rdmurray at bitdance.com> wrote:
> I would say that there certainly are precedents in other areas for
> keeping the information about the input form around. For example,
> occasionally it would be handy if parsing a hex integer returned an
> object that was compatible with other integers but somehow kept a hint
> that would cause printing it to use hex by default.
>
> I see keeping around the IP address used to create a network object as
> a similar edge case. I would probably define the __eq__ method to
> implement equivalency (ignoring the form of the input), just as I
> would in the case of the (hypothetical) hex integers. If you wanted to
> do a comparison that includes the input IP address, you could use (a,
> a.ip) == (b, b.ip).

Ignoring Antoine's excellent points for the moment, to my mind
one difference between your integer-with-hex-hint and ipaddr's
ip-with-netmask is that there is a one to one mapping between the
canonical hex representations and the integer.

If you want to argue that the _exact_ input string be preserved in the
integer object, then there might be more of a direct analogy.  Except that
ipaddr isn't preserving the input _string_, it's preserving a canonical
representation of that string, so even there the analogy wouldn't be
all that close.  The difference here is that ipaddr is preserving input
information that is irrelevant to the object being returned (a network).

The fractions case is much closer.

Or consider another analogy: the ipaddr case is like the mod function
returning a single object that is supposed to be the remainder,
but also has an extra field that records the original input number.
This might be a useful operator and object type in certain contexts, but
it is something that would be layered on top of the real mod function
that returns a simple integer remainder.  You would never approve this
remainder-with-saved-input as the data type returned by the mod operator.
(I hope :)

Similarly, there should be a basic ipaddr parsing function (and I don't
much care how you spell it, even though I have opinions) that returns
an ip address and a network object when given an ipaddress-plus-netmask
string.  An additional object built upon those fundamental data types that
remembers the input IP would be fine, but the data type that remembers
the IP should _not_ be the fundamental data type in the system.  That
strikes me as poor design, OO or otherwise.

In fact, your "sometimes it would be useful if" phrasing indicates that
your 'integer with hex hint' data type would also not be the fundamental
data type, but instead a subclass of int.

--David