On Sun, Sep 27, 2009 at 10:22 AM, Antoine Pitrou <solip...@pitrou.net> wrote:
> Peter Moody <peter <at> hda3.com> writes:
>>
>> The reason (aside from the name) that I'm not going to include this in
>> ipaddr is that it would require the user to deal with two objects when
>> one would suffice.
>
> You make it sound like it's a burden, but "dealing" with two objects is not
> something extraordinary or bizarre, it happens all the time when you do
> network
> programming: e.g. ('127.0.0.1', 80).
>
> (or would you argue that Address objects should have an optional
> distinguishing
> 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.
> If you need the two objects, whether you access them through separate
> variables
> (`network` and `host`) or through attribute access (`network` and
> `network.host`) doesn't really matter. You can even pretend the tuple is an
> atomic object and store it as-is if you want. I'm not sure what annoys you
> here.
this is tautological. if you need two objects, then two objects is
what you need. I'm saying that you don't need two objects for this,
that common accepted practice is to represent this as one. Note,
there is *nothing* stopping you currently from using two objects for
this, an IPAddress object and a strict=True IPNetwork object.
I'm not sure what annoys you about this.
>> It's similar to getting two return values from
>> float().
>
> I don't see how it's similar, since a float is a clearly defined atomic
> entity.
> Most float operations become meaningless if you consider the integral and the
> fractional part separately.
>
> Regards
>
> Antoine.
>
>
> _______________________________________________
> 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
