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

2009-08-19 Thread Antoine Pitrou 
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)?


___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

2009-08-19 Thread Tino Wildenhain 

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.

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.

(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



smime.p7s
Description: S/MIME Cryptographic Signature
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

2009-08-19 Thread Peter Moody 
On Wed, Aug 19, 2009 at 6:47 AM, Tino Wildenhain 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
> [email protected]
> 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
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

2009-08-19 Thread Peter Moody 
On Wed, Aug 19, 2009 at 3:20 AM, 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)?

that's a good point. I'll implement __hash__ in the BaseIP class.

> ___
> Python-Dev mailing list
> [email protected]
> 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
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

2009-08-19 Thread Eric Smith 

Peter Moody wrote:

On Wed, Aug 19, 2009 at 3:20 AM, 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)?


that's a good point. I'll implement __hash__ in the BaseIP class.


But are the objects mutable? I haven't had time to deep dive on this 
yet, but I'd like to. I also use IPy and would like to some this in the 
stdlib.


Eric.
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

2009-08-19 Thread Tino Wildenhain 

Peter Moody wrote:

On Wed, Aug 19, 2009 at 6:47 AM, Tino Wildenhain 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



smime.p7s
Description: S/MIME Cryptographic Signature
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

2009-08-19 Thread R. David Murray 

On Wed, 19 Aug 2009 at 08:19, Peter Moody wrote:

On Wed, Aug 19, 2009 at 6:47 AM, Tino Wildenhain wrote:

Le Tue, 18 Aug 2009 13:00:06 -0700, Peter Moody a ?crit :



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?


Possibly.  Tino means exactly what he said:  the broadcast address
does not _have_ to be the last IP, nor does the last IP _have_ to be
a broadcast, though in practice they almost always are (and using the
last IP as a host IP almost never works in practice in a heterogeneous
network).  Check out the 'broadcast' option of the ifconfig command for
confirmation that the broadcast address can be any IP in the network.
Of course, for that to work all hosts on the network have to agree on
what the broadcast is, hence the normal convention that the broadcast
is the last IP in the network.

As for the 'network' attribute, if you call it 'network' IMO it should
be a network data type, which would make it rather redundant.  What you
are actually returning is what I have normally heard called either the
'zero' of the network, or the "network number" or "network identifier";
but never just "network" (a network has to have at least an implicit
netmask to be meaningful, IMO).

Since you are dealing with networks as a list of addresses, perhaps
you should drop the 'network' attribute, make the 'broadcast' attribute
settable with a default equal to self[-1], and let the user refer to
the zero element to get the zero of the network if they want it.

--David___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

2009-08-19 Thread Peter Moody 
On Wed, Aug 19, 2009 at 8:39 AM, Eric Smith wrote:
> Peter Moody wrote:
>>
>> On Wed, Aug 19, 2009 at 3:20 AM, 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)?
>>
>> that's a good point. I'll implement __hash__ in the BaseIP class.
>
> But are the objects mutable? I haven't had time to deep dive on this yet,
> but I'd like to. I also use IPy and would like to some this in the stdlib.

you can't set them directly, if that's what you mean.

>>> import ipaddr
>>> o = ipaddr.IPv4Network('1.1.1.0/24')
>>> o.broadcast
IPv4Address('1.1.1.255')
>>> o.network
IPv4Address('1.1.1.0')
>>> o.broadcast = ipaddr.IPv4Address('1.1.1.127')
Traceback (most recent call last):
  File "", line 1, in 
AttributeError: can't set attribute
>>> o.prefixlen = 25
>>> o.broadcast
IPv4Address('1.1.1.127')

> Eric.
>
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

2009-08-19 Thread Antoine Pitrou 
Le Wed, 19 Aug 2009 08:35:15 -0700, Peter Moody a écrit :
>>
>> 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)?
> 
> that's a good point. I'll implement __hash__ in the BaseIP class.

It is a common practice that only immutable objects define a meaningful 
__hash__ method. The reason is that dicts and sets (and perhaps other 
structures) cache the hash value instead of calling __hash__ again and 
again. If you stick a mutable with a meaningful __hash__ in a dict, and 
then modify the mutable object, lookups will give the wrong results (they 
will be based on the old, stale hash value).

It seems to me that hashability is a more desireable property of IP 
objects than modifiability. I don't see any reason to modify an IP object 
after having created it (rather than creating a new object).

Regards

Antoine.


___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

2009-08-19 Thread Peter Moody 
On Wed, Aug 19, 2009 at 9:21 AM, R. David Murray wrote:
> On Wed, 19 Aug 2009 at 08:19, Peter Moody wrote:
>>
>> On Wed, Aug 19, 2009 at 6:47 AM, Tino Wildenhain
>> wrote:

 Le Tue, 18 Aug 2009 13:00:06 -0700, Peter Moody a écrit :
>>>
>> 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?
>
> Possibly.  Tino means exactly what he said:  the broadcast address
> does not _have_ to be the last IP, nor does the last IP _have_ to be
> a broadcast, though in practice they almost always are (and using the
> last IP as a host IP almost never works in practice in a heterogeneous
> network).  Check out the 'broadcast' option of the ifconfig command for
> confirmation that the broadcast address can be any IP in the network.
> Of course, for that to work all hosts on the network have to agree on
> what the broadcast is, hence the normal convention that the broadcast
> is the last IP in the network.
>
> As for the 'network' attribute, if you call it 'network' IMO it should
> be a network data type, which would make it rather redundant.  What you
> are actually returning is what I have normally heard called either the
> 'zero' of the network, or the "network number" or "network identifier";
> but never just "network" (a network has to have at least an implicit
> netmask to be meaningful, IMO).
>
> Since you are dealing with networks as a list of addresses, perhaps
> you should drop the 'network' attribute, make the 'broadcast' attribute
> settable with a default equal to self[-1], and let the user refer to
> the zero element to get the zero of the network if they want it.

making the broadcast address settable (with a default to self[-1])
might be reasonable, though it is different from just about every
other python implementation I've seen (IPy, ipv4.py, netaddr).

I'm not sure I understand your point about the network attribute.
what I'm returning with network is the subnet-id/base address of the
given network. Again, .network seems to be fairly standard for naming.

> --David
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

[Python-Dev] Two laments about CPython's AST Nodes

2009-08-19 Thread Frank Wierzbicki 
Before I start complaining, I want to mention what a huge help it has
been to be able to directly compare the AST exposed by ast.py in
making Jython a better Python.  Thanks for that!

Now on to the complaints: Though I recently added support for this in
Jython, I don't like that nodes can be defined without required
attributes, for example:

node = ast.Assign()

Is valid, even though it requires "node.targets" and "node.value" (I'm
less concerned about the required lineno and col_offset, as I can
understand holding off on these so that you can just use
fix_missing_locations to fill these in for you).

My other (bigger) gripe is that you can define these values with
arbitrary objects that will blow up at parse time.  So for example you
can write:

node = ast.Assign()
node.targets = "whatever"

Which, when you try to parse, blows up with "TypeError: Assign field
"targets" must be a list, not a str".  I'd be much happier if this
blew up right away when you try to make the assignment.  At the
moment, this is how it works in Jython (though I could support this
with some contorting).

BTW -- I *am* volunteering to attempt to implement these things in
CPython if there is support :)

-Frank
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

2009-08-19 Thread Eric Smith 

Peter Moody wrote:

On Wed, Aug 19, 2009 at 9:21 AM, R. David Murray wrote:



Possibly.  Tino means exactly what he said:  the broadcast address
does not _have_ to be the last IP, nor does the last IP _have_ to be
a broadcast, though in practice they almost always are (and using the
last IP as a host IP almost never works in practice in a heterogeneous
network).  Check out the 'broadcast' option of the ifconfig command for
confirmation that the broadcast address can be any IP in the network.
Of course, for that to work all hosts on the network have to agree on
what the broadcast is, hence the normal convention that the broadcast
is the last IP in the network.

As for the 'network' attribute, if you call it 'network' IMO it should
be a network data type, which would make it rather redundant.  What you
are actually returning is what I have normally heard called either the
'zero' of the network, or the "network number" or "network identifier";
but never just "network" (a network has to have at least an implicit
netmask to be meaningful, IMO).

Since you are dealing with networks as a list of addresses, perhaps
you should drop the 'network' attribute, make the 'broadcast' attribute
settable with a default equal to self[-1], and let the user refer to
the zero element to get the zero of the network if they want it.


making the broadcast address settable (with a default to self[-1])
might be reasonable, though it is different from just about every
other python implementation I've seen (IPy, ipv4.py, netaddr).

I'm not sure I understand your point about the network attribute.
what I'm returning with network is the subnet-id/base address of the
given network. Again, .network seems to be fairly standard for naming.


I think using .network and .broadcast are pretty well understood to be 
the [0] and [-1] of the network address block. I don't think we want to 
start creating new terms or access patterns here.


+1 on leaving .network and .broadcast as-is (including returning a 
IPvXAddress object).


Eric.
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

2009-08-19 Thread Glyph Lefkowitz 
On Wed, Aug 19, 2009 at 2:20 PM, Eric Smith  wrote:


> I think using .network and .broadcast are pretty well understood to be the
> [0] and [-1] of the network address block. I don't think we want to start
> creating new terms or access patterns here.
>
> +1 on leaving .network and .broadcast as-is (including returning a
> IPvXAddress object).
>

-1.  I think 'network.number' or 'network.zero' is a lot clearer than
'network.network'.  Maybe '.broadcast' would be okay, as long as it *can* be
adjusted for those unusual, or maybe even only hypothetical, networks where
it is not the [-1].
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Two laments about CPython's AST Nodes

2009-08-19 Thread Brett Cannon 
On Wed, Aug 19, 2009 at 11:10, Frank Wierzbicki wrote:
> Before I start complaining, I want to mention what a huge help it has
> been to be able to directly compare the AST exposed by ast.py in
> making Jython a better Python.  Thanks for that!
>
> Now on to the complaints: Though I recently added support for this in
> Jython, I don't like that nodes can be defined without required
> attributes, for example:
>
> node = ast.Assign()
>
> Is valid, even though it requires "node.targets" and "node.value" (I'm
> less concerned about the required lineno and col_offset, as I can
> understand holding off on these so that you can just use
> fix_missing_locations to fill these in for you).
>
> My other (bigger) gripe is that you can define these values with
> arbitrary objects that will blow up at parse time.  So for example you
> can write:
>
> node = ast.Assign()
> node.targets = "whatever"
>
> Which, when you try to parse, blows up with "TypeError: Assign field
> "targets" must be a list, not a str".  I'd be much happier if this
> blew up right away when you try to make the assignment.  At the
> moment, this is how it works in Jython (though I could support this
> with some contorting).
>
> BTW -- I *am* volunteering to attempt to implement these things in
> CPython if there is support :)

+1 from me for adding this support. While I can see people wanting to
create the node as soon as it is known to be needed and then plug in
the parts as they get parsed, postponing the node creation to later
once the subnodes have been done is not exactly a challenge.

-Brett
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

2009-08-19 Thread Eric Smith 

Glyph Lefkowitz wrote:
On Wed, Aug 19, 2009 at 2:20 PM, Eric Smith > wrote:
 


I think using .network and .broadcast are pretty well understood to
be the [0] and [-1] of the network address block. I don't think we
want to start creating new terms or access patterns here.

+1 on leaving .network and .broadcast as-is (including returning a
IPvXAddress object).


-1.  I think 'network.number' or 'network.zero' is a lot clearer than 
'network.network'.  Maybe '.broadcast' would be okay, as long as it 
/can/ be adjusted for those unusual, or maybe even only hypothetical, 
networks where it is not the [-1].


Is there some existing library that uses .number or .zero? IPy uses .net 
(and .broadcast for [-1]).


___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Two laments about CPython's AST Nodes

2009-08-19 Thread Benjamin Peterson 
2009/8/19 Frank Wierzbicki :
> Before I start complaining, I want to mention what a huge help it has
> been to be able to directly compare the AST exposed by ast.py in
> making Jython a better Python.  Thanks for that!
>
> Now on to the complaints: Though I recently added support for this in
> Jython, I don't like that nodes can be defined without required
> attributes, for example:
>
> node = ast.Assign()
>
> Is valid, even though it requires "node.targets" and "node.value" (I'm
> less concerned about the required lineno and col_offset, as I can
> understand holding off on these so that you can just use
> fix_missing_locations to fill these in for you).

+1

>
> My other (bigger) gripe is that you can define these values with
> arbitrary objects that will blow up at parse time.  So for example you
> can write:
>
> node = ast.Assign()
> node.targets = "whatever"
>
> Which, when you try to parse, blows up with "TypeError: Assign field
> "targets" must be a list, not a str".  I'd be much happier if this
> blew up right away when you try to make the assignment.  At the
> moment, this is how it works in Jython (though I could support this
> with some contorting).

I also think this is a good idea, but this also causes an asymmetry. I
would still be able to do this:

node = ast.Module([])
node.body.append("random stuff")

and not have it type checked until it is compiled. This would be hard
to fix, though, and I think it is worth living with.

>
> BTW -- I *am* volunteering to attempt to implement these things in
> CPython if there is support :)

Very generous. :)


-- 
Regards,
Benjamin
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

2009-08-19 Thread Martin v. Löwis 
> 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)

You could, but then you are violating existing protocol specifications.

RFC 1122 mandates, in sections 3.2.1.3 and 3.3.6, that certain addresses
MUST be understood as broadcast addresses, by all nodes (independent of
configuration).

I think a Python IP address library should conform to all relevant RFCs.

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

No. I think setting the broadcast address to something else just does
not need to be supported.

Regards,
Martin

___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Two laments about CPython's AST Nodes

2009-08-19 Thread Martin v. Löwis 
> Now on to the complaints: Though I recently added support for this in
> Jython, I don't like that nodes can be defined without required
> attributes, for example:
> 
> node = ast.Assign()

I think we disagree in two points in our evaluation of this behavior:

a) ast.Assign is *not* a node of the CPython AST. The CPython AST is
   a set of C structures in Include/Python-ast.h. ast.Assign is merely
   a mirror structure of that.

b) it is, IMO, not reasonable to require users who create AST trees
   out of nothing to have correct trees at all times. I.e. it must be
   possible to represent incorrect trees.

c) the AST is *not* part of the Python language or library. It may
   change at any time without notice, and Jython is not required to
   duplicate its behavior exactly.

[so that's three items - as there should be in any good list of
two items :-]

> Which, when you try to parse, blows up with "TypeError: Assign field
> "targets" must be a list, not a str".  I'd be much happier if this
> blew up right away when you try to make the assignment.  At the
> moment, this is how it works in Jython (though I could support this
> with some contorting).

What precisely is it that makes this difficult to implement. If you
would follow CPython's implementation strategy (i.e. generate glue
code out of ASDL), I feel that it should be straight-forward to provide
exactly the same behavior in Jython.

> BTW -- I *am* volunteering to attempt to implement these things in
> CPython if there is support :)

I'm not sure I can support such a change. Giving the child nodes at
creation time, optionally, would be fine with me. Requiring the
tree to conform to the grammar at all times is unreasonable, IMO
(you can't simultaneously create all nodes in the tree and glue
them together, so you have to create the tree in steps - which means
that it will be intermittently incorrect).

You seem to propose some middle ground, but I'm not sure I understand
what that middle ground is.

Regards,
Martin
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

2009-08-19 Thread Glyph Lefkowitz 
On Wed, Aug 19, 2009 at 4:45 PM, "Martin v. Löwis" wrote:

> > 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)
>
> You could, but then you are violating existing protocol specifications.
>
> RFC 1122 mandates, in sections 3.2.1.3 and 3.3.6, that certain addresses
> MUST be understood as broadcast addresses, by all nodes (independent of
> configuration).
>
> I think a Python IP address library should conform to all relevant RFCs.
>

Yes, but section 3.3.6 also states:

There is a class of hosts (4.2BSD Unix and its derivatives, but not 4.3BSD)
that use non-standard broadcast address forms, substituting 0 for -1. All
hosts SHOULD recognize and accept any of these non-standard broadcast
addresses as the destination address of an incoming datagram. A host MAY
optionally have a configuration option to choose the 0 or the -1 form of
broadcast address, for each physical interface, but this option SHOULD
default to the standard (-1) form.

So it sounds like doing what I suggested earlier (default to [-1], allow for
customization) is actually required by the RFC :-).  Although it does sound
like the RFC only requires that you be able to customize to [0] rather than
[-1], rather than any address.  In practical terms though I believe it is
possible to do as Tino suggests and configure any crazy address you want to
be the broadcast address (or addresses, even) for a network.

I think setting the broadcast address to something else just does not need
> to be supported.


It is unusual, but frankly, needing to actually do operations on broadcast
addresses at all is also a pretty unusual task.  Broadcast itself is a
somewhat obscure corner of networking.  I suspect that in many deployments
that need to write significant code to deal with broadcast addresses, rather
than the usual default stuff, funky configurations will actually be quite
common.

I would not be surprised to find that there are still some 4.2BSD VAXes
somewhere doing something important, and some Python may one day be called
upon to manage their networks.
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

2009-08-19 Thread Eric Smith 

[Glyph]
So it sounds like doing what I suggested earlier (default to [-1], allow 
for customization) is actually required by the RFC :-).  Although it 
does sound like the RFC only requires that you be able to customize to 
[0] rather than [-1], rather than any address.  In practical terms 
though I believe it is possible to do as Tino suggests and configure any 
crazy address you want to be the broadcast address (or addresses, even) 
for a network.


If you're doing this, are you really going to be specifying the 
broadcast address as something like network.use_broadcast_index(-2) (or 
even 0) and then using network.broadcast somewhere else? I just don't 
see that happening.


[Martin]


I think setting the broadcast address to something else just does
not need to be supported.


I agree.

[Glyph]
It is unusual, but frankly, needing to actually do operations on 
broadcast addresses at all is also a pretty unusual task.  Broadcast 
itself is a somewhat obscure corner of networking.  I suspect that in 
many deployments that need to write significant code to deal with 
broadcast addresses, rather than the usual default stuff, funky 
configurations will actually be quite common.


I use .broadcast from IPy, and I'm not doing anything funky. All of my 
broadcast addresses are network[-1].



___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

2009-08-19 Thread Nick Coghlan 
Glyph Lefkowitz wrote:
> It is unusual, but frankly, needing to actually do operations on
> broadcast addresses at all is also a pretty unusual task.  Broadcast
> itself is a somewhat obscure corner of networking.  I suspect that in
> many deployments that need to write significant code to deal with
> broadcast addresses, rather than the usual default stuff, funky
> configurations will actually be quite common.
> 
> I would not be surprised to find that there are still some 4.2BSD VAXes
> somewhere doing something important, and some Python may one day be
> called upon to manage their networks.

If using a custom broadcast address rather than the standard one, don't
use the ipnet.broadcast property?

I'm with Martin and the PEP author here - the property can quite happily
just use the conventional meaning without causing any real problems.
People doing something more unusual will still be free to either create
an appropriate IPAddress instance or else create an IPNetwork subclass
that defines the broadcast property differently (e.g. making it the same
as the network address).

Cheers,
Nick.

-- 
Nick Coghlan   |   [email protected]   |   Brisbane, Australia
---
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

2009-08-19 Thread Nick Coghlan 
Glyph Lefkowitz wrote:
> -1.  I think 'network.number' or 'network.zero' is a lot clearer than
> 'network.network'.  Maybe '.broadcast' would be okay, as long as it
> /can/ be adjusted for those unusual, or maybe even only hypothetical,
> networks where it is not the [-1].

Maybe this is something that differs by country, but I have *never*
heard the first address in an IP network (i.e. every bit not covered by
the netmask set to zero) referred to as anything other than the "network
address". Similarly, the last address (every bit not covered by the
netmask set to one) is referred to as the "broadcast address", even if
the relevant RFCs don't actually guarantee that.

Anyone tasked to deal with a network that is sufficient unusual to break
those two conventions is almost certainly going to have bigger problems
than the proposed meanings for ipnet.network and ipnet.broadcast not
giving the correct answer for their specific situation.

And if someone does need to deal with that, then they create an
appropriate subclass or use a less lightweight IP addressing library.

Cheers,
Nick.

-- 
Nick Coghlan   |   [email protected]   |   Brisbane, Australia
---
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

2009-08-19 Thread Nick Coghlan 
Peter Moody wrote:
> you can't set them directly, if that's what you mean.
> 
 import ipaddr
 o = ipaddr.IPv4Network('1.1.1.0/24')
 o.broadcast
> IPv4Address('1.1.1.255')
 o.network
> IPv4Address('1.1.1.0')
 o.broadcast = ipaddr.IPv4Address('1.1.1.127')
> Traceback (most recent call last):
>   File "", line 1, in 
> AttributeError: can't set attribute
 o.prefixlen = 25
 o.broadcast
> IPv4Address('1.1.1.127')

IPAddress instances should definitely be hashable, but as long as
"prefixlen" is mutable, IPNetwork instances should *not* be hashable,
since their value can change.

If prefixlen was made read only, then IPNetwork instances could also be
made hashable. In that case, changing the prefix length would then have
to be done by creating a new instance.

Cheers,
Nick.

-- 
Nick Coghlan   |   [email protected]   |   Brisbane, Australia
---
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

2009-08-19 Thread Peter Moody 
On Wed, Aug 19, 2009 at 2:44 PM, Nick Coghlan wrote:
> Peter Moody wrote:
>> you can't set them directly, if that's what you mean.
>>
> import ipaddr
> o = ipaddr.IPv4Network('1.1.1.0/24')
> o.broadcast
>> IPv4Address('1.1.1.255')
> o.network
>> IPv4Address('1.1.1.0')
> o.broadcast = ipaddr.IPv4Address('1.1.1.127')
>> Traceback (most recent call last):
>>   File "", line 1, in 
>> AttributeError: can't set attribute
> o.prefixlen = 25
> o.broadcast
>> IPv4Address('1.1.1.127')
>
> IPAddress instances should definitely be hashable, but as long as
> "prefixlen" is mutable, IPNetwork instances should *not* be hashable,
> since their value can change.
>
> If prefixlen was made read only, then IPNetwork instances could also be
> made hashable. In that case, changing the prefix length would then have
> to be done by creating a new instance.

ah, I see. I'll make this fix and I think this might actually simplify
the code.

just to double check, it's fine for IPNetwork to remain hashable if
set_prefix() actually returned a new object, correct?

> Cheers,
> Nick.
>
> --
> Nick Coghlan   |   [email protected]   |   Brisbane, Australia
> ---
>
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

2009-08-19 Thread Antoine Pitrou 
Eric Smith  trueblade.com> writes:
> 
> Is there some existing library that uses .number or .zero? IPy uses .net 
> (and .broadcast for [-1]).

Why not be explicit? Use .first and .last.


___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

2009-08-19 Thread Fred Drake 

On Aug 19, 2009, at 6:01 PM, Peter Moody wrote:

just to double check, it's fine for IPNetwork to remain hashable if
set_prefix() actually returned a new object, correct?



The name would be confusing, though.  Perhaps using_prefix() would be  
more clear.



  -Fred

--
Fred Drake   

___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

2009-08-19 Thread Eric Smith 

Fred Drake wrote:

On Aug 19, 2009, at 6:01 PM, Peter Moody wrote:

just to double check, it's fine for IPNetwork to remain hashable if
set_prefix() actually returned a new object, correct?



The name would be confusing, though.  Perhaps using_prefix() would be 
more clear.


I think you'd be better off either doing this with an optional parameter 
to __init__, or a class method factory function (maybe from_prefix or 
similar). I don't see why it should be a method on an existing object.

___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

2009-08-19 Thread Peter Moody 
On Wed, Aug 19, 2009 at 9:07 PM, Eric Smith wrote:
> Fred Drake wrote:
>>
>> On Aug 19, 2009, at 6:01 PM, Peter Moody wrote:
>>>
>>> just to double check, it's fine for IPNetwork to remain hashable if
>>> set_prefix() actually returned a new object, correct?
>>
>>
>> The name would be confusing, though.  Perhaps using_prefix() would be more
>> clear.
>
> I think you'd be better off either doing this with an optional parameter to
> __init__, or a class method factory function (maybe from_prefix or similar).
> I don't see why it should be a method on an existing object.
>

while not the the prettiest, you can already (ignoring the set_prefix)
do something like:

>>> newobject = ipaddr.IP(str(o.network) + "/new prefix")

Is this sufficient?
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com