[Python-Dev] PEP 3144: IP Address Manipulation Library for the Python Standard Library

Peter Moody peter at hda3.com
Wed Aug 19 17:19:46 CEST 2009

On Wed, Aug 19, 2009 at 6:47 AM, Tino Wildenhain<tino at wildenhain.de> wrote:
> Antoine Pitrou wrote:
>> Le Tue, 18 Aug 2009 13:00:06 -0700, Peter Moody a écrit :
>>> Howdy folks,
>>> I have a first draft of a PEP for including an IP address manipulation
>>> library in the python stdlib. It seems like there are a lot of really
>>> smart folks with some, ahem, strong ideas about what an IP address
>>> module should and shouldn't be so I wanted to solicit your input on this
>>> pep.
>> When you say :
>> « the results of the first computation should be cached and only
>> re-generated should the object properties change »
>> does it mean that the objects are mutable? Would it make sense to make
>> them immutable and therefore hashable (such as, e.g., datetime objects)?
> They could impelement __hash__ to behave correctly in this case.
> In the examples however I see:
>>>> o.broadcast
>    IPv4Address('')
> this is often used but not the only valid broadcast address,
> in fact, any address between network address and max(address with given
> netmask) can be defined as broadcast. Maybe biggest or greatest
> would be better name for the attribute. User is then free to interpret
> it as broadcast if desired.
> The attribute network returned as address object also does not seem
> right.

by convention, the highest address in a given network is called the
broadcast address while the lowest address is called the network
address. They're also distinct addresses, as opposed to networks,
hence .broadcast/.network/etc returning IPvXAddress objects. calling
them .biggest and .smallest would be confusing.

am I misinterpreting what you mean?

> The performance hit you mention by translating the object upfront
> is neglegtible I'd say - for any sensible use of the object you'd
> need the binary form anyway. You can even use system (e.g. socket)
> funtions to make the translation very fast. This also safes space
> and allow vor verification of the input.

I'll look into using socket where I can, but the computational hit
actually wasn't negligible. A common use for something like this
library might be to verify that an addresses typed by a user is valid,
'' instead os '1921.68.1.1'; computing the extra attributes
delays the return time and doesn't actually benefit the user or


> (e.g. '' is 18 bytes where it could
>  be stored as 8 bytes instead (or even 5 if you use
> ip/prefixlength)
> I have a very very old implementation which even did the
> translation from cidr format to integer in python code
> (I don't say plain ;) but maybe worth a look:
> http://www.zope.org/Members/tino/IPPatternAuthentication/IPHelper.py/view
> Regards
> Tino
> _______________________________________________
> 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