Re: [Python-Dev] Python 2.6.3

[Ronald Oussoren]

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, but I'd be willing to move the
rc
to Monday the 21st.  We're really just trying to avoid a brown bag
moment, so that should give us enough time to double check the
releases.


The recent release of OS X 10.6 (Snow Leopard) has triggered a fair
amount of 2.6 bug tracker activity, since 10.6 now includes 2.6
(2.6.1)
and a 64-bit version at that.   A number of patches have either just
been checked-in over the past couple of weeks or are getting some
exposure before check-in.  Given the timing and the (appropriate)
infrequency of 2.6.x releases, I think it would be unfortunate to  
push

2.6.3 out the door without ensuring that it works well on 10.6.
Therefore, I propose that 2.6.3 should have 10.6 compatibility as a
"release goal".

Without trying to put Ronald on the spot (too much!), it would be a
good
idea to get his assessment where things stand wrt 2.6 on 10.6 before
setting a final release date.


I'm hoping that Python won't have any issues building and running on
10.6, but I don't have it yet so I can't personally test it out.

How would you quantify "works well"?  Do you have any thoughts on
tests you'd run other than the standard test suite?  If 2.6.3 is  
shown

to pass its test suite on 10.5.x, is that good enough?  Are the
specific bug fixes necessary for 10.6?


Running the standard test suite on 10.6 and seeing no regressions
compared to the same suite on 10.5.x seems a reasonable necessary
requirement.  We have the resources to do that.  Beyond that, as  
Ronald
suggests, I think it important to go through the open issues in the  
next

couple of days and identify and flag any potential release-blockers
(besides the IDLE problem already mentioned).


The IDLE issue is IMHO a release blocker, as is issue 6851.



One other open issue is 64-bit support in the python.org OS X  
installer.

There have been discussions and requests in the past and, with Apple
providing 64-bit out of the box in 10.6, it seems like it's time to
provide something on python.org as well.   One option: continue to
provide a 32-bit only installer for ppc and i386 for 10.3.9 and beyond
and add a second installer image with 3-way (ppc, i386, x86_64 but no
ppc64) 32/64 for 10.5 and beyond.   Ronald, is that your current
thinking?


64-bit support can wait until after 2.6.3 is released. I need time to  
work out what's needed go create a good installer (and not just  
running the current build-installer.py script because that includes to  
much for a binary that doesn't run on 10.3.9). That won't happen  
before 2.6.3 is released because I'm too thinly stretched even without  
working on that.


Ronald



smime.p7s
Description: S/MIME cryptographic signature
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 3144 review.

[Antoine Pitrou]

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.



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

Re: [Python-Dev] PEP 3144 review.

[R. David Murray]

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 (not a network)?
It looks horribly misleading to me.


That was my opinion, too.  I've always called that number the 'zero'
of the network, but other people said that it is usually called the
'network'.

I also find it odd to see a 'network' with an IP address of 192.168.1.1.
That looks like a host-address-plus-netmask to me, not a network
address.

--David
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

[Eric Pruitt]

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/plain
> Created: 04-Aug-2009
> Python-Version: 3.2
>
> Abstract:
>
>    In its present form, the subprocess.Popen implementation is prone to
>    dead-locking and blocking of the parent Python script while waiting on data
>    from the child process.
>
> Motivation:
>
>    A search for "python asynchronous subprocess" will turn up numerous
>    accounts of people wanting to execute a child process and communicate with
>    it from time to time reading only the data that is available instead of
>    blocking to wait for the program to produce data [1] [2] [3].  The current
>    behavior of the subprocess module is that when a user sends or receives
>    data via the stdin, stderr and stdout file objects, dead locks are common
>    and documented [4] [5].  While communicate can be used to alleviate some of
>    the buffering issues, it will still cause the parent process to block while
>    attempting to read data when none is available to be read from the child
>    process.
>
> Rationale:
>
>    There is a documented need for asynchronous, non-blocking functionality in
>    subprocess.Popen [6] [7] [2] [3].  Inclusion of the code would improve the
>    utility of the Python standard library that can be used on Unix based and
>    Windows builds of Python.  Practically every I/O object in Python has a
>    file-like wrapper of some sort.  Sockets already act as such and for
>    strings there is StringIO.  Popen can be made to act like a file by simply
>    using the methods attached the the subprocess.Popen.stderr, stdout and
>    stdin file-like objects.  But when using the read and write methods of
>    those options, you do not have the benefit of asynchronous I/O.  In the
>    proposed solution the wrapper wraps the asynchronous methods to mimic a
>    file object.
>
> Reference Implementation:
>
>    I have been maintaining a Google Code repository that contains all of my
>    changes including tests and documentation [9] as well as blog detailing
>    the problems I have come across in the development process [10].
>
>    I have been working on implementing non-blocking asynchronous I/O in the
>    subprocess.Popen module as well as a wrapper class for subprocess.Popen
>    that makes it so that an executed process can take the place of a file by
>    duplicating all of the methods and attributes that file objects have.
>
>    There are two base functions that have been added to the subprocess.Popen
>    class: Popen.send and Popen._recv, each with two separate implementations,
>    one for Windows and one for Unix based systems.  The Windows
>    implementation uses ctypes to access the functions needed to control pipes
>    in the kernel 32 DLL in an asynchronous manner.  On Unix based systems,
>    the Python interface for file control serves the same purpose.  The
>    different implementations of Popen.send and Popen._recv have identical
>    arguments to make code that uses these functions work across multiple
>    platforms.
>
>    When calling the Popen._recv function, it requires the pipe name be
>    passed as an argument so there exists the Popen.recv function that passes
>    selects stdout as the pipe for Popen._recv by default.  Popen.recv_err
>    selects stderr as the pipe by default. "Popen.recv" and "Popen.recv_err"
>    are much easier to read and understand than "Popen._recv('stdout' ..." and
>    "Popen._recv('stderr' ..." respectively.
>
>    Since the Popen._recv function does not wait on data to be produced
>    before returning a value, it may return empty bytes.  Popen.asyncread
>    handles this issue by returning all data read over a given time
>    interval.
>
>    The ProcessIOWrapper class uses the asyncread and asyncwrite functions to
>    allow a process to act like a file so that there are no blocking issues
>    that can arise from using the stdout and stdin file objects produced from
>    a subprocess.Popen call.
>
>
> References:
>
>    [1] [ python-Feature Requests-1191964 ] asynchronous Subprocess
>        http://mail.python.org/pipermail/python-bugs-list/2006-December/
>          036524.html
>
>    [2] Daily Life in an Ivory Basement : /feb-07/problems-with-subprocess
>        http://ivory.idyll.org/blog/feb-07/problems-with-subprocess
>
>    [3] How can I run an external command asynchronously from Python? - Stack
>        Overflow
>        http://stackoverflow.com/questions/636561/how-can-i-run-an-external-
>          command-asynchronously-from-python
>
>    [4] 18.1. subprocess - Subprocess management - Python v2.6.2 documentation
>        http://docs.python.org/library/subprocess.html#subprocess.Popen.wait
>
>    [5] 18.1. subprocess - Subprocess management - Pyth

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

[Oleg Broytmann]

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 kernel32.dll?

Oleg.
-- 
 Oleg Broytmannhttp://phd.pp.ru/p...@phd.pp.ru
   Programmers don't die, they just GOSUB without RETURN.
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 3144 review.

[Scott Dial]

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
>> object
>> actually gives an address object (not a network)?
>> It looks horribly misleading to me.
> 
> That was my opinion, too.  I've always called that number the 'zero'
> of the network, but other people said that it is usually called the
> 'network'.
> 
> I also find it odd to see a 'network' with an IP address of 192.168.1.1.
> That looks like a host-address-plus-netmask to me, not a network
> address.
> 

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 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 address (hint, it's probably a network)

Because, it *is* a address of a host on a network. I gave in and said:

>>> 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. It took me a while to figure out that you can
iterate over IPNetwork instances:

>>> 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. It is unclear to me why the network information
gets chucked by that operation. I foresee having to work around that in
real applications by doing something obnoxious like:

>>> actual_gateway = ipaddr.IPNetwork("%s/%s" % (gateway, addr.netmask))

But since I only actually needed the IP address for the gateway, it
fulfilled my needs.

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, it's unclear to me why iterating over a IPNetwork would not
produce a sequence of IPNetwork(/IPAddressWithNetwork) objects.

ISTM that if I started with an IPNetwork object, the API should always
return IPNetwork objects. If I want just an IPAddress object, then I can
always fetch the "ip" attribute to get that. Perhaps there is some
compelling conceptual argument as to why this is not correct, but it
seems like the API destroys information needlessly.

Just my opinion..

-- 
Scott Dial
sc...@scottdial.com
scod...@cs.indiana.edu
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 3144 review.

[Jake McGuire]

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 library?  I think it's hard to give
really useful feedback on an API without using it for some non-trivial task,
but maybe other people don't have this problem.

-jake
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 3144 review.

[Peter Moody]

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 been enough discussion.
>
> How many other people are using this library?  I think it's hard to give
> really useful feedback on an API without using it for some non-trivial task,
> but maybe other people don't have this problem.
> -jake

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.

Cheers,
/peter
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 3144 review.

[Peter Moody]

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 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.
>>
>> That was my opinion, too.  I've always called that number the 'zero'
>> of the network, but other people said that it is usually called the
>> 'network'.
>>
>> I also find it odd to see a 'network' with an IP address of 192.168.1.1.
>> That looks like a host-address-plus-netmask to me, not a network
>> address.
>>
>
> 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 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 address (hint, it's probably a network)

are you actually getting '98.223.189.24/255.255.240.0' back? that
doesn't look right.

> Because, it *is* a address of a host on a network. I gave in and said:
>
 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. It took me a while to figure out that you can
> iterate over IPNetwork instances:
>
 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. It is unclear to me why the network information
> gets chucked by that operation. I foresee having to work around that in
> real applications by doing something obnoxious like:
>
 actual_gateway = ipaddr.IPNetwork("%s/%s" % (gateway, addr.netmask))
>
> But since I only actually needed the IP address for the gateway, it
> fulfilled my needs.
>
> 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, it's unclear to me why iterating over a IPNetwork would not
> produce a sequence of IPNetwork(/IPAddressWithNetwork) objects.

What you're describing, at least for the networks, is basically what
ipaddr was.  It seemed, after much heated discussion, that the
community felt that

ipaddr.IPv4Network('1.1.1.0/24')[0]

was actually an individual address. ie, each of the addresses in
1.1.1.0/24 are individual addresses, rather than networks with /32
prefix lengths.

having said that, I understand your confusion; I spent a year+
treating addresses exactly as you've mentioned. It didn't seem as
though the majority of the community felt the same, though, so ipaddr
evolved.

Cheers,
/peter

> ISTM that if I started with an IPNetwork object, the API should always
> return IPNetwork objects. If I want just an IPAddress object, then I can
> always fetch the "ip" attribute to get that. Perhaps there is some
> compelling conceptual argument as to why this is not correct, but it
> seems like the API destroys information needlessly.
>
> Just my opinion..
>
> --
> Scott Dial
> sc...@scottdial.com
> scod...@cs.indiana.edu
> ___
> Python-Dev mailing list
> Python-Dev@python.org
> http://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe: 
> http://mail.python.org/mailman/options/python-dev/python-dev%40hda3.com
>
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 3144 review.

[Antoine Pitrou]

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

I don't understand why you think the network mask should be part of an address.
An address is just an address, it specifies the location of a host, not the
configuration of the network surrounding it. If you look at an IP header, the
destination address doesn't specify a netmask.


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

Re: [Python-Dev] PEP 3144 review.

[Scott Dial]

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, it's unclear to me why iterating over a IPNetwork would not
>> produce a sequence of IPNetwork(/IPAddressWithNetwork) objects.
> 
> What you're describing, at least for the networks, is basically what
> ipaddr was.  It seemed, after much heated discussion, that the
> community felt that
> 
> ipaddr.IPv4Network('1.1.1.0/24')[0]
> 
> was actually an individual address. ie, each of the addresses in
> 1.1.1.0/24 are individual addresses, rather than networks with /32
> prefix lengths.
> 

For clarity, I am going to call the current design "A":

ipaddr.IPv4Network('1.1.1.0/24')[0] == ipaddr.IPv4Address('1.1.1.0')

And what itt sounds like what you are describing as the old behavior is
this (design "B"):

ipaddr.IPv4Network('1.1.1.0/24')[0] == ipaddr.IPv4Network('1.1.1.0/32')

Which is different than what I was trying to describe. I expected
(design "C"):

ipaddr.IPv4Network('1.1.1.0/24')[0] == ipaddr.IPv4Network('1.1.1.0/24')

My summarization of these designs would be that "B" is wrong. And that
"A" is better than "B", certainly. At least "A" is not saying something
untrue. However, "C" would be truthful and retains a superset of
information that "A" provides (the "ip" attribute of IPNetwork).

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 individual addresses (hence my
aliasing it with IPAddressWithNetwork). And wrt, the logical return
would be another IPAddressWithNetwork retaining the same mask.

--
Scott Dial
sc...@scottdial.com
scod...@cs.indiana.edu

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

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

[Antoine Pitrou]

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 attached the the subprocess.Popen.stderr, stdout 
and
> >stdin file-like objects.  But when using the read and write 
methods of
> >those options, you do not have the benefit of asynchronous I/O.

I'm not sure I understand the latter sentence. Do you imply that, with 
your work, read() and write() do allow you to benefit from async I/O? If 
so, how?

Another question: what mechanism does it use internally? Is this mechanism
accessible from the outside, so that people can e.g. integrate this 
inside a third-party event loop (Twisted, asyncore or whatever else)?

The PEP should probably outline the additional APIs a bit more precisely 
and formally than it currently does.

> >The Windows
> >implementation uses ctypes to access the functions needed to 
control pipes
> >in the kernel 32 DLL in an asynchronous manner.

Sorry for the naive question (I'm not a Windows specialist), but does the
allusion to "kernel32.dll" mean that it doesn't function on 64-bit 
variants?

Thanks for your work,

Regards

Antoine.


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

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

[exarkun]

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: Standards Track
Content-Type: text/plain
Created: 04-Aug-2009
Python-Version: 3.2

Abstract:

   In its present form, the subprocess.Popen implementation is prone 
to
   dead-locking and blocking of the parent Python script while waiting 
on data

� �from the child process.

Motivation:

� �A search for "python asynchronous subprocess" will turn up numerous
   accounts of people wanting to execute a child process and 
communicate with
   it from time to time reading only the data that is available 
instead of
   blocking to wait for the program to produce data [1] [2] [3].  The 
current
   behavior of the subprocess module is that when a user sends or 
receives
   data via the stdin, stderr and stdout file objects, dead locks are 
common
   and documented [4] [5].  While communicate can be used to alleviate 
some of
   the buffering issues, it will still cause the parent process to 
block while
   attempting to read data when none is available to be read from the 
child

� �process.

Rationale:

   There is a documented need for asynchronous, non-blocking 
functionality in
   subprocess.Popen [6] [7] [2] [3].  Inclusion of the code would 
improve the
   utility of the Python standard library that can be used on Unix 
based and
   Windows builds of Python.  Practically every I/O object in Python 
has a
   file-like wrapper of some sort.  Sockets already act as such and 
for
   strings there is StringIO.  Popen can be made to act like a file by 
simply
   using the methods attached the the subprocess.Popen.stderr, stdout 
and
   stdin file-like objects.  But when using the read and write methods 
of
   those options, you do not have the benefit of asynchronous I/O.  In 
the
   proposed solution the wrapper wraps the asynchronous methods to 
mimic a

� �file object.

Reference Implementation:

   I have been maintaining a Google Code repository that contains all 
of my
   changes including tests and documentation [9] as well as blog 
detailing

� �the problems I have come across in the development process [10].

   I have been working on implementing non-blocking asynchronous I/O 
in the
   subprocess.Popen module as well as a wrapper class for 
subprocess.Popen
   that makes it so that an executed process can take the place of a 
file by
   duplicating all of the methods and attributes that file objects 
have.


"Non-blocking" and "asynchronous" are actually two different things. 
From the rest of this PEP, I think only a non-blocking API is being 
introduced.  I haven't looked beyond the PEP, though, so I might be 
missing something.
   There are two base functions that have been added to the 
subprocess.Popen
   class: Popen.send and Popen._recv, each with two separate 
implementations,

� �one for Windows and one for Unix based systems. �The Windows
   implementation uses ctypes to access the functions needed to 
control pipes
   in the kernel 32 DLL in an asynchronous manner.  On Unix based 
systems,

� �the Python interface for file control serves the same purpose. �The
   different implementations of Popen.send and Popen._recv have 
identical
   arguments to make code that uses these functions work across 
multiple

� �platforms.


Why does the method for non-blocking read from a pipe start with an "_"? 
This is the convention (widely used) for a private API.  The name also 
doesn't suggest that this is the non-blocking version of reading. 
Similarly, the name "send" doesn't suggest that this is the non-blocking 
version of writing.

� �When calling the Popen._recv function, it requires the pipe name be
   passed as an argument so there exists the Popen.recv function that 
passes
   selects stdout as the pipe for Popen._recv by default. 
 Popen.recv_err
   selects stderr as the pipe by default. "Popen.recv" and 
"Popen.recv_err"
   are much easier to read and understand than "Popen._recv('stdout' 
..." and

� �"Popen._recv('stderr' ..." respectively.


What about reading from other file descriptors?  subprocess.Popen allows 
arbitrary file descriptors to be used.  Is there any provision here for 
reading and writing non-blocking from or to those?

� �Since the Popen._recv function does not wait on data to be produced
   before returning a value, it may return empty bytes. 
 Popen.asyncread

� �handles this issue by returning all data read over a given time
� �interval.


Oh.  Popen.asyncread?   What's that?  This is the first time the PEP 
mentions it.
   The ProcessIOWrapper class uses the asyncread and asyncwrite 
functions to
   allow a process to act like a file so that there are no blocking 
issues
   that can arise from using the stdout and stdin f

Re: [Python-Dev] PEP 3144 review.

[Daniel Stutzbach]

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 gave in and said:
>

10.1.2.3 is the address of a host on a network.  255.255.240.0 is a subnet
mask.

>>> 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. It took me a while to figure out that you can
> iterate over IPNetwork instances:
>

Any IP address on an IP network could be the gateway, so there is no
reliable way to determine the gateway IP from the network address and subnet
mask alone.

Technicalities aside, I agree with you that IPNetwork appears to be doing
double-duty as an IPNetwork type and an IPAddressWithNetwork type, which I
find confusing.

--
Daniel Stutzbach, Ph.D.
President, Stutzbach Enterprises, LLC 
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 3144 review.

[R. David Murray]

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 individual addresses (hence my
aliasing it with IPAddressWithNetwork). And wrt, the logical return
would be another IPAddressWithNetwork retaining the same mask.


In other other words, maybe we have three data types:

IPv4Address
IPv4AddressWithMask
IPv4Network

Where myAddressWithMask.network would return an IPv4Network object,
and an IPv4Network object would always have the zero of the network
as its representation:

x = IPv4AddressWithMask('192.168.1.1/24')
x.network == IPv4Network('192.168.1.0/24')
x.network[1] == x

In this scheme, IPv4Network('192.168.1.1/24') would raise a ValueError.

Although you could probably have what I called IPv4AddressWithMask be
called IPv4Address, and have what is now IPv4Address just have
netmask and network attributes of None.

If this were done, I would expect IPv4Network.network to be either
an attribute error or return self.

--David
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 3144 review.

[Jake McGuire]

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, where we had to pull it at the
> >> last time because there hadn't been enough discussion.
> >
> > How many other people are using this library?  I think it's hard to give
> > really useful feedback on an API without using it for some non-trivial
> task,
> > but maybe other people don't have this problem.
> > -jake
>
> 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.

-jake
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 3144 review.

[Peter Moody]

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 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 library?  I think it's hard to give
>> > really useful feedback on an API without using it for some non-trivial
>> > task,
>> > but maybe other people don't have this problem.
>> > -jake
>>
>> 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 positive correlation between the two.
If you have a better method for determining what you would consider an
appropriate level of usage, I'm all ears.

> -jake
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 3144 review.

[Stephen J. Turnbull]

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 character strings.  So
it's an issue of convenience of representation.



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

Re: [Python-Dev] PEP 3144 review.

[Stephen J. Turnbull]

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

Re: [Python-Dev] PEP 3144 review.

[Antoine Pitrou]

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 function which returns a tuple after parsing:

>>> addr, net = parse_address_with_mask('192.168.1.1/24')
>>> addr == IPv4Address('192.168.1.1')
True
>>> net == IPv4Network('192.168.1.0/24')
True

Regards

Antoine.


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

Re: [Python-Dev] PEP 3144 review.

[Peter Moody]

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
>  > 1-element sublists).
>
> But if you iterate over a string you get one character strings.  So
> it's an issue of convenience of representation.

True, but you don't get a string of equal length back.

from the PEP:

 - Treat network elements as lists (in so far as it's possible).

(that should probably say "treat networks as lists")

you will no be able, with a string, to do something like

>>> 'this is my string'[0][1][2][3]

but that's what's being suggested here for networks.

>>> ipaddr.IPv4Network('1.1.1.1/24')[0][1][2][3]...

>
> ___
> Python-Dev mailing list
> Python-Dev@python.org
> http://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe: 
> http://mail.python.org/mailman/options/python-dev/python-dev%40hda3.com
>
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 3144 review.

[R. David Murray]

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
without any obvious benefit.
We just need a factory function which returns a tuple after parsing:

   >>> addr, net = parse_address_with_mask('192.168.1.1/24')
   >>> addr == IPv4Address('192.168.1.1')
   True
   >>> net == IPv4Network('192.168.1.0/24')
   True


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 function, with attributes 'ip' and 'network'
and a representation that included the netmask.

Other people's use cases would look like addr, _ = parse_address...

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.

--David
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 3144 review.

[Scott Dial]

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

The primary difference between IPv4Network and IPv4AddressWithNetwork
would be that IPv4AddressWithNetwork would not support
iteration/indexing. The example above makes no sense logically and my
original suggestion unknowingly opened that can of worms. If indexing a
IPv4Network returned IPv4AddressWithNetwork, then that would remove that
oddity.

This would also solve the weirdness that Stephen brought up in another
branch of this discussion:

Stephen J. Turnbull wrote:
> 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?

The root of the weirdness is that my proposition would appear to make
IPv4Network play double-duty. However, it already does! That you can
instantiate a IPv4Network object with a non-zero host is a clue, and
that it is apparently the only way to input a host with a mask is the
second clue.

If I have an IP (10.2.3.4) and I know the netmask (say, 255.255.0.0),
then how do I get the network that it is on? As it stands, the only way
I see to do this is to do:

>>> net = ipaddr.IPv4Network("10.2.3.4/255.255.0.0")

Which is strange, because I didn't input a *network*, I inputted an
*address* on a network. Moreover, it's strange because:

>>> net[0] == net.ip
False

If I needed that identity to hold true, then I have to do:

>>> net = ipaddr.IPv4Network("%s/%s" % (net[0], net.netmask)

Although it is unclear why a "network" has an "ip" attribute. As far as
I am concerned, IPv4Network objects should *only* have a net.network.

Hopefully at this point, I have made the case that IPv4Network already
is playing double-duty as a IPv4Network and IPv4AddressWithNetwork. And
that the API would be well-served by splitting that role and that it
would be considerably less confusing.

-- 
Scott Dial
sc...@scottdial.com
scod...@cs.indiana.edu

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

Re: [Python-Dev] PEP 3144 review.

[Antoine Pitrou]

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 function, with attributes 'ip' and 'network'
> and a representation that included the netmask.

If the AddressWithNetwork class has useful functionality of its own, then why
not (although I think that conceptually, this functionality should belong to the
Network class instead).

If, however, the AddressWithNetwork class is only a recipient for a tuple, then
it sounds useless. It's like having an AddressWithPort to hold things like
"127.0.0.1:8080". Building little featureless recipients like that isn't really
idiomatic Python, IMO.

> 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 terminology) doesn't have a network and a mask.
I think we should keep the API clean and reasonably logical, rather than try to
cover all use cases at the expense of weird shortcuts.

Regards

Antoine.


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

Re: [Python-Dev] PEP 3144 review.

[Sebastian Rittau]

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 address (hint, it's probably a network)
> 
> Because, it *is* a address of a host on a network.

To me, 10.1.2.3/255.255.240.0 is not a host address, but specifies a
network. I.e., 10.1.2.3/255.255.240.0 == 10.1.0.0/255.255.240.0 ==
10.1.35.200/20.

> >>> 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 gateway, without querying
the network topology. This is clearly outside the scope of this module.
The only two known host addresses of a network are the network address
(10.1.0.0 in the example you gave) and the broadcast address (10.1.15.255).

> It took me a while to figure out that you can
> iterate over IPNetwork instances:
> 
> >>> 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. It is unclear to me why the network information
> gets chucked by that operation.

This makes perfect sense to me. An IP network consists of a list of IP
addresses. Returning /32 networks seems kind of pointless to me.

> I foresee having to work around that in
> real applications by doing something obnoxious like:
> 
> >>> actual_gateway = ipaddr.IPNetwork("%s/%s" % (gateway, addr.netmask))

But a gateway is not an IP address plus hostmask. A gateway is just a single
IP address. What is the use of adding a hostmask to the gateway IP address
or some other IP address inside the network?

 - Sebastian
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 3144 review.

[R. David Murray]

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 to hold the
tuple returned by your parse function, with attributes 'ip' and 'network'
and a representation that included the netmask.


If the AddressWithNetwork class has useful functionality of its own, then why
not (although I think that conceptually, this functionality should belong to the
Network class instead).


But it's not a network.  It's an address that is explicitly associated
with a network.

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, however, the AddressWithNetwork class is only a recipient for a tuple, then
it sounds useless. It's like having an AddressWithPort to hold things like
"127.0.0.1:8080". Building little featureless recipients like that isn't really
idiomatic Python, IMO.


I could see myself doing that, too, though I haven't had a reason to yet :)
Although I'd probably call it 'IPv4EndPoint' or some such, since it would
be representing one endpoint of a traffic flow...


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 terminology) doesn't have a network and a mask.
I think we should keep the API clean and reasonably logical, rather than try to
cover all use cases at the expense of weird shortcuts.


OK.  I'll withdrawal that suggestion.

If AddressWithMask doesn't get added I won't be heartbroken; it is easy
enough to write in the programs where I need it (at least it would be
if the parsing/validation is in the library).  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.

Oh, and if people don't like 'zero' as the name for the IPv4Address
at the beginning of the network IP range, how about 'network_ip' or
'network_address' instead of just network, to make it clearer that it
is an address?

--David
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 3144 review.

[Antoine Pitrou]

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 parsing and validating, then a tuple works just fine.
Getting the associated IP objects is obtained from iterating over the
network.
Getting the associated network objects I don't understand. There is a
single network, not a bunch of them.

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

> Oh, and if people don't like 'zero' as the name for the IPv4Address
> at the beginning of the network IP range, how about 'network_ip' or
> 'network_address' instead of just network, to make it clearer that it
> is an address?

How about something more explicit about how it's obtained, like
'lower_bound'?



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

Re: [Python-Dev] PEP 3144 review.

[Martin v. Löwis]

> 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 do so before the end of the year, but can't
promise that.

In any case, I don't see a reason to hurry - if the PEP is adopted
two or three months before the release of 2.7, it will still be in
time, IMO.

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

Re: [Python-Dev] PEP 3144 review.

[Terry Reedy]

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 all ears.


You sneak in a bit of code that sends a message to home base "In use 
from ";-)


Kidding aside, there are usage reports, but those tend to be lower if 
the code satifies than if not. I think 200 indicates fair interest. Let 
us hope there is more feedback, pro and con.


tjr

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

Re: [Python-Dev] PEP 3144 review.

[Daniel Fetchinson]

>>> 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 positive correlation between the two.
> If you have a better method for determining what you would consider an
> appropriate level of usage, I'm all ears.

A good way of determining the level of usage would be pointing to open
source projects that are popular in the python community and which
incorporate your module.

Cheers,
Daniel

-- 
Psss, psss, put it down! - http://www.cafepress.com/putitdown
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 3144 review.

[Peter Moody]

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 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 all ears.
>
> A good way of determining the level of usage would be pointing to open
> source projects that are popular in the python community and which
> incorporate your module.

well, the 2.0 release is still new. codesearch.google.com shows some
projects using the 1.x release; hopefully some of those 200
downloaders will put up some publicly indexable python code at some
point.

> Cheers,
> Daniel
>
> --
> Psss, psss, put it down! - http://www.cafepress.com/putitdown
> ___
> Python-Dev mailing list
> Python-Dev@python.org
> http://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe: 
> http://mail.python.org/mailman/options/python-dev/python-dev%40hda3.com
>
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 3144 review.

[R. David Murray]

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 small class, but useful, IMO.


If it's only about parsing and validating, then a tuple works just fine.
Getting the associated IP objects is obtained from iterating over the
network.
Getting the associated network objects I don't understand. There is a
single network, not a bunch of them.


The plural was for the two attributes.  I guess I just like accessing
things by name better than accessing them by indexes.  I suppose a
NamedTuple would work.  Anyway, like I said I'm not attached to that
class.


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?


Oh, and if people don't like 'zero' as the name for the IPv4Address
at the beginning of the network IP range, how about 'network_ip' or
'network_address' instead of just network, to make it clearer that it
is an address?


How about something more explicit about how it's obtained, like
'lower_bound'?


Well, when this came up earlier 'first' and 'last' were suggested to
replace 'network' and 'broadcast', but that proposal didn't get much
traction, the argument being that in normal technical parlance
the first IP in the netblock is (apparently, this isn't my personal
experience(*)) called the network, and the broadcast is almost invariably
the last IP in the netblock (and that does agree with my experience).

--David

(*) in my experience it is called the "network number", which I gather
derives from the pre-CIDR days.  "network identifier" also appears
to be used.  In my experience "network" refers to something that has
a netmask, although the netmask may be implicit in its class in the
classful routing sense, or through other context.

Consider this article, for example:
http://compnetworking.about.com/od/workingwithipaddresses/l/aa042900a.htm___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 3144 review.

[Scott Dial]

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?

This change would have to be dependent on Antoine's suggestion of:

>>> addr, net = parse_address_with_mask('192.168.1.1/24')
>>> addr == IPv4Address('192.168.1.1')
True
>>> net == IPv4Network('192.168.1.0/24')
True

Otherwise, I am ok with this change too. It resloves the weird duality
of IPv4Network. And as RDM says, anyone who wants the
IPv4AddressWithNetwork functionality can just role it themselves. At the
moment of iteration, you have access to what network it is and can build
your own IPv4AddressWithNetwork objects.

net = IPv4Network('10.0.0.0/24')
netaddrs = []
for addr in net:
netaddrs.append(IPv4AddressWithNetwork(addr, net))

I guess I am ok with this. It seems sub-optimal (why not just return a
IPv4AddressWithNetwork to begin with?) but I suppose it is no less
efficient since the same objects would be constructed.

-- 
Scott Dial
sc...@scottdial.com
scod...@cs.indiana.edu
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 3144 review.

[Scott Dial]

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 gateway, without querying
> the network topology. This is clearly outside the scope of this module.
> The only two known host addresses of a network are the network address
> (10.1.0.0 in the example you gave) and the broadcast address (10.1.15.255).

I was not writing a general utility for the world to use. On *my*
network it is always the [1]th address used for the gateway. But, I
agree in general that is not true.

>> Which sorta blew my mind.. I fully expected to receive an IPNetwork back
>> from that operation. It is unclear to me why the network information
>> gets chucked by that operation.
> 
> This makes perfect sense to me. An IP network consists of a list of IP
> addresses. Returning /32 networks seems kind of pointless to me.

As I clarified later, I expected it to still be a /24 network, not a
/32. /32 makes no sense.

> But a gateway is not an IP address plus hostmask. A gateway is just a single
> IP address. What is the use of adding a hostmask to the gateway IP address
> or some other IP address inside the network?

My argument was from a destruction of information standpoint. Why is the
network chucked away? Wouldn't it be handy to be able to inspected
addr.network to see what network it was on? Perhaps because you are
building routing rules and need to actually know that. As it is, you
will just have to build your own IPAddressWithNetwork objects.

Hopefully I have covered all of you inquiries, but I feel like that a
lot of this is covered by many other replies in this thread.

-- 
Scott Dial
sc...@scottdial.com
scod...@cs.indiana.edu
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 3144 review.

[Peter Moody]

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.

> This change would have to be dependent on Antoine's suggestion of:
>
>    >>> addr, net = parse_address_with_mask('192.168.1.1/24')
>    >>> addr == IPv4Address('192.168.1.1')
>    True
>    >>> net == IPv4Network('192.168.1.0/24')
>    True
>
> Otherwise, I am ok with this change too. It resloves the weird duality
> of IPv4Network. And as RDM says, anyone who wants the
> IPv4AddressWithNetwork functionality can just role it themselves. At the
> moment of iteration, you have access to what network it is and can build
> your own IPv4AddressWithNetwork objects.

now, I understand that as the author, I have certain biases, but I'm
not having the same difficulty with this duality as others.  I really
don't even see it as a duality.

It seems as though your issue could more easily be solved by having an
iterator in BaseNet which returns a new network object with the
original prefix length.

eg:

for addr in ipaddr.IPv4Network('1.1.1.0/24').iterwithnetmask():
  # 1.1.1.0/24, 1.1.1.1/24, 1.1.1.2/24...

(or better yet, .iterwithprefix)

this can be done much more cleanly/easily than adding two new
(redundant in my eyes) classes and much less pedantically than raising
exceptions w/ IPv?Network() constructor received something other than
base network address.

Is this sufficient? If not, perhaps someone could help me better
understand the confusion over IPv?Network objects.

Cheers,
/peter

> net = IPv4Network('10.0.0.0/24')
> netaddrs = []
> for addr in net:
>    netaddrs.append(IPv4AddressWithNetwork(addr, net))
>
> I guess I am ok with this. It seems sub-optimal (why not just return a
> IPv4AddressWithNetwork to begin with?) but I suppose it is no less
> efficient since the same objects would be constructed.
>
> --
> Scott Dial
> sc...@scottdial.com
> scod...@cs.indiana.edu
> ___
> Python-Dev mailing list
> Python-Dev@python.org
> http://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe: 
> http://mail.python.org/mailman/options/python-dev/python-dev%40hda3.com
>
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 3144 review.

[Antoine Pitrou]

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

Python is not PHP and does not try to be overly "smart" or tolerant when faced
with bizarrely-formatted input.

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.

> for addr in ipaddr.IPv4Network('1.1.1.0/24').iterwithnetmask():
>   # 1.1.1.0/24, 1.1.1.1/24, 1.1.1.2/24...

I don't have any strong feelings about it, although I don't really think it is
needed, and a plethoric API is not a good thing (neither clarity-wise nor
maintenance-wise).

> this can be done much more cleanly/easily than adding two new
> (redundant in my eyes) classes and much less pedantically than raising
> exceptions w/ IPv?Network() constructor received something other than
> base network address.

I don't think anybody suggested adding two classes. As for the "pedantry" of
thoroughly validating inputs, see above.

Regards

Antoine.


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

Re: [Python-Dev] PEP 3144 review.

[Antoine Pitrou]

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 optional "strict=True" (or "strict=False") argument
to the constructor / parsing function.

Regards

Antoine.


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

Re: [Python-Dev] PEP 3144 review.

[Eric Smith]

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


Python is not PHP and does not try to be overly "smart" or tolerant when faced
with bizarrely-formatted input.

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.


I completely agree. I don't know of any situation where I'd want a 
network of "192.168.1.1/24" to be anything other than an error.


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

Re: [Python-Dev] PEP 3144 review.

[Eric Smith]

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 there can be an optional "strict=True" (or "strict=False") argument
to the constructor / parsing function.


If so, I hope that we'd default to strict=True.
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 3144 review.

[Peter Moody]

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 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.
>>
>> Python is not PHP and does not try to be overly "smart" or tolerant when
>> faced
>> with bizarrely-formatted input.
>>
>> 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.
>
> I completely agree. I don't know of any situation where I'd want a network
> of "192.168.1.1/24" to be anything other than an error.

when you're entering the address of your nic.

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

Re: [Python-Dev] PEP 3144 review.

[Peter Moody]

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 helpful and signal it to the user.
>
> Or perhaps there can be an optional "strict=True" (or "strict=False") argument
> to the constructor / parsing function.

I can live w/ a default of strict=False.  there are plenty of cases
where it's not an error and easy enough ways to check, if the
developer is concerned, with or without an option.  eg if addr.ip !=
addr.network:

Cheers,
/peter

> Regards
>
> Antoine.
>
>
> ___
> Python-Dev mailing list
> Python-Dev@python.org
> http://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe: 
> http://mail.python.org/mailman/options/python-dev/python-dev%40hda3.com
>
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

[A.M. Kuchling]

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 event for developers
of Python implementations and the standard library, to discuss issues
of common concern to all implementors.

It will mostly be organized similarly to last year's event.  I'm going
to drop the initial open discussion, which wasn't very useful, and
we'll just have three 1.5-hour discussion sessions.  The fourth time
slot will be left open for chatting, development, or whatever the
attendees want to do.

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's topics.)

Feel free to raise discussions on other lists such as jython-dev,
catalog-sig, or wherever, but please summarize the results here on
python-dev; I won't see discussions on other lists.

Like last time, invitations will be sent to the committers for Python,
Jython, IronPython, PyPy, Pynie, plus a few extra people and projects.
If you want to suggest another project or person who should be
invited, please send me a private e-mail.


Andrew M. Kuchling
a...@amk.ca
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 3144 review.

[Andrew McNamara]

>>> 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 "strict=False")
>> argument to the constructor / parsing function.
>
>I can live w/ a default of strict=False.  there are plenty of cases
>where it's not an error and easy enough ways to check, if the
>developer is concerned, with or without an option.  eg if addr.ip !=
>addr.network:

I agree - there are definitely times when it is not an error, but I don't
like the idea of a "strict" flag.

I've done a bit of everything - router configs with a national ISP,
scripts to manage host configuration, user interfaces, you name it.
The way I see it, we need:

 * Two address classes that describe a single IP end-point - "Address" with
   no mask and "AddressWithMask" (the later being the current Network
   class, minus the container-like behaviour).

 * A "Network" container-like class. Same as the current Network class,
   but addresses with masked bits would be considered an error.

This is along the lines that RDM was suggesting, except that we remove the
container behaviour from AddressWithMask.

Additionally:

 * The .network attribute on an AddressWithMask would return a Network
   instance.

 * An Address class would not have a .network attribute

 * Network.__contains__() would accept Network, Address and
   AddressWithMask. Only Network implements __contains__ -
   an AddressWithMask can't contain another address, although it's
   .network can.

 * Maybe an Address should compare equal with an AddressWithMask if
   the address is identical and the mask is equivalent to /32?

Personally, I don't see a strong use-case for the list-like indexing and
iteration behaviour - I think it's enough to implement some basic
container behaviour, but I won't object to the iterator and indexing,
provided they don't distort the rest of the design (which I fear they
are doing now). Iterating or indexing a network should return Address
or AddressWithMask instances - if the later, the mask should match the
parent network's mask.

I'm not particularly wedded to the name "AddressWithMask" - maybe it
could be NetworkAddress or MaskedAddress or ?

-- 
Andrew McNamara, Senior Developer, Object Craft
http://www.object-craft.com.au/
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 3144 review.

[rascal]

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 should
return the ANDed result. Whether the number is 192.186.1.1/24 or
192.168.1.0/24, the result after 'and' is the same. Add a strict=false in
case people need it for validation, better yet, add a validation helper
function, but always return the proper form.

2. A host address is an IP address with no network info.  No mask
information, ever.


What about Broadcast / Network IDs?
The "Network-ID or Network Number" and "Broadcast" are meaningless without
context.
1. A network number by itself it's just another address. Its use depends on
context. When routing, it needs a mask.

> route 10.0.0.0 255.0.0.0 192.168.1.1
>
When writing firewall ACLs, it is a host.

> access-list aclname permit ip any 192.168.1.2 255.255.255.254
>
Since both are valid, preference shouldn't be given. Instead add a helper
for firstip.

2. Same story with broadcast. Use depends on context. Add the lastip helper.


What does iterating over a network mean?
Iterating over the set of addresses in a network must return host addresses.
If it returns a network, then the address should be ANDed, but that would
return the same number for every iteration. Only returning hosts makes
sense.

We need to set a solid line between IP String manipulation and IP
manipulation.
If you want an IP with a mask that isn't a network, then you're not doing IP
address manipulation, you're doing string manipulation. There are many use
cases for it, but it's a separate consideration to pure IP manipulation.

If string manipulation is desirable, then add another standard library
called ipstring (or a separate class if you want it all jumbled in the same
import).  This way real network computing can be done without weird quirks
of representation.

R.
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 3144 review.

[Stephen J. Turnbull]

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
 > IPv4AddressWithNetwork (or as he called it: IPv4AddressWithMask)
 > IPv4Network

IPv4AddressWithMask seems silly to me, implementation-wise.  IP
networks are conceptually globally unique (and even for unroutable
networks they're locally unique), and it seems to me that I want that
to be true internally (for example, I once implemented an IP network
type that maintains a hostname table).  If you need *the* network,
you'll have to look it up in a mask_to_network table (at least
internally).

Rather, don't you want to just give IPv4Address an attribute
'network'?  This could then be filled in by the indexing method on
IPv4Network.

Then deriving a mask from a network is trivial (networks need to know
their masks anyway), like so:

IPv4Address('1.1.1.1').network.mask

giving you the mask if .network is known, else an attribute error if
.network is None.  But deriving *the* corresponding network from a
mask will require keeping a table of networks around.

 > that it is apparently the only way to input a host with a mask is the
 > second clue.

I don't see why you would want to do that.  Wouldn't you rather

IPv4Address('1.1.1.1').network_from_mask('255.255.0.0')

and

IPv4Address('1.1.1.1').set_network_from_mask('255.255.0.0')


 > If I have an IP (10.2.3.4) and I know the netmask (say, 255.255.0.0),
 > then how do I get the network that it is on? As it stands, the only way
 > I see to do this is to do:
 > 
 > >>> net = ipaddr.IPv4Network("10.2.3.4/255.255.0.0")
 > 
 > Which is strange, because I didn't input a *network*, I inputted an
 > *address* on a network.

No, you inputted a pair of dotted quads.  Dotted quads do triple duty
representing host addresses, network addresses, and network masks.
Since construction is a conversion anyway, I don't have any problem
with constructing a network from that pair so that your test:

 > >>> net[0] == net.ip

returns true.  Ie, the implementation can do

class IPv4Network(...):
def __init__(self, dotted_quad_pair_string):
ip, mask = pair_string_to_int_pair(dotted_quad_pair_string)
self.mask = mask
self.ip = ip & mask

 > IPv4Network objects should *only* have a net.network.

That's a naming issue, though, isn't it?  I don't see a use for
net.ip != net.network, so you wouldn't have both of them.  If you *do*
have both for some reason, your test

net[0] == net.ip

seems to have the semantics "How was I constructed?" and I don't see
why you can assert that should be True.

 > Hopefully at this point, I have made the case that IPv4Network already
 > is playing double-duty as a IPv4Network and IPv4AddressWithNetwork.

At this point, no, you've only made the point that you would try to
use it that way.  Maybe that's natural for you (and you're obviously
more expert than I), but it's not for me.  I haven't experienced a
need for the operations you're trying to do, but if I needed them,
I'd be looking for APIs on IPv4Address and IPv4Network like those I
described above, not an IPv4AddressWithNetwork type (ie, I would
expect that IPv4Address is implemented as IPv4AddressWithNetwork).

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

Re: [Python-Dev] PEP 3144 review.

[Stephen J. Turnbull]

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 terminology) doesn't have a network and a mask.

It doesn't need a mask attribute because the network knows that.

OTOH, it would be useful for an address to be able to cache the
network it is a member of, because the object that represents a
particular network should be unique.  That means a lookup in a table,
and possibly constructing a new IPv4Network object to represent the
anwser if false, if you are given a netmask and asked to deduce *the*
network.  And addresses do, implicitly, have a network.  Otherwise
the're useless!<0.5 wink>

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