[Python-Dev] PEP 3144: IP Address Manipulation Library for the Python Standard Library
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
>> 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:
> 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
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,
'192.168.1.1' instead os '1918.104.22.168'; computing the extra attributes
delays the return time and doesn't actually benefit the user or
> (e.g. '255.255.255.255/32' is 18 bytes where it could
> be stored as 8 bytes instead (or even 5 if you use
> 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:
> Python-Dev mailing list
> Python-Dev at python.org
More information about the Python-Dev