On Wed, Aug 19, 2009 at 6:47 AM, Tino Wildenhain<t...@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?
> 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.
Cheers,
/peter
> (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
> 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@python.org
> http://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> http://mail.python.org/mailman/options/python-dev/python-dev%40hda3.com
>
>
_______________________________________________
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
