Re: [Python-Dev] Issues with Py3.1's new ipaddr
On Tue, Jun 2, 2009 at 1:47 AM, Martin v. Löwis mar...@v.loewis.de wrote: If this were a core feature that many developers were anxiously awaiting, I could understand the desire to release and iterate. But is there really a pressing need for an IP library in the stdlib? You should have asked this question a few month ago. Now, release mechanics make it difficult to remove the library, except if a severe problem was uncovered - which you haven't been able to demonstrate. This argument makes no sense. The feasibility of removing the library does not depend on the severity of the issues found within it. Either it is hard to remove the library, or it is easy. If it's hard to remove, it doesn't get any easier because I discover a fatal flaw. I've actually provided several examples of where the library fails when used in common scenarios, yet your solution involves incremental hacks that don't fix the underlying problems. You write as if you have a vested interest in releasing the library -- why? I don't believe that your issue hosts and nets are represented with the same class is severe: it is very well possible to use the IP function to represent individual hosts (including having a string representation that doesn't print a netmask). The only possibly-missing feature is support for rejecting host strings that include a mask on parsing; that can be added in a backwards-compatible way as an optional parameter to the IP function (as discussed on the tracker). There are other missing features, but again, my concern is not about missing features: it's about a quirky API that conflates concepts in the problem domain, leading to subtle bugs and breaking the principle of least surprise. Clay ___ 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] Issues with Py3.1's new ipaddr
Clay McClure wrote: On Tue, Jun 2, 2009 at 1:38 AM, Martin v. Löwis mar...@v.loewis.de wrote: For the net-vs-host issue, I think a backwards-compatible solution is possible: just give the IP() function an option parameter that makes it reject a netmask during parsing. That doesn't solve much. IPv4 objects still always use CIDR notation when coerced to strings, meaning that IP addresses will always be rendered with a trailing /32. That's not true: py x = ipaddr.IP(30.40.50.60) py print(x.ip_ext_full) 30.40.50.60 Such notation is unacceptable in real-world applications that (correctly) distinguish between address and network. So use a different notation that is also supported by the library. That was my feeling as well when ipaddr was first offered. It's just not an important library, and people will continue to roll their own for some time. OTOH, with ipaddr in the standard library, people will also start contributing extensions that make it support their use cases, so it should grow a wider application area than it currently supports. That being the case, why not delay its inclusion until we can be sure that it in fact represents a good base upon which to build? Because we *are* sure that it in fact represents a good base upon which to build. 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] Issues with Py3.1's new ipaddr
This argument makes no sense. The feasibility of removing the library does not depend on the severity of the issues found within it. Either it is hard to remove the library, or it is easy. If it's hard to remove, it doesn't get any easier because I discover a fatal flaw. We could remove it, but then what we have wouldn't really be a release candidate anymore, so the release would get delayed. I've actually provided several examples of where the library fails when used in common scenarios, yet your solution involves incremental hacks that don't fix the underlying problems. You write as if you have a vested interest in releasing the library -- why? I have a vested interest in releasing Python 3.1, and in sticking to decisions that have been made by other committers. I trust these fellow committers, so I defend their decisions. I personally have no plans for using this library, or any other IP address library (at least not in any application I plan to write soon). At the moment, I'm struggling more with IP address libraries in Perl. There are other missing features, but again, my concern is not about missing features: it's about a quirky API that conflates concepts in the problem domain, leading to subtle bugs and breaking the principle of least surprise. I believe the API appears more quirky to you than it actually is, probably because you don't have understood it fully (but I might be wrong with that, and there might be a different reason). 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] Issues with Py3.1's new ipaddr
On Mon, 1 Jun 2009 at 18:54, Jake McGuire wrote:
On Mon, Jun 1, 2009 at 12:16 PM, Martin v. L?wis mar...@v.loewis.dewrote:
As for Clay McLure's issue: I feel it's primarily a matter of taste.
I see nothing morally wrong in using the same class for hosts and
networks, i.e. representing a host as a network of size 1. I can
understand why people dislike that, but I don't see why it would stop
people from doing with the library what they want to do.
To the extent that Clay is having issues, it's because ipaddr.py is poorly
documented, has potentially confusing comments, and he became confused.
Lesser issues are that ipaddr.py doesn't work the way he wants and that ip
addressing is inherently subtle.
Looking at the code in detail shows that ipaddr.IP/IPv4/IPv6 objects always
represent *networks*. He wants one particular address out of that network,
and that requires using __getitem__ or using IP.ip_ext. Neither is
particularly intuitive.
import ipaddr
ip = ipaddr.IPv4('10.33.11.17')
ip
IPv4('10.33.11.17/32')
ip[0]
'10.33.11.17'
Actually I find that very intuitive if I understand that the objects
are always networks.
ip.ip_ext
'10.33.11.17'
That's not intuitive :)
This feels much more like poor documentation than wide-ranging conceptual
flaws.
I could put this in the tracker, but I'm not sure if that's appropriate.
I would say yes, put it in the tracker.
--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] Issues with Py3.1's new ipaddr
On Tue, Jun 2, 2009 at 9:22 AM, R. David Murray rdmur...@bitdance.com wrote: ip[0] '10.33.11.17' Actually I find that very intuitive if I understand that the objects are always networks. I suspect the authors would disagree with you on this point, since they insist that host routes and host addresses are the same thing, but assuming you are right, two flaws are immediately apparent: * The ipaddr classes are poorly named. Since they model networks, they should be named appropriately: IPNet or some such. * The ipaddr authors have overlooked IP addresses, which also deserve first-class treatment in any meaningful IP address library. It is called ipaddr, after all, and not ipnet. ip.ip_ext '10.33.11.17' That's not intuitive :) No, nor is the rest of the library intuitive. This is one of the reasons I've called it quirky. Clay ___ 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] Issues with Py3.1's new ipaddr
On Tue, Jun 2, 2009 at 2:15 AM, Martin v. Löwis mar...@v.loewis.de wrote: We could remove it, but then what we have wouldn't really be a release candidate anymore, so the release would get delayed. How long do release candidates soak in the field before being accepted? I'm curious if an exception could be made in this case, given that you have admitted that ipaddr is not an important library. The chances of a problem being introduced due to its removal are vanishingly small. No other components of the stdlib depend on ipaddr, and the few (approximately zero?) developers who will have started writing applications depending on ipaddr due to its inclusion in the release candidate could simply download the library from Google. I believe the API appears more quirky to you than it actually is, probably because you don't have understood it fully (but I might be wrong with that, and there might be a different reason). I believe the API is quirky because: * It tries to represent distinct domain model concepts in a single class * Its methods and properties are strangely named * Methods and properties that should return domain model objects return native types instead * It cannot correctly parse output from netstat, nor can it correctly pass values to ifconfig You seem comfortable with these quirks, but then you're not planning to write software with this library. Developers who do intend to write meaningful network applications do seem concerned, yet we're ignored. If you consult the issue notes, you'll see objections of the type I just mentioned were raised months ago, yet no work has been done to correct them. The only changes that I can see were related to pedantic style issues: camel case and indentation. Clay ___ 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] Issues with Py3.1's new ipaddr
On Tue, Jun 2, 2009 at 2:08 AM, Martin v. Löwis mar...@v.loewis.de wrote: That doesn't solve much. IPv4 objects still always use CIDR notation when coerced to strings, meaning that IP addresses will always be rendered with a trailing /32. That's not true: py x = ipaddr.IP(30.40.50.60) py print(x.ip_ext_full) 30.40.50.60 Thankfully the authors have provided this obscure and strangely-named method to get at the correct string representation of an IP address, but sadly their __str__ method -- which is the Pythonic way to get string representations of objects -- fails in this regard because they have only one class representing two distinct concepts. I could probably make ipaddr work in my application; that is not the issue (at least in my mind). The issue is that I shouldn't have to work around design flaws in the library when they're simple enough to fix before the library is bundled with the stdlib. I do not see the utility of including ipaddr when my choice as a user is to either use its strangely-named methods instead of obvious Pythonic conventions, or to write my own library. Such notation is unacceptable in real-world applications that (correctly) distinguish between address and network. So use a different notation that is also supported by the library. I'm not referring to my software here -- I'm referring to applications like ifconfig that expect addresses to be formatted properly. If the default string representation produced by the ipaddr library does not match the canonical representation expected by software that has existed as long as IP itself, that indicates to me the library is doing something wrong. Because we *are* sure that it in fact represents a good base upon which to build. You certainly seem convinced. I could not disagree more. Clay ___ 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] Issues with Py3.1's new ipaddr
We could remove it, but then what we have wouldn't really be a release candidate anymore, so the release would get delayed. How long do release candidates soak in the field before being accepted? For this release, the release schedule is defined in PEP 375 I'm curious if an exception could be made in this case, given that you have admitted that ipaddr is not an important library. This would be need to be decided by the release manager. However, given that Guido has already pronounced on this issue, Benjamin is unlikely to change anything. You seem comfortable with these quirks, but then you're not planning to write software with this library. Developers who do intend to write meaningful network applications do seem concerned, yet we're ignored. I don't hear a public outcry - only a single complainer. 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] Issues with Py3.1's new ipaddr
On Tue, 02 Jun 2009 19:34:11 +0200, \Martin v. Löwis\ mar...@v.loewis.de wrote: [snip] You seem comfortable with these quirks, but then you're not planning to write software with this library. Developers who do intend to write meaningful network applications do seem concerned, yet we're ignored. I don't hear a public outcry - only a single complainer. Clay repeatedly pointed out that other people have objected to ipaddr and been ignored. It's really, really disappointing to see you continue to ignore not only them, but the repeated attempts Clay has made to point them out. I don't have time to argue this issue, but I agree with essentially everything Clay has said in this thread, and I commented about these problems on the ticket months ago, before ipaddr was added. Jean-Paul ___ 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] Issues with Py3.1's new ipaddr
We could remove it, but then what we have wouldn't really be a release candidate anymore, so the release would get delayed. Not true. There is a second release candidate scheduled on June 13th. Removing the module involves doing svn remove on two files and updating Misc/NEWS. Yesterday, there was a conversation on IRC (including the RM) where it was discussed. So, in the unlikely event that Guido changes his mind, there is still time to do so. Raymond ___ 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] Issues with Py3.1's new ipaddr
On Tue, Jun 2, 2009 at 10:34 AM, Martin v. Löwis mar...@v.loewis.de wrote: We could remove it, but then what we have wouldn't really be a release candidate anymore, so the release would get delayed. How long do release candidates soak in the field before being accepted? For this release, the release schedule is defined in PEP 375 I'm curious if an exception could be made in this case, given that you have admitted that ipaddr is not an important library. This would be need to be decided by the release manager. However, given that Guido has already pronounced on this issue, Benjamin is unlikely to change anything. You seem comfortable with these quirks, but then you're not planning to write software with this library. Developers who do intend to write meaningful network applications do seem concerned, yet we're ignored. I don't hear a public outcry - only a single complainer. I normally just lurk on python-dev, but I will comment on this thread. I manage several large IP address spaces and I've written my own IP address tools in the past. The comments on the thread motivated me to look at the ipaddr module. I fully agree with Clay's comments. I would not use the module as it stands. I apologize for lurking too much and not commenting earlier. casevh 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/casevh%40gmail.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] Issues with Py3.1's new ipaddr
The chances of a problem being introduced due to its removal are vanishingly small. But that provides little consolation to the user who sees it in the standard library, is not aware to this discussion, and builds it into his app. Changes to the lib later may cause subtle but significant effects. ...perhaps undetected for a while. I don't hear a public outcry - only a single complainer. Clay repeatedly pointed out that other people have objected to ipaddr and been ignored. It's really, really disappointing to see you continue to ignore not only them, but the repeated attempts Clay has made to point them out. I don't have time to argue this issue, but I agree with essentially everything Clay has said in this thread I too agree. If it is not ready, it is not ready. Please don't create problems for others. Remove the lib until it is ready. Larry ___ 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] Issues with Py3.1's new ipaddr
2009/6/2 Bugbee, Larry larry.bug...@boeing.com:
I don't hear a public outcry - only a single complainer.
Clay repeatedly pointed out that other people have objected
to ipaddr and been ignored. It's really, really disappointing
to see you continue to ignore not only them, but the repeated
attempts Clay has made to point them out.
I don't have time to argue this issue, but I agree with
essentially everything Clay has said in this thread
I too agree. If it is not ready, it is not ready. Please don't create
problems for others. Remove the lib until it is ready.
I don't write the sort of code that requires this module very often,
so I guess I class as an example of a casual user who would assume the
stdlib module was best practice, and expect to use it naively to
avoid the more obvious gotchas.
I've just now read the documentation for the first time (after reading
this thread) and for what it's worth here are my thoughts:
* I'd expect separate classes for an IP address and a subnet -
I've no problem with that expectation being wrong, but I'd like some
documentation as to *why* a single class is appropriate. (More
generally, the documentation seems pretty terse). Seeing /32 all
over the place in the examples reinforces my feeling.
* I'm sorry, but ip_ext is a hopeless name. It makes no sense to me.
My first thought was why not just use ip? until I realised that
(contrary to the expectations of a naive user) an IP address is an
integer and that (uncommon???) usage gets to use the ip property
name. But still, why not ip_str at least?
* IP('1.2.3.4') vs IP('1.2.3.0/255.255.255.0') - it seems entirely
sane for the former to have a .ip/.ip_str/.ip_ext property, but
bizarre for the latter to. Explain the principles all you like, it
still seems peculiar.
* To be honest, I'd prefer to have the _ext versions be named without
a suffix, and the currently unsuffixed versions have an _int suffix.
That may reflect my naive expectations, and experts may well expect
the integer forms to be the more easily accessible, but is the library
intended for expert or non-expert users? (That's not a rhetorical
question). The people I work with (DBAs) deal with IP addresses all
the time, but almost certainly aren't even aware that they aren't
strings. If I did a poll, I guess most wouldn't even know that the
components were restricted to 0-255! I can't imagine them being
comfortable with this module.
Reading the documentation, I'd probably end up assuming it was for
experts, and writing my own code rather than using it - which is
probably a sign of failure for the module.
Simple example. If I want to scan all the IP addresses on my network
(my IP address is 192.168.1.101) I'd probably write:
for i in range(253):
ip = '192.168.1.' + str(i+1)
...
- and to heck with generality.
Even after reading the documentation, I've *no idea* how I would use
the ipaddr module to do this better. Let alone in as few lines.
My requirements certainly aren't important enough to drive the design
of the stdlib - and it's possible that these issues are *precisely*
the sort of things that can be fixed with documentation and
backward-compatible changes - but I also think that a bit more time to
address such things would be reasonable.
And I also apologise for not checking the module out sooner. Blame an
assumption that my trivial needs would obviously be covered...
Paul.
___
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] Issues with Py3.1's new ipaddr
On Tue, 2 Jun 2009 at 12:26, Clay McClure wrote:
On Tue, Jun 2, 2009 at 2:08 AM, Martin v. L?wis mar...@v.loewis.de wrote:
py x = ipaddr.IP(30.40.50.60)
py print(x.ip_ext_full)
30.40.50.60
Thankfully the authors have provided this obscure and strangely-named
method to get at the correct string representation of an IP address,
but sadly their __str__ method -- which is the Pythonic way to get
string representations of objects -- fails in this regard because they
have only one class representing two distinct concepts.
Having thought more about this, I will agree with you that it would
be useful to have an address-without-netmask class. I'm thinking about
the cases where having an attached netmask is not particularly helpful,
for example in DNS entries. But there are only two reasons I've so far
come up with why this would be useful: to have a different default output
format, and to have a way to encode an IP so that I can have my code raise
an error if I try to use it in a context where a netmask is required.
(Note, however, that even a DNS entry can conceptually be considered to
be a host route.)
IMO, not having such a class is an inconvenience, not a show stopper,
especially since it seems like one could be added without breaking
backward compatibility. I also don't particularly like the names of
the ipaddr attributes for accessing the IP address-without-netmask or
the netmask-without-ip-address, etc; but again, I don't consider that
a show stopper.
So I'm not in favor of pulling ipaddr from 3.1, and it's too late in
the release cycle to change anything.
I wish you had brought this energy to bear earlier, when changes could
have been made. Reality is what it is, though, and now we should work
on making improvements for the next release. I see in the ticket that
the netaddr folks were going to propose improvements so that they could
build netaddr on top of ipaddr, but I guess that didn't happen (yet?).
I have no association with Google, by the way, and I do intend to use
ipaddr in upcoming code, and have hacked my own address manipulation
stuff in previous code.
Such notation is unacceptable in
real-world applications that (correctly) distinguish between address
and network.
So use a different notation that is also supported by the library.
I'm not referring to my software here -- I'm referring to applications
like ifconfig that expect addresses to be formatted properly. If the
default string representation produced by the ipaddr library does not
match the canonical representation expected by software that has
existed as long as IP itself, that indicates to me the library is
doing something wrong.
I don't understand why you are trying to use ifconfig as an example.
It is actually a counter example to your thesis: when working with an IP
address intended for consumption by ifconfig, you had best be using a
datatype that includes a netmask for that IP, or your code is going to
be broken. What's more, modern versions of ifconfig _do_ accept the
default output format of ipaddr. So this does the Right Thing:
myip = ipaddr.IP('192.168.1.1/26')
system('ifconfig eth0 {}'.format(myip))
If you use your ip-address-only class with ifconfig, you will wind up
using the classful default netmask, which is only going to be correct
by luck.
Hmm. I think there is a conceptual divide here. You have said you
think about IP addresses and networks as separate objects, so I wonder
if you would be pulling the netmask for ifconfig out of a separate
network object?
On the other hand I, a network professional, think about an IP address
paired with a netmask as a fundamental object. Very rarely do I use
an IP address in isolation (without a netmask), and in many of _those_
cases there is an implied netmask of 255.255.255.255. Networks to
me are closely related objects, defined by their network number
(the zero of the subnet, which is an IP address and normally not used
as a host address) and the mask. So to me ipaddr's use of a single
datatype makes reasonable sense. I would, as I said, above, find an
ip-without-netmask data type to be also useful (but a lot less important!)
I would also find a subclass that was network-only (rejects anything
but the zero of the subnet for the IP) useful. But I think both of
those can be implemented fairly trivially as subclasses of the existing
ipaddr objects.
--David
PS: I've looked briefly at netaddr, and while I could probably work with
it by adding some equally trivial support code, I don't think it would
serve my needs as well as ipaddr will. In particular, this is _very_
troubling:
import netaddr
ip = netaddr.IP('192.168.1.1/26')
ip
IP('192.168.1.1/26')
ip2 = netaddr.IP('192.168.1.1/27')
ip2
IP('192.168.1.1/27')
ip == ip2
True
The docs say the netmask is accepted only for user convenience,
but to me the netmask is an integral part of the data entity I want to
manipulate. Nor can I express ip-address-with-netmask using the CIDR
data
Re: [Python-Dev] Issues with Py3.1's new ipaddr
On Tue, Jun 2, 2009 at 9:26 AM, Clay McClure c...@daemons.net wrote:
On Tue, Jun 2, 2009 at 2:08 AM, Martin v. Löwis mar...@v.loewis.de wrote:
That doesn't solve much. IPv4 objects still always use CIDR notation
when coerced to strings, meaning that IP addresses will always be
rendered with a trailing /32.
That's not true:
py x = ipaddr.IP(30.40.50.60)
py print(x.ip_ext_full)
30.40.50.60
Thankfully the authors have provided this obscure and strangely-named
method to get at the correct string representation of an IP address,
but sadly their __str__ method -- which is the Pythonic way to get
string representations of objects -- fails in this regard because they
have only one class representing two distinct concepts.
The minimal demonstration of the problem of representing networks and
addresses using the same class:
container = [1, 2, 3, 4]
for item in container:
... print %s in %s: %s % (item, container, item in container)
...
1 in [1, 2, 3, 4]: True
2 in [1, 2, 3, 4]: True
3 in [1, 2, 3, 4]: True
4 in [1, 2, 3, 4]: True
import ipaddr
container = ipaddr.IP('192.168.1.0/24')
for item in container:
... print %s in %s: %s % (item, container, item in container)
...
Traceback (most recent call last):
File stdin, line 2, in module
File ipaddr.py, line 438, in __contains__
return self.network = other.ip and self.broadcast = other.broadcast
AttributeError: 'str' object has no attribute 'ip'
-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] Issues with Py3.1's new ipaddr
Clay repeatedly pointed out that other people have objected to ipaddr and been ignored. It's really, really disappointing to see you continue to ignore not only them, but the repeated attempts Clay has made to point them out. [I meant to stop discussing here, but I just want comment on this remark] I had seen objections from Victor Stinner, which I did not fully understand, but he seemed to be saying that he is ok with including ipaddr. I had also seen objections from David Moss, which he then seems to have withdrawn. I did not take your message (msg78675 in the tracker) as an objection - you just seemed to express a preference to use netaddr instead. You said it had minor quirks, and some of them have to be removed - but I would not infer that the library should be exclude because of these minor quirks. I don't have time to argue this issue, but I agree with essentially everything Clay has said in this thread, and I commented about these problems on the ticket months ago, before ipaddr was added. I now understand (but honestly didn't understand before) that you are objecting to ipaddr's inclusion, and that you would prefer its removal at this point. 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] Issues with Py3.1's new ipaddr
On Tue, 2 Jun 2009 at 21:02, Paul Moore wrote:
* I'd expect separate classes for an IP address and a subnet -
I've no problem with that expectation being wrong, but I'd like some
documentation as to *why* a single class is appropriate. (More
generally, the documentation seems pretty terse). Seeing /32 all
over the place in the examples reinforces my feeling.
Yeah, the documentation needs a lot of work. Since this is a
subject area I know something about, hopefully I can make time to
contribute something.
* I'm sorry, but ip_ext is a hopeless name. It makes no sense to me.
My guess is that it is ip external representation, as opposed
to the internal representation as an integer. I agree that the
name is terrible.
My first thought was why not just use ip? until I realised that
(contrary to the expectations of a naive user) an IP address is an
integer and that (uncommon???) usage gets to use the ip property
name. But still, why not ip_str at least?
Agreed; unless you are talking to C code, I'd think you'd want the string
representation. This seems like an odd design decision.
* IP('1.2.3.4') vs IP('1.2.3.0/255.255.255.0') - it seems entirely
sane for the former to have a .ip/.ip_str/.ip_ext property, but
bizarre for the latter to. Explain the principles all you like, it
still seems peculiar.
It may seem peculiar, but IMO it is correct. The ip is the zero
of the network, and is just as valid an IP as an ip inside the
network with the same netmask.
* To be honest, I'd prefer to have the _ext versions be named without
a suffix, and the currently unsuffixed versions have an _int suffix.
I agree. I wish I'd looked at this back when it was put in, but I was
a lot busier with other things then :)
That may reflect my naive expectations, and experts may well expect
the integer forms to be the more easily accessible, but is the library
intended for expert or non-expert users? (That's not a rhetorical
question). The people I work with (DBAs) deal with IP addresses all
the time, but almost certainly aren't even aware that they aren't
strings. If I did a poll, I guess most wouldn't even know that the
components were restricted to 0-255! I can't imagine them being
comfortable with this module.
If they don't know that, and they only work with IP addresses in the most
trivial form, then I don't think they would need any of the services this
library provides. That doesn't mean the library is for experts, but
it does mean it's for people who need to manipulate IP addresses within
the context of networks. (If all you need to do is move IP addresses
around, just keep them as strings.)
Hmm. Except I suppose they could use the input validation checking...
I think we've already agreed that adding a flag to IP saying 'no netmask'
is a good idea...if the object created that way would by default output
without a netmask, then the trivial needs of your DBA's would probably
be met.
Reading the documentation, I'd probably end up assuming it was for
experts, and writing my own code rather than using it - which is
probably a sign of failure for the module.
Simple example. If I want to scan all the IP addresses on my network
(my IP address is 192.168.1.101) I'd probably write:
for i in range(253):
ip = '192.168.1.' + str(i+1)
...
- and to heck with generality.
Even after reading the documentation, I've *no idea* how I would use
the ipaddr module to do this better. Let alone in as few lines.
net = ipaddr.IP('192.168.1.0/24'):
for i in range(253):
ip = net[i]
...
So, that's one example that needs to be added to the docs.
I'd have liked to write that as:
for ip in ipaddr.IP('192.168.1.0/24')[:253]:
...
but apparently it doesn't support slicing (time for an RFE :)
My requirements certainly aren't important enough to drive the design
of the stdlib - and it's possible that these issues are *precisely*
the sort of things that can be fixed with documentation and
backward-compatible changes - but I also think that a bit more time to
address such things would be reasonable.
If they are documentation and backward compatible changes (and I believe
they are), why not get the thing into the field so more people can
provide feedback and RFEs?
And I also apologise for not checking the module out sooner. Blame an
assumption that my trivial needs would obviously be covered...
Yeah, me too.
--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] Issues with Py3.1's new ipaddr
On Tue, Jun 2, 2009 at 4:53 PM, R. David Murray rdmur...@bitdance.com wrote:
Having thought more about this, I will agree with you that it would
be useful to have an address-without-netmask class.
Not only useful, but necessary. It seems there are few people on this
list who understand IP well enough to realize how distorted ipaddr
actually is.
(Note, however, that even a DNS entry can conceptually be considered to
be a host route.)
Not at all. A host route and a host address (as represented in DNS)
are fundamentally different concepts. Please see my recent post to
ipaddr-py-dev for a refresher on these concepts:
http://groups.google.com/group/ipaddr-py-dev/t/94d54fe581d24e72
So I'm not in favor of pulling ipaddr from 3.1, and it's too late in
the release cycle to change anything.
I'm not sure why you say that when others have said that another
release candidate is planned, and that removing ipaddr is essentially
trivial to do.
I wish you had brought this energy to bear earlier, when changes could
have been made. Reality is what it is, though, and now we should work
on making improvements for the next release. I see in the ticket that
the netaddr folks were going to propose improvements so that they could
build netaddr on top of ipaddr, but I guess that didn't happen (yet?).
I don't think that can happen, actually. If I was a netaddr committer
(which I'm not), I would find it hard to salvage anything reusable
from ipaddr. It is certainly simpler and clearer to start over with an
object model that actually makes sense.
I have no association with Google, by the way, and I do intend to use
ipaddr in upcoming code, and have hacked my own address manipulation
stuff in previous code.
Sorry, I wasn't aware of that. My mistake. Regardless, I find that
your understanding of IP is similar to that of ipaddr's authors, which
is to say imprecise.
I don't understand why you are trying to use ifconfig as an example.
Because it's an obvious real world example that explains why these two
strings are not equivalent:
192.168.1.1
and
192.168.1.1/32
You and others continue to suggest that those strings are equivalent,
yet ifconfig is a tool that has been around for thirty years that
clearly demonstrates that those strings are not equivalent. If what
you say is true, I should be able to pass either string to ifconfig
and get the same result. That is not the case, because the strings are
not equivalent, because a host route is not the same thing as a host
address.
So this does the Right Thing:
myip = ipaddr.IP('192.168.1.1/26')
system('ifconfig eth0 {}'.format(myip))
Sure, but shouldn't this also do the right thing?
address = ipaddr.IP('192.168.1.1')
netmask = ipaddr.IP('255.255.255.192')
system(ifconfig eth0 %s/%s % (address, netmask))
It doesn't.
Hmm. I think there is a conceptual divide here. You have said you
think about IP addresses and networks as separate objects, so I wonder
if you would be pulling the netmask for ifconfig out of a separate
network object?
Of course, because addresses don't have masks; networks do. This command:
ifconfig en0 192.168.1.1/24
is shorthand for operator convenience. What's going on behind the
scenes is quite a lot different than it looks. First, ifconfig
computes a network address by masking the supplied interface address
with the supplied network mask. It is then able to configure a route
for the proper network: 192.168.1.0/24.
The fact that 192.168.1.1/24 appears in the command does *not* mean
that the address 192.168.1.1 has a mask of /24. That is absurd.
Addresses don't have masks; networks do. That's why they're called
netmasks.
On the other hand I, a network professional, think about an IP address
paired with a netmask as a fundamental object.
The IT industry is unique among engineering disciplines in that formal
training and licensing are typically not required for IT
professionals. Whereas concepts like resistance, current, and voltage
have very specific meanings to electrical engineers, the IT vernacular
is not so precise. Since formal training is rare, and what little is
available is often high-priced and vendor-specific, IT professionals
tend to learn their trade from trade books, word of mouth, and
hands-on experience. As a result, IT professionals tend to have a good
working knowledge of how technology applies to their particular job,
but may not have an appreciation of the more theoretical aspects of
the discipline.
What this means in practice is that your experience as a network
professional may not resemble the experiences of other network
professionals. That you tend to think of addresses as having masks is
probably not universal, or even particularly common, among network
professionals. Some electrical engineers probably think of voltage as
pressure, and that may be a useful abstraction, but I would be
surprised to see a voltmeter calibrated in pascals.
What are we to do? How do we arrive at a common
Re: [Python-Dev] Issues with Py3.1's new ipaddr
Clay McClure clay at daemons.net writes: Not only useful, but necessary. It seems there are few people on this list who understand IP well enough to realize how distorted ipaddr actually is. Not having myself enough knowledge about IP routing and administration (although I did happen to dissect BGP and IS-IS packets in an earlier life), I'm, however, inclined to trust Jean-Paul's word when it comes to network programming. IMHO, we should delay ipaddr's official inclusion in the stdlib until the conceptual issues are solved. 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] Issues with Py3.1's new ipaddr
I've just subscribed to python-dev again after being pointed towards this thread (thanks Raymond). I'd be the first to accept failings and oddities in the interface of my own library. Since its release netaddr has taken its own interesting set of twists and turns. However, all along I have tried to be responsive and accommodating with regard to my users needs and requests for new features and bug fixes. There has been a lot of useful feedback which I have faithfully incorporated into netaddr's codebase. It would be a shame to see all the hard work go to waste on Y.A.P.I.M. :- http://code.google.com/p/netaddr/wiki/YetAnotherPythonIPModule There is a veritable graveyard of stuff out there! Some good, some not so good. The netaddr/ipaddr-py merge went awry and our projects decided to remain separate. I don't see any benefit in raking over those old coals; it's all water under the bridge. That being said, based on the passion in this thread, the decision to include ipaddr-py into the stdlib seems to be proving too hasty and contentious for some. It really might be worth taking a step back and taking heed of those concerns. Having had quite a while to think about this over the last few months, this is what I would ideally like to see. A sensible discussion from a *broad* base of network admins, sysadmins and developers using Python on the formulation of a reasonable functional specification and design for a brand new library (without the associated baggage and vested interests of any particular implementation). This would be an opportunity for us to nail our respective problems and differences while simultaneously bringing together most of the Python community behind code that WE WILL ACTUALLY USE. If this is going in the stdlib surely that is doubly important? If possible, I would particularly like to see input from Victor Stinner, the current IPy maintainer. There as some wrinkles and failings in IPy's interface and implementation but its actually not as bad as I first thought having actually spent some time implementing its interface (mostly successfully) as a facade on top of netaddr. See the netaddr repo if you are interested and *no* it is not supported code ;-) Would this actually be feasible or am I just a hopeless optimist? Should we formulate a PEP even though calls for that have so far been rejected? Possibly PEPs don't apply to libraries? Whoever overseas this would need to be someone with a fairly neutral perspective on all of this. Dave M. ___ 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] Issues with Py3.1's new ipaddr
On 03/06/2009, at 3:56 AM, Jean-Paul Calderone wrote: On Tue, 02 Jun 2009 19:34:11 +0200, \Martin v. Löwis\ mar...@v.loewis.de wrote: [snip] You seem comfortable with these quirks, but then you're not planning to write software with this library. Developers who do intend to write meaningful network applications do seem concerned, yet we're ignored. I don't hear a public outcry - only a single complainer. Clay repeatedly pointed out that other people have objected to ipaddr and been ignored. It's really, really disappointing to see you continue to ignore not only them, but the repeated attempts Clay has made to point them out. I don't have time to argue this issue, but I agree with essentially everything Clay has said in this thread, and I commented about these problems on the ticket months ago, before ipaddr was added. Indeed... Me too - I've been quietly concerned with these issues, but have have not said anything as Clay's postings pretty much cover it (and swine flu response is trumping all my other priorities). ___ 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] Issues with Py3.1's new ipaddr
Well, it sounds like the current incarnation of the ipaddr module is widely loathed, even if it also has some fans. Since it is still available as a 3rd party module, and hasn't been available in other releases except 3.1 beta and rc1, I expect few users will be inconvenienced if we withdraw it at this point. Benjamin, what would be involved in removing it? I suppose there's the module itself, some unit tests, and some docs. (I'm not asking you to remove it yet -- but I'm asking to look into the consequences, so that we can be sure to do the right thing before releasing 3.1 final.) I'm disappointed in the process -- it's as if nobody really reviewed the API until it was released with rc1, and this despite there being a significant discussion about its inclusion and alternatives months ago. (Don't look at me -- I wouldn't recognize a netmask if it bit me in the behind, and I can honestly say that I don't know whether /8 means to look only at the first 8 bits or whether it means to mask off the last 8 bits.) I hope we can learn from this. -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ 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] Issues with Py3.1's new ipaddr
On Tue, Jun 2, 2009 at 1:11 PM, Jake McGuire mcgu...@google.com wrote:
The minimal demonstration of the problem of representing networks and
addresses using the same class:
fwiw, that (hosts vs networks in the same class) is not what you are
demonstrating below. What you demonstrate is that its silly for
iteration over a network to return strings rather than IP objects.
Regardless, it is a good example of a problem with the API.
ipaddr could be changed to yield IPv4 /32 or IPv6 /128 objects when
iterating over it instead of strings and this example would work
properly.
container = [1, 2, 3, 4]
for item in container:
... print %s in %s: %s % (item, container, item in container)
...
1 in [1, 2, 3, 4]: True
2 in [1, 2, 3, 4]: True
3 in [1, 2, 3, 4]: True
4 in [1, 2, 3, 4]: True
import ipaddr
container = ipaddr.IP('192.168.1.0/24')
for item in container:
... print %s in %s: %s % (item, container, item in container)
...
Traceback (most recent call last):
File stdin, line 2, in module
File ipaddr.py, line 438, in __contains__
return self.network = other.ip and self.broadcast = other.broadcast
AttributeError: 'str' object has no attribute 'ip'
Regardless, after reading the many different opinions on this thread
especially including those of other python developers it sounds like
we should not include ipaddr in 3.1.
This example is IMHO one good reason to not include ipaddr in the
standard library as it stands.
It sounds like we have a 3.1rc2 scheduled for June 13th. At this
point based on the multitude of other developer comments in these
threads and barring strong arguments in favor of including it as it
stands I will remove it because there seem to be quite a number of
people with objections to it as an API in its current form.
I've filed http://bugs.python.org/issue6182 as a release blocker to
track its removal (or not) based on any further discussion in these
python-dev threads.
I do believe an API for an ip and network address manipulation library
can be worked out but during the 3.1 release candidate phase is not
the time to hastily do that and choose one so removal due to
disagreement seems the best option.
Would someone volunteer write up a proposal (PEP) for such with a goal
of having it completed within the next few months? (I know people
have suggested various other libraries, that counts; i have not taken
the time to look at them).
-gps
___
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] Issues with Py3.1's new ipaddr
On Tue, Jun 2, 2009 at 7:39 PM, Guido van Rossum gu...@python.org wrote: I'm disappointed in the process -- it's as if nobody really reviewed the API until it was released with rc1, and this despite there being a significant discussion about its inclusion and alternatives months ago. (Don't look at me -- I wouldn't recognize a netmask if it bit me in the behind, and I can honestly say that I don't know whether /8 means to look only at the first 8 bits or whether it means to mask off the last 8 bits.) I hope we can learn from this. Yep, thats a fair summary. Removal will be trivial. Should it only be removed from py3k branch or also from trunk pending a decision as to if the library is reworked or if something else entirely is adopted? ___ 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] Issues with Py3.1's new ipaddr
2009/6/2 Guido van Rossum gu...@python.org: Benjamin, what would be involved in removing it? I suppose there's the module itself, some unit tests, and some docs. (I'm not asking you to remove it yet -- but I'm asking to look into the consequences, so that we can be sure to do the right thing before releasing 3.1 final.) As Raymond and Gregory have pointed out in this thread, the library is quite independent as it stands now in the stlib, so should be trivial to remove. Nothing else should be affected. -- Regards, Benjamin ___ 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] Issues with Py3.1's new ipaddr
2009/6/2 Aahz a...@pythoncraft.com: On Tue, Jun 02, 2009, Guido van Rossum wrote: I hope we can learn from this. I'm not thrilled with adding more process just because we had a problem here, and the only obvious solution I see is to require a PEP every time a module is added. Based on what I've seen of this discussion so far, I think that cure would at this time be worse than the disease. I don't think he's suggesting adding more process yet, just in the diagnosis phase. -- Regards, Benjamin ___ 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] Issues with Py3.1's new ipaddr
On Tue, Jun 2, 2009 at 10:41 PM, Gregory P. Smith g...@krypto.org wrote: ipaddr could be changed to yield IPv4 /32 or IPv6 /128 objects when iterating over it instead of strings and this example would work properly. I have opened an issue in the ipaddr bug tracker that I think addresses this issue. There are a few methods and properties in the ipaddr.IP classes that return native types but should return IP objects: http://code.google.com/p/ipaddr-py/issues/detail?id=21 It sounds like we have a 3.1rc2 scheduled for June 13th. At this point based on the multitude of other developer comments in these threads and barring strong arguments in favor of including it as it stands I will remove it because there seem to be quite a number of people with objections to it as an API in its current form. Thank you. Would someone volunteer write up a proposal (PEP) for such with a goal of having it completed within the next few months? (I know people have suggested various other libraries, that counts; i have not taken the time to look at them). I am happy to take a stab at that. Thanks, Clay ___ 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] Issues with Py3.1's new ipaddr
2009/6/2 Gregory P. Smith g...@krypto.org: Should it only be removed from py3k branch or also from trunk pending a decision as to if the library is reworked or if something else entirely is adopted? I think it should disappear from the whole python tree for the moment. Even the unstable trunk is not a good place for a module pending uncertain, future changes. -- Regards, Benjamin ___ 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] Issues with Py3.1's new ipaddr
On 03/06/2009, at 12:39 PM, Guido van Rossum wrote: I'm disappointed in the process -- it's as if nobody really reviewed the API until it was released with rc1, and this despite there being a significant discussion about its inclusion and alternatives months ago. (Don't look at me -- I wouldn't recognize a netmask if it bit me in the behind, and I can honestly say that I don't know whether /8 means to look only at the first 8 bits or whether it means to mask off the last 8 bits.) I hope we can learn from this. When including third-party modules into the standard library, we've generally only included them after they have broad acceptance in the community. In this case, however, it seems that while the ipaddr module had acceptance within Google, it had not had much exposure to the broader python community. I think if anyone other than Guido had proposed adding the module to the standard library, we would not have even considered it until it had spent some time standing on it's own two feet. ___ 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] Issues with Py3.1's new ipaddr
Aahz writes: On Tue, Jun 02, 2009, Guido van Rossum wrote: I hope we can learn from this. I'm not thrilled with adding more process just because we had a problem here, and the only obvious solution I see is to require a PEP every time a module is added. Based on what I've seen of this discussion so far, I think that cure would at this time be worse than the disease. +1 A couple of people commented that they didn't say anything because they were really busy. I don't think there's much you can do about that, unless the time machine can be used to unmutate the swine flu! FWIW I also agree with Martin's assessment of the thread in the tracker that it looked like there was only one person strongly opposed. Mostly an unfortunate combination of circumstances. One thing I would recommend is that while inclusion is not a matter of voting, people who are recognized as domain experts on Python-Dev *should* try to add their +1 or -1 early. Especially if they don't expect to have time to participate actively in discussion. After all, they can always change their assessment based on either changes or as a response to a persuasive lobby, precisely because it's not a vote. ___ 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
