[Python-Dev] PEP 3144 review.

[Steven D'Aprano]

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

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

>>> IPv4Network(192.168.1.1/24)
IPv4Network(192.168.1.0/24)

as reducing functionality, presumably because the address 192.168.1.1 is 
lost. 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.

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.



-- 
Steven D'Aprano