Mailing List Archive: Python: Dev

PEP 3144 review.

1 2 3 4 5 6 7 8 9 10

View All

Index | Next | Previous | View Threaded

peter at hda3

Sep 14, 2009, 9:44 AM

Post #1 of 239 (1881 views)
Permalink

PEP 3144 review.

Folks, Guido,

I believe PEP 3144 is ready for your review. When you get a chance,
can you take a look/make a pronouncement?

Cheers,
/peter
_______________________________________________
Python-Dev mailing list
Python-Dev [at] python
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/list-python-dev%40lists.gossamer-threads.com

guido at python

Sep 14, 2009, 9:54 AM

Post #2 of 239 (1826 views)
Permalink

Re: PEP 3144 review. [In reply to]

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.

On Mon, Sep 14, 2009 at 9:44 AM, Peter Moody <peter [at] hda3> wrote:
> Folks, Guido,
>
> I believe PEP 3144 is ready for your review. When you get a chance,
> can you take a look/make a pronouncement?
>
> Cheers,
> /peter
>

--
--Guido van Rossum (home page: http://www.python.org/~guido/)
_______________________________________________
Python-Dev mailing list
Python-Dev [at] python
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/list-python-dev%40lists.gossamer-threads.com

andrewm at object-craft

Sep 14, 2009, 7:11 PM

Post #3 of 239 (1772 views)
Permalink

Re: PEP 3144 review. [In reply to]

>I believe PEP 3144 is ready for your review. When you get a chance,
>can you take a look/make a pronouncement?

In my experience it is common to leave out the masked octets when
referring to an IPv4 network (the octets are assumed to be zero), so I
don't agree with this behaviour from the reference implementation:

>>> ipaddr.IPv4Network('10/8')
IPv4Network('0.0.0.10/8')
>>> ipaddr.IPv4Network('192.168/16')
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
File "/usr/src/py/ipaddr/ipaddr.py", line 1246, in __init__
raise IPv4IpValidationError(addr[0])
ipaddr.IPv4IpValidationError: '192.168' is not a valid IPv4 address

I also couldn't see an easy way to get from a network address to the
containing network. For example:

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

This is close:

>>> ipaddr.IPv4Network('192.168.1.1/16').network
IPv4Address('192.168.0.0')

What I want is a method that returns:

IPv4Network('192.168.0.0/16')

I appreciate these requests are somewhat contradictory (one calls
for masked octets to be insignificant, the other calls for them to be
significant), but they are both valid use cases in my experience.

Apologies if these have already been covered in prior discussion -
I've tried to keep up, but I haven't been able to give it the attention
it deserves.

I also note that many methods in the reference implementation are not
discussed in the PEP. While I don't consider this a problem for the PEP,
anyone reviewing the module for inclusion in the standard lib needs to
consider them.

--
Andrew McNamara, Senior Developer, Object Craft
http://www.object-craft.com.au/
_______________________________________________
Python-Dev mailing list
Python-Dev [at] python
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/list-python-dev%40lists.gossamer-threads.com

peter at hda3

Sep 14, 2009, 11:02 PM

Post #4 of 239 (1773 views)
Permalink

Re: PEP 3144 review. [In reply to]

On Mon, Sep 14, 2009 at 7:11 PM, Andrew McNamara
<andrewm [at] object-craft> wrote:
>>I believe PEP 3144 is ready for your review. When you get a chance,
>>can you take a look/make a pronouncement?
>
> In my experience it is common to leave out the masked octets when
> referring to an IPv4 network (the octets are assumed to be zero), so I
> don't agree with this behaviour from the reference implementation:

huh, this appears to be a bug. filing an issue and I'll have this
fixed before anything is submitted
(http://code.google.com/p/ipaddr-py/issues/detail?id=35)

> >>> ipaddr.IPv4Network('10/8')
> IPv4Network('0.0.0.10/8')
> >>> ipaddr.IPv4Network('192.168/16')
> Traceback (most recent call last):
> File "<stdin>", line 1, in <module>
> File "/usr/src/py/ipaddr/ipaddr.py", line 1246, in __init__
> raise IPv4IpValidationError(addr[0])
> ipaddr.IPv4IpValidationError: '192.168' is not a valid IPv4 address
>
> I also couldn't see an easy way to get from a network address to the
> containing network. For example:
>
> >>> ipaddr.IPv4Network('192.168.1.1/16')
> IPv4Network('192.168.1.1/16')
>
> This is close:
>
> >>> ipaddr.IPv4Network('192.168.1.1/16').network
> IPv4Address('192.168.0.0')
>
> What I want is a method that returns:
>
> IPv4Network('192.168.0.0/16')

I can see about adding this. you can currently do:

>>> a = ipaddr.IPv4Network('192.168.1.1/16')
>>> '%s/%s' % (a.network, a.prefixlen)
192.168.0.0/16

(I do something very similar to this in address_exclude)

> I appreciate these requests are somewhat contradictory (one calls
> for masked octets to be insignificant, the other calls for them to be
> significant), but they are both valid use cases in my experience.
>
> Apologies if these have already been covered in prior discussion -
> I've tried to keep up, but I haven't been able to give it the attention
> it deserves.

no need to apologize, all comments welcome.

> I also note that many methods in the reference implementation are not
> discussed in the PEP. While I don't consider this a problem for the PEP,
> anyone reviewing the module for inclusion in the standard lib needs to
> consider them.

yeah, I didn't exactly want the PEP to be the pydoc of ipaddr, but I
did want to explain the features and show how I thought they were
important to whatever might be accepted by python. I can certainly go
into much more detail in the PEP if that's deemed important.

Cheers,
/peter

> --
> Andrew McNamara, Senior Developer, Object Craft
> http://www.object-craft.com.au/
>
_______________________________________________
Python-Dev mailing list
Python-Dev [at] python
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/list-python-dev%40lists.gossamer-threads.com

solipsis at pitrou

Sep 15, 2009, 7:28 AM

Post #5 of 239 (1803 views)
Permalink

Re: PEP 3144 review. [In reply to]

Andrew McNamara <andrewm <at> 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 [at] python
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/list-python-dev%40lists.gossamer-threads.com

rdmurray at bitdance

Sep 15, 2009, 7:36 AM

Post #6 of 239 (1805 views)
Permalink

Re: PEP 3144 review. [In reply to]

On Tue, 15 Sep 2009 at 14:28, Antoine Pitrou wrote:
> Andrew McNamara <andrewm <at> 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 [at] python
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/list-python-dev%40lists.gossamer-threads.com

scott+python-dev at scottdial

Sep 15, 2009, 10:16 AM

Post #7 of 239 (1760 views)
Permalink

Re: PEP 3144 review. [In reply to]

R. David Murray wrote:
> On Tue, 15 Sep 2009 at 14:28, Antoine Pitrou wrote:
>> Andrew McNamara <andrewm <at> 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))
<class 'ipaddr.IPv4Address'>

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
scott [at] scottdial
scodial [at] cs
_______________________________________________
Python-Dev mailing list
Python-Dev [at] python
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/list-python-dev%40lists.gossamer-threads.com

mcguire at google

Sep 15, 2009, 10:16 AM

Post #8 of 239 (1796 views)
Permalink

Re: PEP 3144 review. [In reply to]

On Mon, Sep 14, 2009 at 9:54 AM, Guido van Rossum <guido [at] python> 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

peter at hda3

Sep 15, 2009, 10:36 AM

Post #9 of 239 (1793 views)
Permalink

Re: PEP 3144 review. [In reply to]

On Tue, Sep 15, 2009 at 10:16 AM, Jake McGuire <mcguire [at] google> wrote:
> On Mon, Sep 14, 2009 at 9:54 AM, Guido van Rossum <guido [at] python> 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 [at] python
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/list-python-dev%40lists.gossamer-threads.com

peter at hda3

Sep 15, 2009, 10:56 AM

Post #10 of 239 (1757 views)
Permalink

Re: PEP 3144 review. [In reply to]

On Tue, Sep 15, 2009 at 10:16 AM, Scott Dial
<scott+python-dev [at] scottdial> wrote:
> R. David Murray wrote:
>> On Tue, 15 Sep 2009 at 14:28, Antoine Pitrou wrote:
>>> Andrew McNamara <andrewm <at> 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))
> <class 'ipaddr.IPv4Address'>
>
> 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
> scott [at] scottdial
> scodial [at] cs
> _______________________________________________
> Python-Dev mailing list
> Python-Dev [at] python
> 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 [at] python
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/list-python-dev%40lists.gossamer-threads.com

solipsis at pitrou

Sep 15, 2009, 11:07 AM

Post #11 of 239 (1793 views)
Permalink

Re: PEP 3144 review. [In reply to]

Scott Dial <scott+python-dev <at> scottdial.com> writes:
>
> >>> gateway = net[1]
>
> I was then confused, because:
>
> >>> print(type(gateway))
> <class 'ipaddr.IPv4Address'>
>
> 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 [at] python
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/list-python-dev%40lists.gossamer-threads.com

scott+python-dev at scottdial

Sep 15, 2009, 11:16 AM

Post #12 of 239 (1756 views)
Permalink

Re: PEP 3144 review. [In reply to]

Peter Moody wrote:
> On Tue, Sep 15, 2009 at 10:16 AM, Scott Dial
> <scott+python-dev [at] scottdial> 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
scott [at] scottdial
scodial [at] cs

_______________________________________________
Python-Dev mailing list
Python-Dev [at] python
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/list-python-dev%40lists.gossamer-threads.com

daniel at stutzbachenterprises

Sep 15, 2009, 11:32 AM

Post #13 of 239 (1793 views)
Permalink

Re: PEP 3144 review. [In reply to]

On Tue, Sep 15, 2009 at 12:16 PM, Scott Dial
<scott+python-dev [at] scottdial<scott%2Bpython-dev [at] scottdial>
> 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 <http://stutzbachenterprises.com>

mcguire at google

Sep 15, 2009, 11:33 AM

Post #14 of 239 (1789 views)
Permalink

Re: PEP 3144 review. [In reply to]

On Tue, Sep 15, 2009 at 10:36 AM, Peter Moody <peter [at] hda3> wrote:

> On Tue, Sep 15, 2009 at 10:16 AM, Jake McGuire <mcguire [at] google> wrote:
> > On Mon, Sep 14, 2009 at 9:54 AM, Guido van Rossum <guido [at] python>
> 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

rdmurray at bitdance

Sep 15, 2009, 11:33 AM

Post #15 of 239 (1792 views)
Permalink

Re: PEP 3144 review. [In reply to]

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 [at] python
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/list-python-dev%40lists.gossamer-threads.com

peter at hda3

Sep 15, 2009, 11:36 AM

Post #16 of 239 (1789 views)
Permalink

Re: PEP 3144 review. [In reply to]

On Tue, Sep 15, 2009 at 11:33 AM, Jake McGuire <mcguire [at] google> wrote:
> On Tue, Sep 15, 2009 at 10:36 AM, Peter Moody <peter [at] hda3> wrote:
>>
>> On Tue, Sep 15, 2009 at 10:16 AM, Jake McGuire <mcguire [at] google> wrote:
>> > On Mon, Sep 14, 2009 at 9:54 AM, Guido van Rossum <guido [at] python>
>> > 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 [at] python
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/list-python-dev%40lists.gossamer-threads.com

solipsis at pitrou

Sep 15, 2009, 11:43 AM

Post #17 of 239 (1792 views)
Permalink

Re: PEP 3144 review. [In reply to]

R. David Murray <rdmurray <at> 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 [at] python
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/list-python-dev%40lists.gossamer-threads.com

mcguire at google

Sep 15, 2009, 11:44 AM

Post #18 of 239 (1700 views)
Permalink

Re: PEP 3144 review. [In reply to]

On Tue, Sep 15, 2009 at 11:36 AM, Peter Moody <peter [at] hda3> wrote:

> On Tue, Sep 15, 2009 at 11:33 AM, Jake McGuire <mcguire [at] google> wrote:
> > On Tue, Sep 15, 2009 at 10:36 AM, Peter Moody <peter [at] hda3> wrote:
> >>
> >> On Tue, Sep 15, 2009 at 10:16 AM, Jake McGuire <mcguire [at] google>
> wrote:
> >> > On Mon, Sep 14, 2009 at 9:54 AM, Guido van Rossum <guido [at] python>
> >> > 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.
>

Put something on the project page (or download page if possible) saying
"ipaddr is being considered for inclusion in the Python standard library.
We want to make sure it meets your needs, but we need you to tell us. If
you use ipaddr and like it, please let us know on ip-addr-dev."

I dunno, maybe it's too much work. But no one else seems to have an opinion
strong enough to share, at least not at this point.

-jake

peter at hda3

Sep 15, 2009, 11:46 AM

Post #19 of 239 (1792 views)
Permalink

Re: PEP 3144 review. [In reply to]

On Tue, Sep 15, 2009 at 11:49 AM, Stephen J. Turnbull
<stephen [at] xemacs> 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 [at] python
> 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 [at] python
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/list-python-dev%40lists.gossamer-threads.com

stephen at xemacs

Sep 15, 2009, 11:49 AM

Post #20 of 239 (1793 views)
Permalink

Re: PEP 3144 review. [In reply to]

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 [at] python
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/list-python-dev%40lists.gossamer-threads.com

stephen at xemacs

Sep 15, 2009, 11:54 AM

Post #21 of 239 (1793 views)
Permalink

Re: PEP 3144 review. [In reply to]

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 [at] python
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/list-python-dev%40lists.gossamer-threads.com

mcguire at google

Sep 15, 2009, 11:58 AM

Post #22 of 239 (1700 views)
Permalink

Re: PEP 3144 review. [In reply to]

On Tue, Sep 15, 2009 at 11:44 AM, Jake McGuire <mcguire [at] google> wrote:

> On Tue, Sep 15, 2009 at 11:36 AM, Peter Moody <peter [at] hda3> wrote:
>
>> On Tue, Sep 15, 2009 at 11:33 AM, Jake McGuire <mcguire [at] google>
>> wrote:
>> > On Tue, Sep 15, 2009 at 10:36 AM, Peter Moody <peter [at] hda3> wrote:
>> >>
>> >> On Tue, Sep 15, 2009 at 10:16 AM, Jake McGuire <mcguire [at] google>
>> wrote:
>> >> > On Mon, Sep 14, 2009 at 9:54 AM, Guido van Rossum <guido [at] python>
>> >> > 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.
>>
>
> Put something on the project page (or download page if possible) saying
> "ipaddr is being considered for inclusion in the Python standard library.
> We want to make sure it meets your needs, but we need you to tell us. If
> you use ipaddr and like it, please let us know on ip-addr-dev."
>
> I dunno, maybe it's too much work. But no one else seems to have an
> opinion strong enough to share, at least not at this point.
>

To clarify: there will always be some group of people happy to tell you that
whatever you made is crap and that it should have been done differently.
There may be many more people out there who think that what you did is
great. But those people probably don't read python-dev so their voices
don't get heard when it comes to deciding what to do with PEP 3144.

The easiest way to get their voices heard is to ask them to speak up, and
the one place you know they visited was the ipaddr page on code.google.com,
so you may as well ask them there.

-jake

rdmurray at bitdance

Sep 15, 2009, 12:09 PM

Post #23 of 239 (1796 views)
Permalink

Re: PEP 3144 review. [In reply to]

On Tue, 15 Sep 2009 at 18:43, Antoine Pitrou wrote:
> R. David Murray <rdmurray <at> 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 [at] python
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/list-python-dev%40lists.gossamer-threads.com

scott+python-dev at scottdial

Sep 15, 2009, 12:13 PM

Post #24 of 239 (1756 views)
Permalink

Re: PEP 3144 review. [In reply to]

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
scott [at] scottdial
scodial [at] cs

_______________________________________________
Python-Dev mailing list
Python-Dev [at] python
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/list-python-dev%40lists.gossamer-threads.com

solipsis at pitrou

Sep 15, 2009, 12:20 PM

Post #25 of 239 (1752 views)
Permalink

Re: PEP 3144 review. [In reply to]

R. David Murray <rdmurray <at> 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 [at] python
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/list-python-dev%40lists.gossamer-threads.com

1 2 3 4 5 6 7 8 9 10

View All

Index | Next | Previous | View Threaded

Interested in having your list archived? Contact Gossamer Threads