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

Paul Moore p.f.moore at gmail.com
Mon Sep 28 17:25:54 CEST 2009

2009/9/28 Peter Moody <peter at hda3.com>:

That is, you've rejected the idea of having:

IPv4Network(192.168.1.1/24) IPv4Network(192.168.1.0/24) yes, I and everyone have rejected that idea. this should either raise an error, or do what it does now, that is, return IPv4Network('192.168.1.1/24')

Speaking as a member of the group "everyone", I have not rejected that idea. It seems perfectly sensible to me. Yes, it "loses" the information about the full IP address 192.168.1.1, but in my view, that's what I asked it to do by requesting a network object back.

2009/9/28 R. David Murray <rdmurray at bitdance.com>:

The fundamental divide here is between two behaviors.

ipaddr:  >>> x = IPv4Network('192.168.1.1/24')  >>> y = IPv4Network('192.168.1.0/24')  >>> x == y  False  >>> x.ip  IPv4Address('192.168.1.1') desired:  >>> x = IPv4Network('192.168.1.1/24')  >>> y = IPv4Network('192.168.1.0/24')  >>> x == y  True  >>> x.ip  Traceback (most recent call last):  File "", line 1, in  AttributeError: 'IPv4Network' object has no attribute 'ip' Everything else is pretty much bikeshedding and can be dealt with.  This is fundamental and Peter has indicated he will not change it.

Agreed. I would prefer the option marked "desired". As a naive "casual user" of the module, I claim that the current behaviour is non-intuitive and I anticipate it causing me issues (not many, and I won't use the module often, so I concede - before someone asks - that it'll be a minor inconvenience to me).

Given that I am a minor user, as noted above, I remain -1 on inclusion, largely because it feels to me like the module will suffer the same fate as optparse - rejecting certain changes which have relatively widespread support on essentially philosophical grounds.

Paul.

More information about the Python-Dev mailing list