Re: [Python-Dev] PEP 3144 review.

Antoine Pitrou writes: > > An IPv4Address with 'network' and 'mask' attributes that could be > > None would also not complicate the API, IMO, and would handle both > > of these use cases. > > But it would be confusing and conceptually bizarre, because an address (in > usually accepted termi

Re: [Python-Dev] PEP 3144 review.

I haven't looked closedly at the reference implementation, and my experience is small. So take this as "POLA to the naive new user of the API" discussion. Scott Dial writes: > This example here solidifies my support of RDM's suggestion of there > being 3 types: > > IPv4Address > IP

Re: [Python-Dev] PEP 3144 review.

I'd like to see more clear direction for this. Is it a string manipulation library, or an IP address library? There are ONLY TWO types of IP representations: 1. Network = 32 bit number AND 32 bit mask. That is the binary AND. The mask needs to be preserved, but not the network portion. Any library

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=True" (or "

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

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 is an invitation-only

Re: [Python-Dev] PEP 3144 review.

On Tue, Sep 15, 2009 at 5:33 PM, Antoine Pitrou wrote: > Antoine Pitrou pitrou.net> writes: >> >> 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

Re: [Python-Dev] PEP 3144 review.

On Tue, Sep 15, 2009 at 6:02 PM, Eric Smith wrote: > Antoine Pitrou wrote: >> >> Peter Moody hda3.com> writes: >>> >>> 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 pron

Re: [Python-Dev] PEP 3144 review.

Antoine Pitrou wrote: Antoine Pitrou pitrou.net> writes: 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 the

Re: [Python-Dev] PEP 3144 review.

Antoine Pitrou wrote: Peter Moody hda3.com> writes: 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 disagr

Re: [Python-Dev] PEP 3144 review.

Antoine Pitrou pitrou.net> writes: > > 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 op

Re: [Python-Dev] PEP 3144 review.

Peter Moody hda3.com> writes: > > 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 y

Re: [Python-Dev] PEP 3144 review.

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

Re: [Python-Dev] PEP 3144 review.

Sebastian Rittau wrote: > On Tue, Sep 15, 2009 at 01:16:06PM -0400, Scott Dial wrote: > net = ipaddr.IPNetwork("10.1.2.3/255.255.240.0") >> But then, I was dumbfounded as to how I could get the gateway IP from >> this IPNetwork object. > > Well, you can't. There is no way to determine a gatewa

Re: [Python-Dev] PEP 3144 review.

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 err

Re: [Python-Dev] PEP 3144 review.

On Tue, 15 Sep 2009 at 21:58, Antoine Pitrou wrote: Le mardi 15 septembre 2009 ?? 15:48 -0400, R. David Murray a ??crit : It's useful functionality is parsing/validating an address+mask, rendering as address+mask, and being able to get the associated IP and network objects from it. It's a smal

Re: [Python-Dev] PEP 3144 review.

On Tue, Sep 15, 2009 at 1:34 PM, Daniel Fetchinson wrote: 188 (check that, 190) people have downloaded the 2.0 release in the last week (numbers publicly available from the code.google.com). I can't tell you how many (if any) have downloaded it via svn. >>> >>> Downloading and using

Re: [Python-Dev] PEP 3144 review.

>>> 188 (check that, 190) people have downloaded the 2.0 release in the >>> last week (numbers publicly available from the code.google.com). I >>> can't tell you how many (if any) have downloaded it via svn. >> >> Downloading and using are not the same thing. > > Correct, but there is a strong posi

Re: [Python-Dev] PEP 3144 review.

Peter Moody wrote: On Tue, Sep 15, 2009 at 11:33 AM, Jake McGuire wrote: Downloading and using are not the same thing. Correct, but there is a strong positive correlation between the two. If you have a better method for determining what you would consider an appropriate level of usage, I'm

Re: [Python-Dev] PEP 3144 review.

> What's the opinion of the other interested party or parties? I don't > want a repeat of the events last time, where we had to pull it at the > last time because there hadn't been enough discussion. I'm slightly interested, but didn't have the time to review the PEP at all yet. I may be able to d

Re: [Python-Dev] PEP 3144 review.

Le mardi 15 septembre 2009 à 15:48 -0400, R. David Murray a écrit : > > It's useful functionality is parsing/validating an address+mask, rendering > as address+mask, and being able to get the associated IP and network objects > from it. It's a small class, but useful, IMO. If it's only about par

Re: [Python-Dev] PEP 3144 review.

On Tue, 15 Sep 2009 at 19:20, Antoine Pitrou wrote: R. David Murray bitdance.com> writes: I would find that acceptable but sub-optimal. Most of my use cases (which involve manipulating router and firewall configuration files) would then start by making a little class named AddressWithNetwork t

Re: [Python-Dev] PEP 3144 review.

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") > ... > ipaddr.IPAddressIPValidationError: '98.223.189.24/255.255.240.0' is not > a valid

Re: [Python-Dev] PEP 3144 review.

R. David Murray bitdance.com> writes: > > I would find that acceptable but sub-optimal. Most of my use cases > (which involve manipulating router and firewall configuration files) would > then start by making a little class named AddressWithNetwork to hold the > tuple returned by your parse func

Re: [Python-Dev] PEP 3144 review.

Peter Moody wrote: > but that's what's being suggested here for networks. > ipaddr.IPv4Network('1.1.1.1/24')[0][1][2][3]... This example here solidifies my support of RDM's suggestion of there being 3 types: IPv4Address IPv4AddressWithNetwork (or as he called it: IPv4AddressWithMask

Re: [Python-Dev] PEP 3144 review.

On Tue, 15 Sep 2009 at 18:43, Antoine Pitrou wrote: R. David Murray bitdance.com> writes: x = IPv4AddressWithMask('192.168.1.1/24') x.network == IPv4Network('192.168.1.0/24') x.network[1] == x I don't think we need an IPAddressWithMask which would just complicate the API witho

Re: [Python-Dev] PEP 3144 review.

On Tue, Sep 15, 2009 at 11:49 AM, Stephen J. Turnbull wrote: > Antoine Pitrou writes: > >  > Speaking as a non-network specialist, it actually looks logical to >  > me to be given an address if I iterate over a network (the same way >  > that, if I iterate on a list, I get individual elements, not

Re: [Python-Dev] PEP 3144 review.

R. David Murray bitdance.com> writes: > > x = IPv4AddressWithMask('192.168.1.1/24') > x.network == IPv4Network('192.168.1.0/24') > x.network[1] == x I don't think we need an IPAddressWithMask which would just complicate the API without any obvious benefit. We just need a factory f

Re: [Python-Dev] PEP 3144 review.

Scott Dial writes: > ipaddr.IPv4Network('1.1.1.0/24')[0] == ipaddr.IPv4Network('1.1.1.0/24') So foo returns True? def foo(): a = ipaddr.IPv4Network('1.1.1.0/24') return a[0] == a That seems ... weird. Maybe you committed a typo? ___ Python

Re: [Python-Dev] PEP 3144 review.

Antoine Pitrou writes: > Speaking as a non-network specialist, it actually looks logical to > me to be given an address if I iterate over a network (the same way > that, if I iterate on a list, I get individual elements, not > 1-element sublists). But if you iterate over a string you get one

Re: [Python-Dev] PEP 3144 review.

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 >> > wrote: >> >> >> >> What's the opinion of the other interested part

Re: [Python-Dev] PEP 3144 review.

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 > wrote: > >> > >> What's the opinion of the other interested party or parties? I don't > >> want a repeat of the events last time,

Re: [Python-Dev] PEP 3144 review.

On Tue, 15 Sep 2009 at 14:16, Scott Dial wrote: In other words, I don't see why obtaining a host address would *not* retain the hostmask from the network it was obtained from. I am not disagreeing with it being an individual address. I am disagreeing that IPNetwork itself already does represent i

Re: [Python-Dev] PEP 3144 review.

On Tue, Sep 15, 2009 at 12:16 PM, Scott Dial > wrote: > >>> addr = ipaddr.IPAddress("10.1.2.3/255.255.240.0") > ... > ipaddr.IPAddressIPValidationError: '98.223.189.24/255.255.240.0' is not > a valid address (hint, it's probably a network) > > Because, it *is* a address of a host on a network. I

Re: [Python-Dev] PEP 3145 (With Contents)

On 04:25 pm, eric.pru...@gmail.com wrote: I'm bumping this PEP again in hopes of getting some feedback. Thanks, Eric On Tue, Sep 8, 2009 at 23:52, Eric Pruitt wrote: PEP: 3145 Title: Asynchronous I/O For subprocess.Popen Author: (James) Eric Pruitt, Charles R. McCreary, Josiah Carlson Type:

Re: [Python-Dev] PEP 3145 (With Contents)

Hello, I would like to know if your approach is based on Python 2.x or 3.x. Python 3.x has new API provisions, in the I/O layer, for non-blocking I/O and it would be nice if your work could fit in that framework. > >Popen can be made to act like a file by simply > >using the methods att

Re: [Python-Dev] PEP 3144 review.

Peter Moody wrote: > On Tue, Sep 15, 2009 at 10:16 AM, Scott Dial > wrote: >> In the end, I found the names IPNetwork/IPAddress and their >> instantiations confusing. ISTM that IPNetwork is overloaded and plays >> two roles of being an IPNetwork and being an IPAddressWithNetwork. And >> finally, i

Re: [Python-Dev] PEP 3144 review.

Scott Dial scottdial.com> writes: > > >>> gateway = net[1] > > I was then confused, because: > > >>> print(type(gateway)) > > > Which sorta blew my mind.. I fully expected to receive an IPNetwork back > from that operation. Speaking as a non-network specialist, it actually looks logical to m

Re: [Python-Dev] PEP 3144 review.

On Tue, Sep 15, 2009 at 10:16 AM, Scott Dial wrote: > R. David Murray wrote: >> On Tue, 15 Sep 2009 at 14:28, Antoine Pitrou wrote: >>> Andrew McNamara object-craft.com.au> writes:    >>> ipaddr.IPv4Network('192.168.1.1/16').network     IPv4Address('192.168.0.0') >>> >>> Er, does t

Re: [Python-Dev] PEP 3144 review.

On Tue, Sep 15, 2009 at 10:16 AM, Jake McGuire wrote: > On Mon, Sep 14, 2009 at 9:54 AM, Guido van Rossum wrote: >> >> What's the opinion of the other interested party or parties? I don't >> want a repeat of the events last time, where we had to pull it at the >> last time because there hadn't be

Re: [Python-Dev] PEP 3144 review.

On Mon, Sep 14, 2009 at 9:54 AM, Guido van Rossum wrote: > What's the opinion of the other interested party or parties? I don't > want a repeat of the events last time, where we had to pull it at the > last time because there hadn't been enough discussion. How many other people are using this l

Re: [Python-Dev] PEP 3144 review.

R. David Murray wrote: > On Tue, 15 Sep 2009 at 14:28, Antoine Pitrou wrote: >> Andrew McNamara object-craft.com.au> writes: >>> >>>>>> ipaddr.IPv4Network('192.168.1.1/16').network >>> IPv4Address('192.168.0.0') >> >> Er, does this mean that taking the `network` attribute from a network >>

Re: [Python-Dev] PEP 3145 (With Contents)

On Tue, Sep 15, 2009 at 12:25:35PM -0400, Eric Pruitt wrote: > A search for "python asynchronous subprocess" will turn up numerous > accounts of people IMHO there is no need to refer to a search. It'd be enough to say "There are many people...". > kernel 32 DLL Why not just name it kernel3

Re: [Python-Dev] PEP 3145 (With Contents)

I'm bumping this PEP again in hopes of getting some feedback. Thanks, Eric On Tue, Sep 8, 2009 at 23:52, Eric Pruitt wrote: > PEP: 3145 > Title: Asynchronous I/O For subprocess.Popen > Author: (James) Eric Pruitt, Charles R. McCreary, Josiah Carlson > Type: Standards Track > Content-Type: text/p

Re: [Python-Dev] PEP 3144 review.

On Tue, 15 Sep 2009 at 14:28, Antoine Pitrou wrote: Andrew McNamara object-craft.com.au> writes: >>> ipaddr.IPv4Network('192.168.1.1/16').network IPv4Address('192.168.0.0') Er, does this mean that taking the `network` attribute from a network object actually gives an address object (n

Re: [Python-Dev] PEP 3144 review.

Andrew McNamara object-craft.com.au> writes: > > >>> ipaddr.IPv4Network('192.168.1.1/16').network > IPv4Address('192.168.0.0') Er, does this mean that taking the `network` attribute from a network object actually gives an address object (not a network)? It looks horribly misleading to me

Re: [Python-Dev] Python 2.6.3

On 10 Sep, 2009, at 18:23, Ned Deily wrote: In article <9d506035-7c2d-4929-a134-e88eeb7b7...@python.org>, Barry Warsaw wrote: On Sep 9, 2009, at 1:29 PM, Ned Deily wrote: In article <11a6545d-7204-4f61-b55b-1cc77cb56...@python.org>, Barry Warsaw wrote: I still want to release by the 25th