Re: [Python-Dev] PEP 3144 review.

2009-09-26 Thread Barry Scott 


On 16 Sep 2009, at 01:05, Peter Moody wrote:


On Tue, Sep 15, 2009 at 4:34 PM, Scott Dial
 wrote:

R. David Murray wrote:

On Tue, 15 Sep 2009 at 21:58, Antoine Pitrou wrote:

Le mardi 15 septembre 2009 à 15:48 -0400, R. David Murray a écrit :

However, I do not think
that the proposed API should accept, eg, IPv4Network 
('192.168.1.1/24')

as valid.  That's just too confusing and error prone.


Indeed, it should throw some kind of ValueError instead.


Peter, what do you think?


I disagree. It seems overly pedantic to throw a valueerror on this.
IPy does (used to do?) this and it's one of the primary reasons I
wrote ipaddr.


I've seen user interfaces accept 192.168.1.1/24 as a short cut
to set the ipaddr and netmask on an interface.

For that use being able to parse that string into an IP Address and
a Net Mask is what they want.

If this is a common idiom having a utility function that returned
an IPv4Address('192.168.1.1') and IPv4Network('192.168.0.0')
would be useful.

If someone really thinks that '192.168.1.1/16' is a network any
good UI should detect it is invalid report that to the user.

If you think this is a decision that the only the caller can decide
why not add a keyword param to control the parsing?

IPv4Network( '192.168.1.1/16', syntax='loose' )

(I'm sure syntax='loose' is not right but you get the idea.)

Barry

___
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] Python 2.7 Mac universal builds seem broken on trunk

2009-09-26 Thread Barry Scott 
I'm working with http://svn.python.org/projects/python/trunk on Mac OS  
X 10.6.1

using Apples xcode gcc 4.2.1.

When I run the following commands:

	./configure --enable-framework --with-universal-archs=32-bit | tee  
build.config.log

make clean all | tee build.make.log

I end up with a x86_64 Python image.

No matter what I use for archs its always the same.

I would expect to see -arch arg to GCC but it is not there.

export CFLAG="-arch i386"

did not work either.

Am I doing something wrong or is this broken on trunk?

Barry

___
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 review.

2009-09-26 Thread Martin v. Löwis 
>  - Masks are also 32- (128-) bit integers, which happen to have the
>property that their leftmost N bits are all zero and the rest are all
>one.

As a side note, I would be in favor of dropping the concept of a mask
from the library, and only support a prefix length.

IPv6 doesn't support masks at all, and even for IPv4, I think there are
conventions (if not RFCs) against using them in a way that does not
correspond to a prefix length.

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 review.

2009-09-26 Thread Martin v. Löwis 
> I don't think the RFCs forbid the zero address being used


RFC 1122 does: "IP addresses are not permitted to have the value 0 or -1
for any of the , , or  fields (except in the special cases listed above)."

RFC 3021 modifies this requirement, allowing the zero address to
be used for an 31-bit prefix.

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-09-26 Thread Martin v. Löwis 
>>> 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].
> Real life example: network with a /31 mask.
> There are only two hosts: 0 and 1
> first host configures the other's host as broadcast address and vice versa.
> NOTE - broadcasts are different here!

This is RFC 3021. IIUC, it does not support directed broadcast; only
link-local broadcast can be used on that link.

So ISTM that .broadcast should raise an exception on a /31 network. Any
installation that configures the partner as the broadcast address is
broken (somebody correct me if I'm wrong).

> Another real life examples include /32 networks on PPP. Just a point-to-point.
> No need for broadcasts and networks, a host just have one IP address and
> send all traffic via point-to-point link, no addressing is required there.
> This is a working dialup configuration, it works for me, it works for you, 
> probably.
> It is not weird, it is common, it is used for PPPoE, for ADSL, for dialup.

So where is that defined?

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 review.

2009-09-26 Thread DrKJam 
2009/9/26 "Martin v. Löwis" 

> > I don't think the RFCs forbid the zero address being used
>
>
> RFC 1122 does: "IP addresses are not permitted to have the value 0 or -1
> for any of the , , or  number> fields (except in the special cases listed above)."
>
> The current version of the PEP and reference implementation do not mention
or deal with IPv4 classful addressing (A, B, C, D and E). It would be good
to know if any of this (admittedly older yet no less important)
functionality is going to be supported. If the library is to concentrate
solely on classless addressing (i.e. CIDR) please can this be stated in
future revisions of the PEP.


> RFC 3021 modifies this requirement, allowing the zero address to
> be used for an 31-bit prefix.
>
> 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/drkjam%40gmail.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 review.

2009-09-26 Thread Daniel Stutzbach 
On Sat, Sep 26, 2009 at 2:07 PM, DrKJam  wrote:

> The current version of the PEP and reference implementation do not mention
> or deal with IPv4 classful addressing (A, B, C, D and E). It would be good
> to know if any of this (admittedly older yet no less important)
> functionality is going to be supported. If the library is to concentrate
> solely on classless addressing (i.e. CIDR) please can this be stated in
> future revisions of the PEP.
>

Classful addressing was deprecated more than 15 years ago!

Quoting RFC 4632: "With the full deployment of CIDR on the Internet, such
scenarios are no longer operationally relevant."

--
Daniel Stutzbach, Ph.D.
President, Stutzbach Enterprises, LLC 
"The plumage don't enter into it. It's stone dead."
___
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 review.

2009-09-26 Thread DrKJam 
2009/9/26 Daniel Stutzbach 

> On Sat, Sep 26, 2009 at 2:07 PM, DrKJam  wrote:
>
>> The current version of the PEP and reference implementation do not mention
>> or deal with IPv4 classful addressing (A, B, C, D and E). It would be good
>> to know if any of this (admittedly older yet no less important)
>> functionality is going to be supported. If the library is to concentrate
>> solely on classless addressing (i.e. CIDR) please can this be stated in
>> future revisions of the PEP.
>>
>
> Classful addressing was deprecated more than 15 years ago!
>
> Quoting RFC 4632: "With the full deployment of CIDR on the Internet, such
> scenarios are no longer operationally relevant."


Interesting as evidence of classful IPv4 behaviour seems fairly pervasive in
current IP stacks and software that supports IPv4 addressing (e.g.
PostgreSQL inet and cidr data types).

Here's an excerpt from the 'ifconfig' man page (taken from an Ubuntu 9.04
install) :-
^^^
...
netmask addr

Set the IP network mask for this interface. This value defaults to the usual
class A, B or C network mask (as derived from the interface IP address). but
it can be set to any value.
...
^^^

The point being that you can't always assume /32 implicitly for all use
cases.

Here is how IP addresses without an explicit prefix or netmask are currently
handled :-

>>> import ipaddr
>>> ipaddr.IPv4Network('10.0.0.1')
IPv4Network('10.0.0.1/32')

It may not be something we want to support (you could always force the end
user to specify a prefix or netmask explicitly). This is fair enough, but
let's indicate that it's a considered choice. Somewhere in the PEP text is
might be a good place for treatment of this topic.

> --
> Daniel Stutzbach, Ph.D.
> President, Stutzbach Enterprises, LLC 
> "The plumage don't enter into it. It's stone dead."
>
>
___
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 review.

2009-09-26 Thread Daniel Stutzbach 
On Sat, Sep 26, 2009 at 4:57 PM, DrKJam  wrote:

> 2009/9/26 Daniel Stutzbach 
>
>> On Sat, Sep 26, 2009 at 2:07 PM, DrKJam  wrote:
>>
>>> The current version of the PEP and reference implementation do not
>>> mention or deal with IPv4 classful addressing (A, B, C, D and E). It would
>>> be good to know if any of this (admittedly older yet no less important)
>>> functionality is going to be supported. If the library is to concentrate
>>> solely on classless addressing (i.e. CIDR) please can this be stated in
>>> future revisions of the PEP.
>>>
>>
>> Classful addressing was deprecated more than 15 years ago!
>>
>> Quoting RFC 4632: "With the full deployment of CIDR on the Internet, such
>> scenarios are no longer operationally relevant."
>
>
> Interesting as evidence of classful IPv4 behaviour seems fairly pervasive
> in current IP stacks and software that supports IPv4 addressing (e.g.
> PostgreSQL inet and cidr data types).
>

PostgreSQL's inet type stores a host address and optionally a network mask.
It's cidr type stores a network address and mask.  Neither of them are
classful.


> Here's an excerpt from the 'ifconfig' man page (taken from an Ubuntu 9.04
> install) :-
> netmask addr
>
> Set the IP network mask for this interface. This value defaults to the
> usual class A, B or C network mask (as derived from the interface IP
> address). but it can be set to any value.
>

Since the network mask can be set to any legal value, that means it's stored
as CIDR.  It falls back on the classful network mask as a default.
Undoubtedly that was useful when ifconfig was updated for CIDR.  There were
still many classful networks and it needed to retain backward
compatibility.  After all, ifconfig is around 25 years old, and CIDR is only
16.

Today, all IP networks are classless (CIDR), and a system administrator
would have to do extra work to figure out if the default value happened to
be just right for the network they're setting up.


>  The point being that you can't always assume /32 implicitly for all use
> cases.
>

Certainly, which is why the user can explicitly set the netmask.


> Here is how IP addresses without an explicit prefix or netmask are
> currently handled :-
>
> >>> import ipaddr
> >>> ipaddr.IPv4Network('10.0.0.1')
> IPv4Network('10.0.0.1/32')
>
> It may not be something we want to support (you could always force the end
> user to specify a prefix or netmask explicitly). This is fair enough, but
> let's indicate that it's a considered choice. Somewhere in the PEP text is
> might be a good place for treatment of this topic.
>

+1 on forcing the user to specify a netmask explicitly and documenting it.

--
Daniel Stutzbach, Ph.D.
President, Stutzbach Enterprises, LLC 
___
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 review.

2009-09-26 Thread Peter Moody 
On Sat, Sep 26, 2009 at 4:27 PM, Daniel Stutzbach
 wrote:
> On Sat, Sep 26, 2009 at 4:57 PM, DrKJam  wrote:
>>
>> 2009/9/26 Daniel Stutzbach 
>>>
>>> On Sat, Sep 26, 2009 at 2:07 PM, DrKJam  wrote:

 The current version of the PEP and reference implementation do not
 mention or deal with IPv4 classful addressing (A, B, C, D and E). It would
 be good to know if any of this (admittedly older yet no less important)
 functionality is going to be supported. If the library is to concentrate
 solely on classless addressing (i.e. CIDR) please can this be stated in
 future revisions of the PEP.

I'll call this out in the PEP if necessary.  As mentioned elsewhere,
classful addressing is so long deprecated that I would expect it to
cause confusion if it was assumed.

>>> Classful addressing was deprecated more than 15 years ago!
>>>
>>> Quoting RFC 4632: "With the full deployment of CIDR on the Internet, such
>>> scenarios are no longer operationally relevant."
>>
>> Interesting as evidence of classful IPv4 behaviour seems fairly pervasive
>> in current IP stacks and software that supports IPv4 addressing (e.g.
>> PostgreSQL inet and cidr data types).
>
> PostgreSQL's inet type stores a host address and optionally a network mask.
> It's cidr type stores a network address and mask.  Neither of them are
> classful.
>
>>
>> Here's an excerpt from the 'ifconfig' man page (taken from an Ubuntu 9.04
>> install) :-
>> netmask addr
>>
>> Set the IP network mask for this interface. This value defaults to the
>> usual class A, B or C network mask (as derived from the interface IP
>> address). but it can be set to any value.
>
> Since the network mask can be set to any legal value, that means it's stored
> as CIDR.  It falls back on the classful network mask as a default.
> Undoubtedly that was useful when ifconfig was updated for CIDR.  There were
> still many classful networks and it needed to retain backward
> compatibility.  After all, ifconfig is around 25 years old, and CIDR is only
> 16.
>
> Today, all IP networks are classless (CIDR), and a system administrator
> would have to do extra work to figure out if the default value happened to
> be just right for the network they're setting up.
>
>>
>>  The point being that you can't always assume /32 implicitly for all use
>> cases.
>
> Certainly, which is why the user can explicitly set the netmask.
>
>>
>> Here is how IP addresses without an explicit prefix or netmask are
>> currently handled :-
>>
>> >>> import ipaddr
>> >>> ipaddr.IPv4Network('10.0.0.1')
>> IPv4Network('10.0.0.1/32')
>>
>> It may not be something we want to support (you could always force the end
>> user to specify a prefix or netmask explicitly). This is fair enough, but
>> let's indicate that it's a considered choice. Somewhere in the PEP text is
>> might be a good place for treatment of this topic.
>
> +1 on forcing the user to specify a netmask explicitly and documenting it.

-(1/0) forcing a user to include a prefixlen when creating a network
object doesn't actually serve any useful purpose. when dealing with
network objects, it's very useful (and common) to assume a /32 prefix
length when none is supplied.

Cheers,
/peter

> --
> Daniel Stutzbach, Ph.D.
> President, Stutzbach Enterprises, LLC
>
> ___
> 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 review.

2009-09-26 Thread Steven D'Aprano 
On Sun, 27 Sep 2009 03:44:45 am Martin v. Löwis wrote:
> >  - Masks are also 32- (128-) bit integers, which happen to have the
> >property that their leftmost N bits are all zero and the rest
> > are all one.
>
> As a side note, I would be in favor of dropping the concept of a mask
> from the library, and only support a prefix length.

-1

> IPv6 doesn't support masks at all, and even for IPv4, I think there
> are conventions (if not RFCs) against using them in a way that does
> not correspond to a prefix length.

Then the module should only support netmasks of the form 
(say) '255.255.255.224' (equivalent to "/27"), and reject those 
like "255.3.255.255". It currently accepts them.

Many applications still display netmasks in dot-quad form, and I would 
be terribly annoyed if I had to count the bits myself before passing it 
to IPv4Address.



-- 
Steven D'Aprano
___
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 review.

2009-09-26 Thread Steven D'Aprano 
On Sat, 26 Sep 2009 11:23:14 pm Barry Scott wrote:

> I've seen user interfaces accept 192.168.1.1/24 as a short cut
> to set the ipaddr and netmask on an interface.
>
> For that use being able to parse that string into an IP Address and
> a Net Mask is what they want.

I think you're at least the second person who has requested this 
functionality, or something similar.


> If this is a common idiom having a utility function that returned
> an IPv4Address('192.168.1.1') and IPv4Network('192.168.0.0')
> would be useful.
>
> If someone really thinks that '192.168.1.1/16' is a network any
> good UI should detect it is invalid report that to the user.

Currently the ipaddr module accepts that without complaint:

>>> ipaddr.IPv4Network('192.168.1.1/16')
IPv4Network('192.168.1.1/16')

The current behaviour is confusing to me. For example:

>>> netw1 = ipaddr.IPv4Network('192.168.1.1/24')
>>> netw2 = ipaddr.IPv4Network('192.168.1.0/24')
>>> netw1 == netw2
False
>>> list(netw1) == list(netw2)
True

Two networks, containing exactly the same range of addresses, but they 
don't compare equal. I'm not convinced that netw1 should even be 
allowed, but if it is, surely it should be turned into canonical form 
netw2? E.g. I would expect this:

>>> ipaddr.IPv4Network('192.168.1.1/24')
IPv4Network('192.168.1.0/24')

but that's not what it does.


-- 
Steven D'Aprano
___
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] Python 2.7 Mac universal builds seem broken on trunk

2009-09-26 Thread Ned Deily 
In article <[email protected]>,
 Barry Scott  wrote:
> I'm working with http://svn.python.org/projects/python/trunk on Mac OS  
> X 10.6.1
> using Apples xcode gcc 4.2.1.
> 
> When I run the following commands:
> 
>   ./configure --enable-framework --with-universal-archs=32-bit | tee  
> build.config.log
>   make clean all | tee build.make.log
> 
> I end up with a x86_64 Python image.
> 
> No matter what I use for archs its always the same.
> 
> I would expect to see -arch arg to GCC but it is not there.
> 
>   export CFLAG="-arch i386"
> 
> did not work either.
> 
> Am I doing something wrong or is this broken on trunk?

You need to add the enable-universalsdk parameter to configure:

  ... --enable-universalsdk=/Developer/SDKs/MacOSX10.6.sdk

Be aware, though, that universal build support on 10.6 is a bit of a 
work in progress as there are still some interesting unexplained 
universal build issues when building on Snow Leopard (see, for instance, 
the comments in http://bugs.python.org/issue6957).  At the moment, the 
focus is on getting 2.6.3 out the door and the standard installer for 
that will be built on 10.5.

-- 
 Ned Deily,
 [email protected]

___
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 review.

2009-09-26 Thread Peter Moody 
I again invite interested parties to continue this discussion on
[email protected].  we're pushing 250 messages on PEP
3144 at this point; well beyond what most folks would call a "long
open-ended discussion".

anyway:

> The current behaviour is confusing to me. For example:
>
 netw1 = ipaddr.IPv4Network('192.168.1.1/24')
 netw2 = ipaddr.IPv4Network('192.168.1.0/24')
 netw1 == netw2
> False
 list(netw1) == list(netw2)
> True

I think you're intentionally confusing yourself here.  192.168.1.1
clearly doesn't equal 192.168.1.0, so I don't know why you'd expect
192.168.1.1/24 to equal 192.168.1.0/24.

> Two networks, containing exactly the same range of addresses, but they
> don't compare equal. I'm not convinced that netw1 should even be
> allowed, but if it is, surely it should be turned into canonical form
> netw2? E.g. I would expect this:
>
 ipaddr.IPv4Network('192.168.1.1/24')
> IPv4Network('192.168.1.0/24')
>
> but that's not what it does.

now you're confusing me as before you've asked for this to either:

 1. Raise an exception
 2. Return two objects.

your unconfusing (to you) example does neither one of those.


> --
> Steven D'Aprano
> ___
> 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-09-26 Thread Guido van Rossum 
I realize I'm late to this party, but this is just a naming issue, right?

For any network, there are two special addresses, one with the last
bits all zeros, one with the last bits all ones. We can call them A
and B, or network and broadcast, or zeros and ones, or whatever we
care. But their definitions are two well-defined functions for all
networks (assuming a network is defined as an IP address and a number
of bits), even if in an extreme case the functions return the same
value.

What is actually configured on a particular host to be the broadcast
address is a separate issue, even if *by convention* in most cases it
is given by one of the above functions -- the network object doesn't
care, the configuration object is something else (and outside the
scope of this PEP).

IMO "real life examples" don't matter for the definitions of the
functions, and I would personally be happy to name them network and
broadcast, since I know their definitions and their typical uses and
these match pretty closely. The expectation should be clearly set that
these are pure functions though and do not imply knowledge of the
configuration of any given host.

--Guido

On Sat, Sep 26, 2009 at 11:19 AM, "Martin v. Löwis"  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].
>> Real life example: network with a /31 mask.
>> There are only two hosts: 0 and 1
>> first host configures the other's host as broadcast address and vice versa.
>> NOTE - broadcasts are different here!
>
> This is RFC 3021. IIUC, it does not support directed broadcast; only
> link-local broadcast can be used on that link.
>
> So ISTM that .broadcast should raise an exception on a /31 network. Any
> installation that configures the partner as the broadcast address is
> broken (somebody correct me if I'm wrong).
>
>> Another real life examples include /32 networks on PPP. Just a 
>> point-to-point.
>> No need for broadcasts and networks, a host just have one IP address and
>> send all traffic via point-to-point link, no addressing is required there.
>> This is a working dialup configuration, it works for me, it works for you, 
>> probably.
>> It is not weird, it is common, it is used for PPPoE, for ADSL, for dialup.
>
> So where is that defined?
>
> 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/guido%40python.org
>



-- 
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
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] LAST CHANCE: PyCon 2010: Call for Proposals

2009-09-26 Thread Aahz 
Just four more days to propose a presentation!

Call for proposals -- PyCon 2010 -- 
===

Due date: October 1st, 2009

Want to showcase your skills as a Python Hacker? Want to have
hundreds of people see your talk on the subject of your choice? Have some
hot button issue you think the community needs to address, or have some
package, code or project you simply love talking about? Want to launch
your master plan to take over the world with python?

PyCon is your platform for getting the word out and teaching something
new to hundreds of people, face to face.

Previous PyCon conferences have had a broad range of presentations,
from reports on academic and commercial projects, tutorials on a broad
range of subjects and case studies. All conference speakers are volunteers
and come from a myriad of backgrounds. Some are new speakers, some
are old speakers. Everyone is welcome so bring your passion and your
code! We're looking to you to help us top the previous years of success
PyCon has had.

PyCon 2010 is looking for proposals to fill the formal presentation tracks.
The PyCon conference days will be February 19-22, 2010 in Atlanta,
Georgia, preceded by the tutorial days (February 17-18), and followed
by four days of development sprints (February 22-25).

Online proposal submission is open now! Proposals  will be accepted
through October 1st, with acceptance notifications coming out on
November 15th. For the detailed call for proposals, please see:

 

For videos of talks from previous years - check out:



We look forward to seeing you in Atlanta!
-- 
Aahz ([email protected])   <*> http://www.pythoncraft.com/

"Look, it's your affair if you want to play with five people, but don't
go calling it doubles."  --John Cleese anticipates Usenet
___
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 review.

2009-09-26 Thread Nick Coghlan 
Peter Moody wrote:
> I again invite interested parties to continue this discussion on
> [email protected].  we're pushing 250 messages on PEP
> 3144 at this point; well beyond what most folks would call a "long
> open-ended discussion".
> 
> anyway:
> 
>> The current behaviour is confusing to me. For example:
>>
> netw1 = ipaddr.IPv4Network('192.168.1.1/24')
> netw2 = ipaddr.IPv4Network('192.168.1.0/24')
> netw1 == netw2
>> False
> list(netw1) == list(netw2)
>> True
> 
> I think you're intentionally confusing yourself here.  192.168.1.1
> clearly doesn't equal 192.168.1.0, so I don't know why you'd expect
> 192.168.1.1/24 to equal 192.168.1.0/24.

No, this is exactly the "dual purpose" nature of IPNetwork that people
have been complaining about: 192.168.1.1 & 255.255.255.0 == 192.168.1.0
& 255.255.255.0, so the two objects describe the exact same network, but
the network objects don't currently respect their own netmask, instead
remembering which particular host happened to be used to derive the
network ID.

"Arbitrary network host with associated netmask" and "IP Network" are
different concepts, but the library currently uses a single class
interface (IPNetwork) for both of them.

What we're asking for is for the "ip" attribute to be removed from IP
Network, with the constructor either forgetting the host IP that was
used to derive the network address, or else only accepting the correct
network address in the constructor and providing a separate helper
function or class method to create an IPNetwork object from an arbitrary
hostname.

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 review.

2009-09-26 Thread Peter Moody 
On Sat, Sep 26, 2009 at 10:38 PM, Nick Coghlan  wrote:
> Peter Moody wrote:
>> I again invite interested parties to continue this discussion on
>> [email protected].  we're pushing 250 messages on PEP
>> 3144 at this point; well beyond what most folks would call a "long
>> open-ended discussion".
>>
>> anyway:
>>
>>> The current behaviour is confusing to me. For example:
>>>
>> netw1 = ipaddr.IPv4Network('192.168.1.1/24')
>> netw2 = ipaddr.IPv4Network('192.168.1.0/24')
>> netw1 == netw2
>>> False
>> list(netw1) == list(netw2)
>>> True
>>
>> I think you're intentionally confusing yourself here.  192.168.1.1
>> clearly doesn't equal 192.168.1.0, so I don't know why you'd expect
>> 192.168.1.1/24 to equal 192.168.1.0/24.
>
> No, this is exactly the "dual purpose" nature of IPNetwork that people
> have been complaining about: 192.168.1.1 & 255.255.255.0 == 192.168.1.0
> & 255.255.255.0, so the two objects describe the exact same network, but
> the network objects don't currently respect their own netmask, instead
> remembering which particular host happened to be used to derive the
> network ID.
>
> "Arbitrary network host with associated netmask" and "IP Network" are
> different concepts, but the library currently uses a single class
> interface (IPNetwork) for both of them.
>
> What we're asking for is for the "ip" attribute to be removed from IP
> Network, with the constructor either forgetting the host IP that was
> used to derive the network address, or else only accepting the correct
> network address in the constructor and providing a separate helper
> function or class method to create an IPNetwork object from an arbitrary
> hostname.

what you want is strict=True, just checked in. I've been meaning to
send an update to the PEP explaining why this choice was made. I'm
hoping this will ameliorate your confusion.

Cheers,
/peter

> 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 review.

2009-09-26 Thread Nick Coghlan 
Peter Moody wrote:
> what you want is strict=True, just checked in. I've been meaning to
> send an update to the PEP explaining why this choice was made. I'm
> hoping this will ameliorate your confusion.

If the ip property remains and equality is still broken as Steven
describes, then no, it won't really alleviate my concerns.

I've also previously registered my objections to using a boolean flag
for this instead of a separate method.

However, I'll wait and see what the PEP update says before commenting
further.

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 review.

2009-09-26 Thread Martin v. Löwis 
>> As a side note, I would be in favor of dropping the concept of a mask
>> from the library, and only support a prefix length.
> 
> -1
> 
>> IPv6 doesn't support masks at all, and even for IPv4, I think there
>> are conventions (if not RFCs) against using them in a way that does
>> not correspond to a prefix length.
> 
> Then the module should only support netmasks of the form 
> (say) '255.255.255.224' (equivalent to "/27"), and reject those 
> like "255.3.255.255". It currently accepts them.
> 
> Many applications still display netmasks in dot-quad form, and I would 
> be terribly annoyed if I had to count the bits myself before passing it 
> to IPv4Address.

I wouldn't ask for that: it should certainly be possible to supply
masks. However, I would want to reject masks that don't correspond to
a prefix, and have only the prefix length in the internal representation.

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