[Python-Dev] PEP 3144 review, and the inclusion process (original) (raw)
Guido van Rossum guido at python.org
Mon Sep 28 20:43:06 CEST 2009
- Previous message: [Python-Dev] PEP 3144 review, and the inclusion process
- Next message: [Python-Dev] PEP 3144 review, and the inclusion process
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
On Mon, Sep 28, 2009 at 11:17 AM, Antoine Pitrou <solipsis at pitrou.net> wrote:
Guido van Rossum <guido 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/)
- Previous message: [Python-Dev] PEP 3144 review, and the inclusion process
- Next message: [Python-Dev] PEP 3144 review, and the inclusion process
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]