[Python-Dev] PEP 3144 review. (original) (raw)

R. David Murray rdmurray at bitdance.com
Tue Sep 29 04:17:54 CEST 2009

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

More information about the Python-Dev mailing list