[Python-Dev] PEP 3144 review.

Peter Moody peter at hda3.com
Sun Sep 27 20:04:04 CEST 2009


On Sun, Sep 27, 2009 at 10:22 AM, Antoine Pitrou <solipsis at 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 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