Re: [Python-Dev] PEP 3144 review.

Andrew McNamara writes: > As the module stands, we have a pair of address-without-mask classes > called *Address, and a pair of address-with-mask classes called > *Network. So, sometimes when you want to record an *address* you use > a class called Network, and that class comes with a behaviou

Re: [Python-Dev] PEP 3144 review.

>> I argue that we're not actually adding any complexity: yes, we add >> a class (per protocol), but we then merely relocate functionality to >> clarify the intended use of the classes. > >And I argue the moving this functionality to new classes (and adding >new restrictions to existing classes) do

Re: [Python-Dev] PEP 3144 review.

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Scott Dial wrote: > The purpose is to avoid conflating IPNetwork with an IPAddress that has > a mask. I'm not confused by anything in this discussion except the repeated harping on the (to me imaginary) concept of "address with a mask". Conceptually:

Re: [Python-Dev] PEP 3144 review.

Peter Moody wrote: > On Wed, Sep 16, 2009 at 8:21 PM, Andrew McNamara > wrote: I think we're in a painful middle ground now - we should either go back to the idea of a single class (per protocol), or make the distinctions clear (networks are containers and addresses are singletons).

Re: [Python-Dev] PEP 3144 review.

On Wed, Sep 16, 2009 at 8:36 PM, Peter Moody wrote: > On Wed, Sep 16, 2009 at 8:21 PM, Andrew McNamara > wrote: I think we're in a painful middle ground now - we should either go back to the idea of a single class (per protocol), or make the distinctions clear (networks are contain

Re: [Python-Dev] PEP 3144 review.

On Wed, Sep 16, 2009 at 8:21 PM, Andrew McNamara wrote: >>> I think we're in a painful middle ground now - we should either go back >>> to the idea of a single class (per protocol), or make the distinctions >>> clear (networks are containers and addresses are singletons). >>> >>> Personally, I thi

Re: [Python-Dev] PEP 3144 review.

>Another way to approach this would be for the Address object to >potentially have a 'network' attribute referencing a Network object. Yes - that's reasonable. >Then there are only two classes, but three use cases are covered: > >1) a Network > >2) a plain, network-agnostic Address with network =

Re: [Python-Dev] PEP 3144 review.

On Wed, Sep 16, 2009 at 7:48 PM, Greg Ewing wrote: > Peter Moody wrote: >> >> I don't see where the confusion lies.  You have an address >> + netmask. ergo, you have a Network object.  The single address that >> defines the base address (most commonly referred to as the network >> address) is an A

Re: [Python-Dev] PEP 3144 review.

>> I think we're in a painful middle ground now - we should either go back >> to the idea of a single class (per protocol), or make the distinctions >> clear (networks are containers and addresses are singletons). >> >> Personally, I think I would be happy with a single class (but I suspect >> that

Re: [Python-Dev] PEP 3144 review.

Peter Moody wrote: I don't see where the confusion lies. You have an address + netmask. ergo, you have a Network object. The single address that defines the base address (most commonly referred to as the network address) is an Address object. there is no netmask associated with that single addr

Re: [Python-Dev] PEP 3144 review.

Andrew McNamara wrote: I also suggest the AddressWithMask classes not have any network/container behaviours for a similar reason. If the developer needs these, the .network attribute is only a lookup away. Another way to approach this would be for the Address object to potentially have a 'netw

Re: [Python-Dev] PEP 3144 review.

On Wed, Sep 16, 2009 at 6:32 PM, Andrew McNamara wrote: >>This proposal actually leads to 6 entities (3 for IPv4 and 3 for IPv6). > > Yes, I know - I was just trying to keep to the point. > >>It's still unclear to me what is gained by pulling AddressWithMask >>functionality out of the current netw

Re: [Python-Dev] PEP 3144 review.

>This proposal actually leads to 6 entities (3 for IPv4 and 3 for IPv6). Yes, I know - I was just trying to keep to the point. >It's still unclear to me what is gained by pulling AddressWithMask >functionality out of the current network classes. It's easy enough for >the concerned developer who t

Re: [Python-Dev] PEP 3144 review.

On Wed, Sep 16, 2009 at 5:30 PM, Andrew McNamara wrote: >>R. David Murray wrote: >> >>> A network is conventionally represented by an IP address in which the >>> bits corresponding to the one bits in the netmask are set to zero, plus >>> the netmask. >> >>Okay, that's clarified things for me, than

Re: [Python-Dev] PEP 3144 review.

>> Some people have claimed that the gateway address of a >> network isn't necessarily the zero address in that network. It almost never is - conventions vary, but it is often the network address plus one, or the broadcast address minus one. >I'll go further: I don't think it's even legal for the

Re: [Python-Dev] PEP 3144 review.

>R. David Murray wrote: > >> A network is conventionally represented by an IP address in which the >> bits corresponding to the one bits in the netmask are set to zero, plus >> the netmask. > >Okay, that's clarified things for me, thanks. Put another way, an "Address" describes a single end-point

Re: [Python-Dev] PEP 3144 review.

R. David Murray wrote: A network is conventionally represented by an IP address in which the bits corresponding to the one bits in the netmask are set to zero, plus the netmask. Okay, that's clarified things for me, thanks. In that case, we shouldn't be talking about a "network address" at al

Re: [Python-Dev] PEP 3144 review.

On Wed, Sep 16, 2009 at 4:59 PM, Greg Ewing wrote: > Some people have claimed that the gateway address of a > network isn't necessarily the zero address in that network. > I'll go further: I don't think it's even legal for the gateway address to be the zero address of the network (and I used to p

Re: [Python-Dev] PEP 3144 review.

On Thu, 17 Sep 2009 at 09:59, Greg Ewing wrote: Nick Coghlan wrote: Or, to put it another way, given an arbitrary host in a network (e.g. your own machine or the default gateway) and the netmask for that network, calculate the network address. Some people have claimed that the gateway addr

Re: [Python-Dev] PEP 3144 review.

On 15Sep2009 13:16, Scott Dial wrote: | It just happened that I needed a tool today to calculate the gateway IP | for an interface, and I took it as an opportunity to try out this ipaddr | module. I'll attempt to relate my experience below... | | I have to concur with the opinions above. I was ve

Re: [Python-Dev] PEP 3144 review.

Eric. "Greg Ewing" wrote: >Nick Coghlan wrote: > >> Or, to put it another way, given an arbitrary host in a network (e.g. >> your own machine or the default gateway) and the netmask for that >> network, calculate the network address. > >Some people have claimed that the gateway address of a >ne

Re: [Python-Dev] PEP 3144 review.

Nick Coghlan wrote: Or, to put it another way, given an arbitrary host in a network (e.g. your own machine or the default gateway) and the netmask for that network, calculate the network address. Some people have claimed that the gateway address of a network isn't necessarily the zero address

Re: [Python-Dev] PEP 3144 review.

Peter Moody wrote: On Wed, Sep 16, 2009 at 1:35 PM, Antoine Pitrou wrote: Le Mon, 14 Sep 2009 09:44:12 -0700, Peter Moody a écrit : Folks, Guido, I believe PEP 3144 is ready for your review. When you get a chance, can you take a look/make a pronouncement? Besides what has already been said

Re: [Python-Dev] PEP 3144 review.

On Wed, Sep 16, 2009 at 1:35 PM, Antoine Pitrou wrote: > Le Mon, 14 Sep 2009 09:44:12 -0700, Peter Moody a écrit : >> Folks, Guido, >> >> I believe PEP 3144 is ready for your review.  When you get a chance, can >> you take a look/make a pronouncement? > > Besides what has already been said in the

Re: [Python-Dev] PEP 3144 review.

Le Mon, 14 Sep 2009 09:44:12 -0700, Peter Moody a écrit : > Folks, Guido, > > I believe PEP 3144 is ready for your review. When you get a chance, can > you take a look/make a pronouncement? Besides what has already been said in the thread, I have a bunch of comments: It should be noted

Re: [Python-Dev] pthreads, fork, import, and execvp

On Wed, Sep 9, 2009 at 23:56, Nick Coghlan wrote: > Thomas Wouters wrote: > > Your idea of making this an API called a 'fork lock' or something > > sounds good (though I think it needs a better name. PyBeforeFork & > > PyAfterFork?). The subprocess module, for example, disables garb

Re: [Python-Dev] Python 2.6.3

On 16 Sep, 2009, at 14:52, Barry Warsaw wrote: On Sep 15, 2009, at 9:53 AM, Ronald Oussoren wrote: The IDLE issue is IMHO a release blocker, as is issue 6851. So that leaves 4 release blockers for 2.6.3. Three of these are assigned to Ronald. Ronald are you sure you will have time to fi

Re: [Python-Dev] Python 2.6.3

On Wed, Sep 16, 2009 at 05:52, Barry Warsaw wrote: > On Sep 15, 2009, at 9:53 AM, Ronald Oussoren wrote: > >> The IDLE issue is IMHO a release blocker, as is issue 6851. > > So that leaves 4 release blockers for 2.6.3.  Three of these are assigned to > Ronald.  Ronald are you sure you will have ti

Re: [Python-Dev] displayhook behavior in pdb

Guido van Rossum schrieb: > >> Now, what is the lesser evil? > >> > >> > > > > IMO not showing the extraneous Nones is preferable. > > I agree (although I don't use pdb, so my view shouldn't be given too > much weight...) > > > I *do* use pdb a lot, and I agree that

Re: [Python-Dev] PEP 3144 review.

On Wed, 16 Sep 2009 at 12:04, Paul Moore wrote: Of course, the discussion seems to imply that even the experts have a confused view, so maybe I'm being too ambitious here :-) Part of the problem, as we discovered in the last go-round on ipaddr, is that there are two types of experts: those who

Re: [Python-Dev] PEP 3144 review.

On Wed, 16 Sep 2009 at 12:50, exar...@twistedmatrix.com wrote: On 11:10 am, ncogh...@gmail.com wrote: Or, to put it another way, given an arbitrary host in a network (e.g. your own machine or the default gateway) and the netmask for that network, calculate the network address. With a "lax" pars

Re: [Python-Dev] displayhook behavior in pdb

On Wed, Sep 16, 2009 at 3:48 AM, Paul Moore wrote: > 2009/9/16 Michael Foord : > > Georg Brandl wrote: > >> > >> May I have a short vote on this issue: > >> > >> http://bugs.python.org/issue6903 > >> > >> In short, pdb (since 2.6) uses a separate displayhook in order to avoid > >> _ being reass

Re: [Python-Dev] Python Language Summit #2 in February

A.M. Kuchling wrote: We therefore need to decide what those three sessions should be about. Please discuss on python-dev and hopefully we can arrive at some consensus on topics of reasonably wide current interest. (See http://us.pycon.org/2009/about/summits/language/ for a reminder of last year'

Re: [Python-Dev] PEP 3144 review.

exar...@twistedmatrix.com wrote: > On 11:10 am, ncogh...@gmail.com wrote: >> If the default IPNetwork constructor was made more strict, then this >> functionality would have to be made available another way (probably as >> an alternate constructor like IPNetwork.from_host_address rather than as >>

Re: [Python-Dev] Python 2.6.3

On Sep 15, 2009, at 9:53 AM, Ronald Oussoren wrote: The IDLE issue is IMHO a release blocker, as is issue 6851. So that leaves 4 release blockers for 2.6.3. Three of these are assigned to Ronald. Ronald are you sure you will have time to fix these by then? The one I'm still uncertain on

Re: [Python-Dev] PEP 3144 review.

On 11:10 am, ncogh...@gmail.com wrote: Steven D'Aprano wrote: I've been skimming emails in this thread, since most of them go over my head and I have no current need for an ipaddress module. But one thing I noticed stands out and needs commenting on: On Wed, 16 Sep 2009 11:05:26 am Peter Moody

Re: [Python-Dev] Python Language Summit #2 in February

On Sep 16, 2009, at 7:53 AM, Antoine Pitrou wrote: Of course, all this will perhaps have been discussed before the summit. Sure, but not resolved. :) I do think stdlib evolution should be high on the list of topics. -B PGP.sig Description: This is a digitally signed message part ___

Re: [Python-Dev] Python Language Summit #2 in February

Antoine Pitrou wrote: Michael Foord voidspace.org.uk> writes: Given the long discussion on the stdlib-sig it seems like a discussion of the standard library would be useful. Potential topics include (some of which partially overlap each other): [snip] Let me suggest the following a

Re: [Python-Dev] Python Language Summit #2 in February

Michael Foord voidspace.org.uk> writes: > > Given the long discussion on the stdlib-sig it seems like a discussion > of the standard library would be useful. Potential topics include (some > of which partially overlap each other): > [snip] Let me suggest the following additional point: * Cla

Re: [Python-Dev] PEP 3144 review.

On Tue, Sep 15, 2009 at 11:44 AM, Jake McGuire wrote: > On Tue, Sep 15, 2009 at 11:36 AM, Peter Moody wrote: > >> On Tue, Sep 15, 2009 at 11:33 AM, Jake McGuire >> wrote: >> > On Tue, Sep 15, 2009 at 10:36 AM, Peter Moody wrote: >> >> >> >> On Tue, Sep 15, 2009 at 10:16 AM, Jake McGuire >> wr

Re: [Python-Dev] PEP 3144 review.

On Tue, Sep 15, 2009 at 11:36 AM, Peter Moody wrote: > On Tue, Sep 15, 2009 at 11:33 AM, Jake McGuire wrote: > > On Tue, Sep 15, 2009 at 10:36 AM, Peter Moody wrote: > >> > >> On Tue, Sep 15, 2009 at 10:16 AM, Jake McGuire > wrote: > >> > On Mon, Sep 14, 2009 at 9:54 AM, Guido van Rossum > >>

Re: [Python-Dev] PEP 3144 review.

Stephen J. Turnbull xemacs.org> writes: > > Rather, don't you want to just give IPv4Address an attribute > 'network'? This could then be filled in by the indexing method on > IPv4Network. It doesn't make sense to me. An address, conceptually, doesn't have a "network". If I say "213.5.4.68", it

Re: [Python-Dev] PEP 3144 review.

Steven D'Aprano wrote: > I've been skimming emails in this thread, since most of them go over my > head and I have no current need for an ipaddress module. But one thing > I noticed stands out and needs commenting on: > > On Wed, 16 Sep 2009 11:05:26 am Peter Moody wrote: >> On Tue, Sep 15, 2009

Re: [Python-Dev] PEP 3144 review.

2009/9/16 Steven D'Aprano : > I've been skimming emails in this thread, since most of them go over my > head and I have no current need for an ipaddress module. Same here. > As an outsider to this argument, and judging from the lack of agreement > here, it seems to me that some (many? most?) deve

Re: [Python-Dev] Python Language Summit #2 in February

A.M. Kuchling wrote: PyCon 2010 will be February 19-21 2010 in Atlanta, Georgia (US). Van Lindberg, PyCon chair, has approved having another Python Language Summit on Thursday, February 18 2010. The web page for it is The Python Language Summit

Re: [Python-Dev] PEP 3144 review.

I've been skimming emails in this thread, since most of them go over my head and I have no current need for an ipaddress module. But one thing I noticed stands out and needs commenting on: On Wed, 16 Sep 2009 11:05:26 am Peter Moody wrote: > On Tue, Sep 15, 2009 at 6:02 PM, Eric Smith wrote: >

Re: [Python-Dev] displayhook behavior in pdb

2009/9/16 Michael Foord : > Georg Brandl wrote: >> >> May I have a short vote on this issue: >> >>   http://bugs.python.org/issue6903 >> >> In short, pdb (since 2.6) uses a separate displayhook in order to avoid >> _ being reassigned (which screws up debugging apps that use _ as gettext). >> In tha

Re: [Python-Dev] displayhook behavior in pdb

Georg Brandl wrote: May I have a short vote on this issue: http://bugs.python.org/issue6903 In short, pdb (since 2.6) uses a separate displayhook in order to avoid _ being reassigned (which screws up debugging apps that use _ as gettext). In that displayhook, I did not add the suppression of

[Python-Dev] displayhook behavior in pdb

May I have a short vote on this issue: http://bugs.python.org/issue6903 In short, pdb (since 2.6) uses a separate displayhook in order to avoid _ being reassigned (which screws up debugging apps that use _ as gettext). In that displayhook, I did not add the suppression of printing None, as it

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

On Wed, Aug 19, 2009 at 02:28:38PM -0400, 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

Re: [Python-Dev] PEP 3144 review.

On Tue, Sep 15, 2009 at 09:35:13PM +0200, Sebastian Rittau wrote: > On Tue, Sep 15, 2009 at 01:16:06PM -0400, Scott Dial wrote: > > > I have to concur with the opinions above. I was very confused by the > > following error: > > > > >>> addr = ipaddr.IPAddress("10.1.2.3/255.255.240.0") > > ... > >

Re: [Python-Dev] PEP 3144 review.

>>> I don't see any valid reason for entering a network as >>> "192.168.1.1/24" rather >>> than the canonical "192.168.1.0/24". The former might indicate a >>> typing error >>> or >>> a mental slip, so let's be helpful and signal it to the user. >> >> Or perhaps there can be an optional "strict=Tru