On Mon, Sep 28, 2009 at 11:17 AM, Antoine Pitrou <solip...@pitrou.net> wrote:
> Guido van Rossum <guido <at> python.org> writes:
>>
>> At the same time I don't think a complete reset of the proposed API is
>> necessary. I am rather more thinking of judicious API tweaks in order
>> to cover some new use cases, without requiring a complete rewrite or
>> destroying the usability of the proposal for Peter's original use
>> cases.
>
> I think the current API is mostly fine as well, except for one roadblock for
> which several people has raised concerns, and that Peter stated he doesn't
> want
> to change.
Well, I'm sure somebody can come up with a compromise that works for everyone.
Assuming this is the issue about e.g. IPNetwork('7.7.7.7/30') !=
IPNetwork('7.7.7.4/30') even though these describe the same network
(and in fact their .network and .broadcast attributes have the same
values), there are several compromises; I don't know the use cases
well enough to pick one:
- There could be an optional keyword parameter that decides whether
the last bits are cleared or not (one would have to argue which
behavior to use by default).
- The __eq__ (and hence __hash__) could be made to return equality
even though the .ip attribute returns a different value and the repr()
is different. This is not unheard-of; Python's __eq__ is best thought
of as some sort of equivalence. For example two dicts that only differ
in the order of the items still compare equal (even though .keys() and
repr() return different values).
I note that it's easy to convert the unnormalized form to the normalized form:
a = IPNetwork('7.7.7.7/30')
b = IPNetwork(a.network, a.prefixlen)
It would also be easy to have a property or method that returns the
normalized version; as an optimization it could return self if self is
already normalized. And there could be an explicit API to test whether
a network is normalized (something more explicit than a.network ==
a.ip).
I'll leave it to others to discuss the pros and cons of each
alternative. I don't know why Peter wants to preserve the unnormalized
data but I'm sure he has a good use case, otherwise he wouldn't be so
adamant to keep it. :-)
--
--Guido van Rossum (home page: http://www.python.org/~guido/)
_______________________________________________
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
