On Sun, Sep 27, 2009 at 5:13 PM, Steven D'Aprano <st...@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@python.org
> http://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> http://mail.python.org/mailman/options/python-dev/python-dev%40hda3.com
>
_______________________________________________
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
