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

[Tino Wildenhain]

Peter Moody wrote:
> 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('1.1.1.255')
>>
>> 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?

No, I just said its conventionally used as that but its not definition
of a broadcast (in fact you can have any valid host address defined
as broadcast as long as all members of the network agree on that)

Since you dont want to call the attribute ususally_the_broadcast_address
or something, other names which tell you about the data would seem more
appropriate (like greatest)

>> 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 '1921.68.1.1'; computing the extra attributes
> delays the return time and doesn't actually benefit the user or
> programmer.

Maybe I don't quite understand your extra attributes stuff - the
32 bit integer for ipv4 IP and the netmask in either 32 bit
or prefix length in 5 bits would be enough of a storage attribute.

All others are just representation of the values.

Storing the data as string seems a bit suboptimal since for
any sensible operation with the data you'd need to do the
conversion anyway.

Regards
Tino

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3241 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://mail.python.org/pipermail/python-dev/attachments/20090819/d879585b/attachment.bin>