[Python-Dev] PEP 3144 review.

[Peter Moody]

On Wed, Sep 16, 2009 at 1:35 PM, Antoine Pitrou <solipsis at pitrou.net> wrote:
> Le Mon, 14 Sep 2009 09:44:12 -0700, Peter Moody a écrit :
>> Folks, Guido,
>>
>> I believe PEP 3144 is ready for your review.  When you get a chance, can
>> you take a look/make a pronouncement?
>
> Besides what has already been said in the thread, I have a bunch of
> comments:
>
>    It should be noted
>    that __len__ doesn't work as expected since python internals has this
>    limited to a 32 bit integer and it would need to be at least 128 bits
> to
>    work with IPV6.
>
> You should clarify what it means: does the result get truncated, or is an
> error thrown when it can't fit inside an int?

I'll clarify this, but it looks like this:

>>> len(xrange(0xFFFFFFFFFFFFFFFFFFFFFFFFF))
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
OverflowError: long int too large to convert to int
>>>

basically, __len__(self): can only return an int. At least that's what
I recall from the discussion.

>    1. all IP addresses and networks, both IPv4 and IPv6. (IPAddrBase)
>
>    2. all IP addresses of both versions. (BaseIP)
>
>    3. all IP networks of both version. (BaseNet)
>
>    4. all IPv4 objects, both addresses and networks. (BaseV4)
>
>    5. all IPv6 objects, both addresses and networks. (BaseV6)
>
> Should those base classes be exposed publically? It may make life more
> difficult if an alternate implementation (say, a C accelerator) wants to
> adopt a different code sharing strategy.
>
> If they are not to be part of the public API, their names should be
> prefixed with an underscore.

makes sense. I see no need for them to be public. private they go.

>
> _______________________________________________
> 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
>