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

Peter Moody peter at hda3.com
Mon Sep 28 02:31:56 CEST 2009

On Sun, Sep 27, 2009 at 5:13 PM, Steven D'Aprano <steve at pearwood.info> wrote:

On Mon, 28 Sep 2009 03:53:27 am Peter Moody wrote:

>>   I understand what you're saying, I understand that >> 192.168.1.1/24 isn't a network, > > But you still want to treat it as one. > > Could you explain what benefit there is for allowing the user to > create network objects that don't represent networks? Is there a > use-case where these networks-that-aren't-networks are something > other than a typo? Under what circumstances would I want to specify > a network as 192.168.1.1/24 instead of 192.168.1.0/24?

this is pretty ridiculous. if in the last two months you haven't seen a single use case, then you haven't been paying attention. No, I haven't read every single email in excruciating detail in this extremely long thread. I'd bet most other people haven't. I'm trying to understand why you want something which, in my ignorance, seems patently ridiculous to me: allowing Network objects which aren't Networks, particularly since in private email to me you denied that there was a use-case for the requested (Address object + netmask).

no, it seems as though you're either misrepresenting my position or you misunderstood what I said. I said that there wasn't a use-case for explicitly pulling that functionality out into a a new class, and having 6 classes.

But it seems to me that this is exactly what you have in the current implementation, except you call it a Network object, and have rejected the suggestion that the non-network bits of the address should be zeroed.

I have not rejected this. I have rejected the suggestion that the current IPv?Network classes do this by default.

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')

as reducing functionality, presumably because the address 192.168.1.1 is lost.

good guess.

Sounds just like an Address+netmask to me, with added network-like behaviour.

Some people have requested a way of explicitly calculating a network from an Address and netmask, and you've been hostile to the idea. But it seems to me that your API does exactly that.

You mean the suggestion to include an IPv?Network object attribute with the IPv?Address objects? I thought that was dropped long ago.

I'm not the only person who thinks your API conflates two different concepts into a single class, and I'm trying to see your side of the argument. But your hostile attitude isn't making it easy.

apologies if you find me hostile. I'm not sure how you'd expect me to be if, after 2 months 200+ messages, both on list and off, you were unable to recall a single use-case.

-- Steven D'Aprano

Python-Dev mailing list Python-Dev at python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/python-dev%40hda3.com

More information about the Python-Dev mailing list