[Python-Dev] PEP 3144 review.
peter at hda3.com
Sun Sep 27 21:18:58 CEST 2009
On Sun, Sep 27, 2009 at 11:17 AM, Antoine Pitrou <solipsis at pitrou.net> wrote:
> Peter Moody <peter <at> hda3.com> writes:
>> > (or would you argue that Address objects should have an optional
>> > port number, for "convenience" reasons?)
>> I'm not sure what you're talking about, I've never argued to add layer
>> 4 information to ipaddr.
> It was an analogy, just like your "float" analogy.
>> I'm not sure what annoys you about this.
> I have already explained it: what annoys me is that it makes `Network` a hybrid
> object conflating two independent concepts, and makes the library less
> understandable as a result.
I understand that this is your assertion.
Here's the thing, your use case is already supported. IPv?Network
objects can only be created of network addresses, exceptions are
raised if all the host bits aren't 0, you can create and only deal
with IPv4Address('192.168.1.1') and IPv4Network('192.168.1.0/24',
strict=True) etc etc. That's not how I (nor many other network
administrators) would use it, but it's doable. what you're claiming is
that my use case is invalid.
that's what I claim is broken.
There have been folks on both sides claiming that this design is both
fundamentally confusing and fundamentally sound. The confused have
obviously been more vocal and less willing to compromise. So, the
basic design of the library stands as it is, minor implementation and
documentation bugs not withstanding. I'm not going to make ipaddr
less useful (strictly removing functionality), more bulky and
confusing (adding more confusingly named classes and methods) or
otherwise break the library in a vain attempt to have it included in
> Others have already pointed out that it makes operations like equality
> Python-Dev mailing list
> Python-Dev at python.org
> Unsubscribe: http://mail.python.org/mailman/options/python-dev/python-dev%40hda3.com
More information about the Python-Dev