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

Glyph Lefkowitz glyph at twistedmatrix.com
Tue Sep 29 20:19:10 CEST 2009

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>

More information about the Python-Dev mailing list