[Python-Dev] PEP 3144 review.

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 "<stdin>", line 1, in <module>
>    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