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
2009/6/2 Bugbee, Larry <larry.bugbee@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.
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
2009/6/2 R. David Murray <rdmurray@bitdance.com>:
On Tue, 2 Jun 2009 at 21:02, Paul Moore wrote:
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 :)
Given that what I *want* to do is to skip the "special" cases of 0 and 255, would the following work? net = ipaddr.IP('192.168.1.101/255.255.255.0') # Note 1 for ip in net: if ip.ip = ip.broadcast or ip.is_multicast(): continue ... That would be what I mean by the module helping me to avoid "gotchas" - like assuming 0 and 255 are the "special" multicast and broadcast (or whatever they are) addresses that I shouldn't be testing in my port scanner. I'd like a .is_broadcast() method. Does that expose my lack of understanding, or is it a sensible thing to add? Note 1 - by the way, I use this form because I don't understand how the /24 notation works. I can get the subnet mask from ipconfig, so I use that. Ideally, I'd rather just put my IP address and have the module work out the "obvious" subnet (at my level of use, it's always 255.255.255.0 for 192.168 addresses) but I guess that's not actually a well-defined idea. Paul.
Paul Moore wrote:
Note 1 - by the way, I use this form because I don't understand how the /24 notation works. I can get the subnet mask from ipconfig, so I use that.
<OT> It's just a shorthand way of writing IPv4 net masks based on their binary form: /8 = 8 ones followed by 24 zeroes = 255.0.0.0 /16 = 16 ones followed by 16 zeroes = 255.255.0.0 /24 = 24 ones followed by 8 zeroes = 255.255.255.0 /30 = 30 ones followed by 2 zeroes = 255.255.255.252 /32 = 32 ones followed by no zeroes = 255.255.255.255 It's particularly convenient when you're dividing subnets up into chunks that don't align with a byte boundary in the IPv4 address (e.g. /27 can easily be recognised as giving a subnet containing 2**5 = 32 hosts, but the subnet size is significantly less obvious when written using the equivalent 255.255.255.224 netmask). </OT> Cheers, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia ---------------------------------------------------------------
participants (4)
-
Bugbee, Larry -
Nick Coghlan -
Paul Moore -
R. David Murray