[Python-Dev] PEP 3144 review.

[Glyph Lefkowitz]

On Tue, Sep 29, 2009 at 1:00 PM, Guido van Rossum <guido at python.org> wrote:

> On Tue, Sep 29, 2009 at 9:03 AM, Antoine Pitrou <solipsis at pitrou.net>
> wrote:
>
> You say it yourself : it describes "the ip address/prefix of a NIC".
> > It isn't the job of a Network class. A Network shouldn't describe a
> > host, or a particular NIC.
>
> Hey Antoine,
>
> Can we drop the pedantic discussion about what "should" or "shouldn't"
> be the job of a "Network" class, and just proceed to a pragmatic
> compromise? Peter has already posted that he is okay with __eq__ and
> friends ignoring the .ip attribute, which sounds good enough to me.
> His use case (which he mentioned to me off-list) is simply that if the
> denormalized .ip attribute weren't saved as part of the IPNetwork
> class, in many cases he'd have to keep track of it separately, which
> just feels clumsy.
>

I apologize in advance for missing a message that answers my question; I've
done my best to read all the related traffic in the various threads that
discuss this, but I'm sure I missed something.

I don't see what's particularly "pragmatic", in terms of functionality,
about confusing the responsibility of the Network class.  Networks don't
have addresses, in the sense that is being discussed here.  Allowing them to
have an IP presents a misleading model, and will encourage applications to
be passing around networks where they should be passing around hosts.  And
yes, the discussion is pedantic, in that some people are certain to learn
about the model of IP networking by reading the documentation of this module
if it gets into the stdlib.  I personally learned all about async networking
from reading the asyncore, select, and socket modules in python 1.5.2, lo
these many years past.

The discussion seems to be centered around the inconvenience of adding a
separate IPNetworkWithHost class that can encapsulate both of these things.
Peter seems to think that this is hugely inconvenient, but classes are
cheap.  If we were talking about IPNetwork.from_string() instead of
IPNetwork(), it seems to me that it would even be acceptable for it to
return a IPNetwork subclass if the address were not canonical (i.e. without
the bits already masked off and zeroed).  Perhaps there should be such a
method, or even just a free function, parse_mask(), as that would allow for
dealing with other user-input use-cases that have been brought up in this
thread.  I don't understand why we can't just add that class and make
everybody happy.  IPNetwork could even have a .canonicalize() method which
would return itself, and the subclass implementation in IPNetworkWithHost
return the corresponding IPNetwork.  (I wish I could come up with a better
name, but I certainly agree that there are cases where a IPNetworkWithHost
is what I would want.)

In addition to the somebody-must-have-mentioned-this-already feeling that I
got, I hesitated to post this message because it doesn't actually seem that
important to me.  While I'm firmly convinced that Network.ip is a design
mistake, it's not like the rest of Python, or for that matter any software,
is completely perfect.  In fact I think this mistake is significantly less
bad than some of the others already present in Python.  If Peter remains
unconvinced, I do think that we should put it in the stdlib, move on, and
get to fixing some of the other stuff we agree needs fixing rather than
continuing to re-hash this.  Primarily because, as far as I can tell, if
hashing and equality are defined the way that everyone seems to be agreeing
they be defined (ignoring the .ip attribute) then those of us who think .ip
is a design error can use the library and safely ignore it completely.

So, I promise not to contribute further to the problem; I won't post again
in this thread against someone who is actually going to do some work here
wants to solicit a clarification of my opinion or some more ideas :).
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20090929/1bec9bb9/attachment.htm>