[issue3959] Add Google's ipaddr.py to the stdlib
Changes by pmoody <[EMAIL PROTECTED]>: -- nosy: +pmoody ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue3959> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3959] Add Google's ipaddr.py to the stdlib
pmoody <[EMAIL PROTECTED]> added the comment: as one of the owners listed in the code.google.com project (same name), and the original author, you certainly have my approval for inclusion in python. ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue3959> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3959] Add Google's ipaddr.py to the stdlib
pmoody added the comment:
I'm biased ;) but I don't see what netaddr provides over ipaddr. it
also seems to be in the neighborhood of 50% slower (at least on my mac
mini).
pmo...@mini - 04:52 PM - ~/Downloads/ipaddr-1.0.1
-> python -m timeit 'import ipaddr;\
ipaddr.IP("1.1.1.1")'
1 loops, best of 3: 46.2 usec per loop
pmo...@mini - 04:52 PM - ~/Downloads/netaddr-0.5.2
-> python -m timeit 'import netaddr;\
netaddr.IP("1.1.1.1")'
1 loops, best of 3: 71.9 usec per loop
dealing with netmasks, the difference is even greater.
pmo...@mini - 04:52 PM - ~/Downloads/ipaddr-1.0.1
-> python -m timeit 'import ipaddr;\
ipaddr.IP("1.1.1.1/255.255.255.0")'
1 loops, best of 3: 78.4 usec per loop
pmo...@mini - 04:49 PM - ~/Downloads/netaddr-0.5.2
-> python -m timeit 'import netaddr;\
> netaddr.IP("1.1.1.1/255.255.255.0")'
1000 loops, best of 3: 247 usec per loop
(and it doesn't seem to deal with hostsmasked addresses).
it also seems to be layed out in an unintuitive way, treating address
ranges a something very different than network addresses. hopefully
someone who isn't intimately familiar with both libraries can comment,
but ipaddr feels a lot cleaner to me.
___
Python tracker
<http://bugs.python.org/issue3959>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3959] Add Google's ipaddr.py to the stdlib
pmoody added the comment:
hm, all addresses have a subnet, even if its an implied /32, so
specifying a network as ("1.1.1.0", "1.1.1.255") seems a lot more
off-putting than "1.1.1.0/24". You're also much more likely to see the
latter in network devices. I guess I don't see the utility in an address
range of .1 - .22 (or something arbitrary, something which doesn't fall
on a power-of-2 boundary); when dealing with ranges of addresses, i've
always only wanted to/needed to manipulate sub-networks of addresses.
and my expectation was always that method names, etc. would have to be
converted to more closely match other python code; ipaddr was written to
google's python style guide, which I understand can be different than
the python.org style guide ;)
also, ipaddr does make extensive use of pydoc, but you're right, the
webpage is spartan.
happy (PST) new year.
Cheers,
/peter
___
Python tracker
<http://bugs.python.org/issue3959>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3959] Add Google's ipaddr.py to the stdlib
pmoody added the comment:
> I'm not sure which API in netaddr you're referring to. If you want to
> construct that /24 with netaddr, then I would use
> netaddr.address.CIDR("1.1.1.0/24"). Offhand, I can't find an API which
netaddr.AddrRange
class AddrRange(__builtin__.object)
| A block of contiguous network addresses bounded by an arbitrary start and
| stop address. There is no requirement that they fall on strict bit mask
| boundaries, unlike L{CIDR} addresses.
|
| __init__(self, first, last, klass=)
| Constructor.
|
| @param first: start address for this network address range.
|
| @param last: stop address for this network address range.
|
| @param klass: (optional) class used to create each object returned.
| Default: L{Addr()} objects. See L{nrange()} documentations for
| additional details on options.
when looking through the code.google.com wiki, I couldn't find any
examples of creating addresses with netmasks and AddrRange was the
first thing I found when looking through pydoc.
> accepts two endpoints of a range to construct a network in netaddr.
> When I wrote about having separate types for individual addresses vs
> ranges of addresses in my previous comment, I had IP and CIDR
> respectively in mind, as opposed to ipaddr-py's single IPv4 class which
> can represent either.
and still having two separate classes represent the same thing seems odd to me.
___
Python tracker
<http://bugs.python.org/issue3959>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3959] Add Google's ipaddr.py to the stdlib
pmoody added the comment: > That is not sufficient for inclusion to Python. We also want support > from the author (along with a promise to eventually give up the external > project). As Guido had mentioned in a previous message, this is along the lines of my thinking wrt ipaddr. Cheers, /peter ___ Python tracker <http://bugs.python.org/issue3959> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3959] Add Google's ipaddr.py to the stdlib
pmoody added the comment: > Good idea. > > Peter M. and the ipaddr contributors, are you all happy to proceed in > accordance with Duncan's suggestions? If so, let's kick off a thread on > python-dev to get the ball rolling and see what we can come up with. I'm fine with this. But as Duncan mentioned, some guidance from the benevolent powers that be on what exactly they're looking for before we launch into a bunch of work would be appreciated. Cheers, /peter ___ Python tracker <http://bugs.python.org/issue3959> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3959] Add Google's ipaddr.py to the stdlib
pmoody added the comment: (kicking an old thread) On Mon, Jan 5, 2009 at 11:21 AM, Guido van Rossum wrote: > > Guido van Rossum added the comment: > > I've been on vacation and unable to follow this, and won't have time to > catch up now. Note that I have no vested interest in Google's module > except knowing it has many happy users (I have never used it myself -- > but Collin Winter has and he tells me it's great). > > Since I haven't used either module and am not particularly interested in > this functionality, I'm withdrawing myself from the set of experts who > can decide which is better. > > Duncan McGreggor asked some questions on python-dev; here are my responses: > >> * do we want to limit it to IP (i.e. no EUI/MAC support)? > > I don't want to exclude EUI/MAC support, but it seems quit a separate > (and much more specialized) application area, so it's probably best to > keep it separate (even if it may make sense to use a common (abstract > or concrete) base class or just have similar APIs). > >> * do we want a single module or is a package acceptable? > > I don't care either way. > >> * other thoughts? > > How about a merger? so we've talked about this on the ipaddr/netaddr lists and it seems like a merger is pretty unlikely. ipaddr and netaddr have some pretty fundamental design differences, to the point where a merger wouldn't mean a complete re-write of one or the other (in which case we're back to picking one over the other). so I guess a decision needs to be made. Is this something that should be made on python-dev or does this bug have enough visibility? for ipaddr's part, trunk is now pep8 compliant (with some backwards compatible aliases). I also know that David hasn't stopped adding features to netaddr as well. So, where do we go from here? Cheers, /peter > ___ > Python tracker > <http://bugs.python.org/issue3959> > ___ > ___ Python tracker <http://bugs.python.org/issue3959> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3959] Add Google's ipaddr.py to the stdlib
pmoody added the comment: > I could live with such a choice if the netaddr authors agree that it > is the right choice (them being experts themselves in the domain). > I don't want to be accused of drkjam's accusation of fast-tracking > code just because it comes from Google (which would be a false > accusation regardless, but there is no reason to make some Python > users unhappy because they feel they are subject to political games). in light of david's email, would you agree that the bar for buy-in has been met or should I now start writing a PEP and preparing offerings for the BDFL? Cheers, /peter ___ Python tracker <http://bugs.python.org/issue3959> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17400] ipaddress.is_private needs to take into account of rfc6598
pmoody added the comment: I'm still not convinced. The rfc still says in essence "It's not private like rfc1918 space, but sometimes certain people can treat it similarly." and I think it would be pretty surprising for ipaddress to return True if it's not a network operator running the query. Since we have no way of knowing that, I'm extremely disinclined to make this change. A more formal solution would be all of the possible "is_RFC" methods, but that doesn't seem to be worth the effort. -- resolution: -> rejected status: open -> closed ___ Python tracker <http://bugs.python.org/issue17400> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17400] ipaddress.is_private needs to take into account of rfc6598
pmoody added the comment: is_private was, as you note, basically shorthand for is_RFC1918 (and is_RFC4193 for v6). It's not a particularly well-named method, but at the time that I wrote it (~5 years ago?), it did what I needed it to do. I'm not sure what you mean by an 'is_natted()' method; there's nothing in particular preventing someone from natting a globally unique address. is_global() makes some sense to me, and it appears that I most likely have to update is_reserved, but I don't understand is_forwardable(). -- ___ Python tracker <http://bugs.python.org/issue17400> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17400] ipaddress should make it easy to identify rfc6598 addresses
pmoody added the comment: The problem is that 'shared' describes exactly one network, unless you mean that we should try to start 'private' as 'shared'. That's something I really don't want to do because it leads to confusion like this. Do you not think that is_global or is_forwardable (per the iana registry) is worthwhile? -- ___ Python tracker <http://bugs.python.org/issue17400> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14814] Implement PEP 3144 (the ipaddress module)
pmoody added the comment: I'm not sure if this is still an issue, but returning the address in a packed format was an early issue (http://code.google.com/p/ipaddr-py/issues/detail?id=14). No objections from me for removing it from the network objects or for removing the packed constructor (I'm assuming there isn't any python-ism about being able to copy-construct an object from any valid representation of said object) -- ___ Python tracker <http://bugs.python.org/issue14814> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14814] Implement PEP 3144 (the ipaddress module)
pmoody added the comment: Hynek, I don't see that error when I run the tests on a freshly built python. -- ___ Python tracker <http://bugs.python.org/issue14814> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14814] Implement PEP 3144 (the ipaddress module)
pmoody added the comment: Reported externally, ipaddress tries to parse 4 character strings as bytes. https://groups.google.com/forum/?hl=en_US&fromgroups#!topic/ipaddr-py-dev/j6FkeJtsBz4 -- Added file: http://bugs.python.org/file26210/ipaddress-bytes-str.diff ___ Python tracker <http://bugs.python.org/issue14814> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14814] Implement PEP 3144 (the ipaddress module)
pmoody added the comment: one more patch, superseding the last patch. also reported externally, the v6 parser would incorrectly parse some v6 addresses. http://code.google.com/p/ipaddr-py/issues/detail?id=97 -- Added file: http://bugs.python.org/file26211/ipaddress-bytes-str-v6-parsing.diff ___ Python tracker <http://bugs.python.org/issue14814> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14814] Implement PEP 3144 (the ipaddress module)
pmoody added the comment: There's no reason why IPv?Network().with_prefixlen can't return str(self). -- ___ Python tracker <http://bugs.python.org/issue14814> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14814] Implement PEP 3144 (the ipaddress module)
pmoody added the comment: sorry, yes, I meant the interface classes. -- ___ Python tracker <http://bugs.python.org/issue14814> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16531] Allow IPNetwork to take a tuple
pmoody added the comment: fine by me. this has been on my todo list forever by $payingjob and $family have prevented me from devoting any time. -- ___ Python tracker <http://bugs.python.org/issue16531> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16531] Allow IPNetwork to take a tuple
pmoody added the comment: on it. I'm not a huge fan of integer args for the first argument because of possible confusion between v4/v6. -- ___ Python tracker <http://bugs.python.org/issue16531> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16531] Allow IPNetwork to take a tuple
pmoody added the comment: This patch is for (address, prefixlen). I now see that the original request was (address, netmask). I'll fix this up. In the meantime, let me know if this is what you had in mind. Cheers, peter -- keywords: +patch Added file: http://bugs.python.org/file28233/issue16531.patch ___ Python tracker <http://bugs.python.org/issue16531> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16531] Allow IPNetwork to take a tuple
pmoody added the comment: Sorry. I thought I'd uploaded this earlier. I'm working on a version that pushes the parsing into _split_optional_netmask -- Added file: http://bugs.python.org/file28402/issue16531-2.patch ___ Python tracker <http://bugs.python.org/issue16531> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17400] ipaddress should make it easy to identify rfc6598 addresses
pmoody added the comment: ok, here's an is_global/is_private patch using the iana special registry for ipv4 and ipv6. -- keywords: +patch Added file: http://bugs.python.org/file31851/issue.17400.patch ___ Python tracker <http://bugs.python.org/issue17400> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18805] ipaddress netmask/hostmask parsing bugs
pmoody added the comment: I've got a patch from pmarks that I've applied to ipaddr and the google code version of ipaddress-py. I'll get it applied to the hg ipaddress. -- ___ Python tracker <http://bugs.python.org/issue18805> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17400] ipaddress should make it easy to identify rfc6598 addresses
pmoody added the comment: I have a change that needs to be submitted for the parser then I'll come back to the caching. The pedant in me would like like to keep the addresses ordered because that makes it clear where to add new networks as iana changes classifications, but it may just make more sense to put rfc1918 at the top. -- ___ Python tracker <http://bugs.python.org/issue17400> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17400] ipaddress should make it easy to identify rfc6598 addresses
pmoody added the comment: antoine, quite right. I've updated is_global. Nick, I've added lru_cache() to is_private and updated the docs (hope it's right this time). -- ___ Python tracker <http://bugs.python.org/issue17400> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue19157] ipaddress.IPv6Network.hosts function omits network and broadcast addresses
pmoody added the comment: Ack. My first impression is that #1 is probably the right way to do this. I'm arguing with hg about the right way to stash a change, but I'll get this fixed. -- assignee: -> pmoody ___ Python tracker <http://bugs.python.org/issue19157> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20563] Mark ipaddress as stable?
pmoody added the comment: Works for me. I was going to say that there was still the issue with the mask parsing which turned out to be more difficult than simply applying the ipaddress-py patch but it looks like you've managed to get that applied. I spent a few hours banging my head on the keyboard before. -- ___ Python tracker <http://bugs.python.org/issue20563> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue19157] ipaddress.IPv6Network.hosts function omits network and broadcast addresses
pmoody added the comment: Since there's no broadcast address for ipv6, should calling .broadcast* on an ipv6 address raise an exception? -- ___ Python tracker <http://bugs.python.org/issue19157> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue19157] ipaddress.IPv6Network.hosts function omits network and broadcast addresses
pmoody added the comment: Hey Michiel, the patch looks good to me. Have you signed the contributor license agreement? http://www.python.org/psf/contrib/contrib-form/ Nick, is there anyway for me to check if this has been signed? -- ___ Python tracker <http://bugs.python.org/issue19157> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue19157] ipaddress.IPv6Network.hosts function omits network and broadcast addresses
Changes by pmoody : -- status: open -> closed ___ Python tracker <http://bugs.python.org/issue19157> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20815] ipaddress unit tests PEP8
pmoody added the comment: Nick, did you want me to apply this? -- ___ Python tracker <http://bugs.python.org/issue20815> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20826] Faster implementation to collapse consecutive ip-networks
pmoody added the comment: Hey Exhuma, thanks for the patch. Can you give me an example list on which this shift reduce approach works much better? -- assignee: -> pmoody ___ Python tracker <http://bugs.python.org/issue20826> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20825] containment test for "ip_network in ip_network"
pmoody added the comment: subnet_of and supernet_of also avoid confusion with the IP?Interface classes (which incidentally can be used in 'a in b' containment tests). Michael, have you signed the contributor license agreement? I don't think I have anyway of seeing if you have or not and I think you need to sign it for me to apply you patch. http://www.python.org/psf/contrib/contrib-form/ -- assignee: -> pmoody ___ Python tracker <http://bugs.python.org/issue20825> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20825] containment test for "ip_network in ip_network"
pmoody added the comment: Thanks! -- ___ Python tracker <http://bugs.python.org/issue20825> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue19157] ipaddress.IPv6Network.hosts function omits network and broadcast addresses
pmoody added the comment: Yes, I think omitting the broadcast address in the usable hosts was a bug. -- ___ Python tracker <http://bugs.python.org/issue19157> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20815] ipaddress unit tests PEP8
pmoody added the comment: Will Do. Michael, would you mind signing the contributor agreement so I can apply your patch? http://www.python.org/psf/contrib/contrib-form/ -- ___ Python tracker <http://bugs.python.org/issue20815> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20815] ipaddress unit tests PEP8
pmoody added the comment: thanks. -- ___ Python tracker <http://bugs.python.org/issue20815> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3959] Add Google's ipaddr.py to the stdlib
pmoody added the comment: Are there any committers who'd be able to help get this integrated? Martin is booked solid until April and that would apparently jeopardize the inclusion of ipaddr in python 3.1. Cheers, /peter On Wed, Feb 4, 2009 at 11:27 AM, Martin v. Löwis wrote: > > Martin v. Löwis added the comment: > >> in light of david's email, would you agree that the bar for buy-in has >> been met or should I now start writing a PEP and preparing offerings >> for the BDFL? > > Yes, I think it can be integrated now. I'll look into it, unless > somebody is faster (it could well take some weeks until I find some > time) > > ___ > Python tracker > <http://bugs.python.org/issue3959> > ___ > ___ Python tracker <http://bugs.python.org/issue3959> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3959] Add Google's ipaddr.py to the stdlib
pmoody added the comment: I'll submit a change for this to trunk in a second. On Fri, May 1, 2009 at 1:16 PM, Antoine Pitrou wrote: > > Antoine Pitrou added the comment: > > Is there any chance the test methods in test_ipaddr can be PEP8-ified? > > -- > > ___ > Python tracker > <http://bugs.python.org/issue3959> > ___ > -- ___ Python tracker <http://bugs.python.org/issue3959> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3959] Add Google's ipaddr.py to the stdlib
pmoody added the comment: well, sent it for review anyway. is this a showstopper for submission? On Fri, May 1, 2009 at 1:19 PM, pmoody wrote: > > pmoody added the comment: > > I'll submit a change for this to trunk in a second. > > On Fri, May 1, 2009 at 1:16 PM, Antoine Pitrou wrote: >> >> Antoine Pitrou added the comment: >> >> Is there any chance the test methods in test_ipaddr can be PEP8-ified? >> >> -- >> >> ___ >> Python tracker >> <http://bugs.python.org/issue3959> >> ___ >> > > -- > > ___ > Python tracker > <http://bugs.python.org/issue3959> > ___ > -- ___ Python tracker <http://bugs.python.org/issue3959> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3959] Add Google's ipaddr.py to the stdlib
pmoody added the comment:
On Mon, Jun 1, 2009 at 1:33 PM, Clay McClure wrote:
>
> Clay McClure added the comment:
>
> On Mon, Jun 1, 2009 at 1:09 PM, Martin v. Löwis
> wrote:
>
>>> My hope is that now that a library has been selected, it can be improved
>>> before Python 2.7 and 3.1 ship.
>>
>> That is fairly unlikely. The 3.1 release candidate has been produced,
>> so the only options possible at this point are to either go ahead with
>> what is in the code, or withdraw the library from 3.1 if it can be
>> demonstrated to have severe flaws.
>
> False
>>>> ipaddr.IPv4('192.168.1.1') == ipaddr.IPv4('192.168.1.1/32')
> True
>
> ipaddr makes no distinction between two fundamentally different
> concepts -- to my mind, that is a serious flaw.
I don't see these a fundamentally different, I guess. can you
demonstrate how this equivalency makes ipaddr unusable?
> ipaddr has many other quirks that, while not technically flaws, are
> design warts that deserve to be fixed before its target audience is
> amplified by its inclusion in the stdlib.
I haven't seen any new issues on code.google.com (and I haven't heard
of any being reported on the python bugtracker), so since you're using
this thread to report issues, can you elaborate?
> To those arguing for ipaddr's inclusion in the stdlib, how many of you
> will actually use ipaddr to develop software? As an actual developer
> of network scanning and discovery software, I can tell you that I
> would rather roll my own library than use ipaddr as it exists today.
have used it to develop software and will continue to use it to
develop software.
Cheers,
/peter
> Clay
>
> --
>
> ___
> Python tracker
> <http://bugs.python.org/issue3959>
> ___
>
--
___
Python tracker
<http://bugs.python.org/issue3959>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3959] Add Google's ipaddr.py to the stdlib
pmoody added the comment:
On Mon, Jun 1, 2009 at 4:41 PM, Clay McClure wrote:
>
> Clay McClure added the comment:
>
> On Mon, Jun 1, 2009 at 5:02 PM, R. David Murray
> wrote:
>
>>> >>> ipaddr.IPv4('192.168.1.1') == ipaddr.IPv4('192.168.1.1/32')
>>> True
>>
>> As a network engineer I don't see any inherent problem with that equality.
>> In fact I make use of that conceptual equality on a regular basis.
>
> For an example of why 192.168.1.1 != 192.168.1.1/32, look no further
> than ifconfig:
>
> # ifconfig en0 192.168.1.1/32
> # ifconfig en0
> en0: flags=8863 mtu 1500
> inet 192.168.1.1 netmask 0x broadcast 192.168.1.1
> ...
>
> # ifconfig en0 192.168.1.1
> # ifconfig en0
> en0: flags=8863 mtu 1500
> inet 192.168.1.1 netmask 0xff00 broadcast 192.168.1.255
> ...
>
> Can you provide an example of when 192.168.1.1 does in fact equal
> 192.168.1.1/32?
what this shows is that your copy of darwin defaults to a /24
prefixlen; ipaddr assumes a /32 prefixlen. I don't see anything
particularly *more* intuitive with darwin, but in any event, it seems
to provide support for assuming a prefixlen when none is supplied.
>
> ___
> Python tracker
> <http://bugs.python.org/issue3959>
> ___
>
--
___
Python tracker
<http://bugs.python.org/issue3959>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3959] Add Google's ipaddr.py to the stdlib
pmoody added the comment:
On Mon, Jun 1, 2009 at 5:47 PM, Clay McClure wrote:
>
> Clay McClure added the comment:
>
> On Mon, Jun 1, 2009 at 4:54 PM, Martin v. Löwis
> wrote:
>
>> Do you have an application in mind where this lack of distinction
>> would prevent writing the application in a straight-forward way?
>> IOW, could you do something if they were distinct that you can't
>> do because they are not?
>
> Consider applications that use ipaddr.IPv4 objects to configure
> network interfaces:
>
> ifconfig: 255.255.255.0/32: bad value
>
> That's because ipaddr wrongly appends a prefix length to all
> ipaddr.IPv4 objects, even those representing addresses, which do not
> have prefix lengths.
I'm not sure what you're trying to do here, can you elaborate?
> Consider applications that need to validate addresses (or networks,
> but not both) supplied as user input:
>
> address = ipaddr.IP(input)
>
> if isinstance(address, ipaddr.IPv4):
> if address.prefixlen != 32:
> raise TypeError("Expecting IP address, not network")
> elif isinstance(address, ipaddr.IPv6):
> if address.prefixlen != 128:
> raise TypeError("Expecting IP address, not network")
i'm not sure what's onerous about this code. you're missing a
try/except around ipaddr.IP(), but otherwise it seems fine.
> Given its myriad quirks, it is really rather surprising that ipaddr is
> being considered for inclusion in the Python stdlib.
it's actually already been included, but that's beside the point. I'm
now asking you a second time to submit bug reports if there are issues
which you see; perhaps these 'myriad of quirks' can be fixed, perhaps
not. yelling here doesn't actually do anything productive.
> Clay
>
> --
>
> ___
> Python tracker
> <http://bugs.python.org/issue3959>
> ___
>
--
___
Python tracker
<http://bugs.python.org/issue3959>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3959] Add Google's ipaddr.py to the stdlib
pmoody added the comment:
On Mon, Jun 1, 2009 at 7:38 PM, Clay McClure wrote:
>
> Clay McClure added the comment:
>
> On Mon, Jun 1, 2009 at 9:03 PM, pmoody wrote:
>
>>> ifconfig: 255.255.255.0/32: bad value
>>>
>>> That's because ipaddr wrongly appends a prefix length to all
>>> ipaddr.IPv4 objects, even those representing addresses, which do not
>>> have prefix lengths.
>>
>> I'm not sure what you're trying to do here, can you elaborate?
>
> Let's say I have a UI that prompts users for two pieces of
> information: interface address, and network mask. I then take those
> two strings and make ipaddr.IPv4 objects out of them. This lets me
> validate their correctness, and lets me perform convenient
> calculations and tests (things the ipaddr library has done well).
> Next, I take the IPv4 objects, coerce them to strings, and pass them
> to ifconfig to configure an interface.
>
> Assuming the user has supplied this information:
>
> Interface address = '192.168.1.1'
> Network mask = '255.255.255.0'
>
> the following would get passed to ifconfig:
>
> ifconfig en0 192.168.1.1/32 netmask 255.255.255.0/32
I suppose that might be the case if you didn't know how to use ipaddr.
knowing that ipaddr accepts an ipaddress/netmask, I'd pass it
my_ip = ipaddr.IP('%s/%s' % (ipaddress, netmask))
and then check for any exceptions. I'd then ifconfig en0 str(my_ip)
> Clearly this is not what we expect, nor even legal. The principle of
> least surprise is violated here, if nothing else.
>
> We could work around this, of course, but why should we have to work
> around our libraries when simply fixing them isn't that hard?
>
>>> if isinstance(address, ipaddr.IPv4):
>>> if address.prefixlen != 32:
>>> raise TypeError("Expecting IP address, not network")
>>> elif isinstance(address, ipaddr.IPv6):
>>> if address.prefixlen != 128:
>>> raise TypeError("Expecting IP address, not network")
>>
>> i'm not sure what's onerous about this code. you're missing a
>> try/except around ipaddr.IP(), but otherwise it seems fine.
>
> Your definition of onerous apparently differs from mine :)
>
> In my own applications, when I'm expecting a network, I use an
> IPNetwork class, and when I'm expecting an address, I use an IPAddress
> class. This means I can simply rely on the class constructors to do
> the type checking for me. With ipaddr, I have to do the validation
> myself. Simple isinstance() testing and duck typing don't work because
> networks and addresses are represented (wrongly) by the same class.
so ipaddr doing this validation for the user actually could make some
sense, but this could be fixed by something as easy
ipaddr.IP(ip, network=False)
or
ipaddr.IP(net, network=True)
anyway (more below)...
>> it's actually already been included, but that's beside the point. I'm
>> now asking you a second time to submit bug reports if there are issues
>> which you see; perhaps these 'myriad of quirks' can be fixed, perhaps
>> not. yelling here doesn't actually do anything productive.
>
> Rest assured, I've opened one issue and will open one or two more
> before the night is out.
cool, I see that you did that. as an aside, this probably isn't the
best place for continued discussion on ipaddr. ipaddr has already been
shipped with python, so i'm not sure that debate on it's inclusion is
able to influence that decision. All of the folks who've worked on
ipaddr + the python committer are on ipaddr-py-...@googlegroups.com
(looks like you are too), so might I suggest we continue this
discussion there?
> I'm sorry that you think "yelling" is unproductive. I happen to think
> that healthy debate breeds better code.
I think debate is healthy, too. but I measure my success at a debate
by my ability to convince other people of my side. I find I have
better success when I listen other people and respond with respect.
yelling promotes neither of those.
Cheers,
/peter
> Cheers,
>
> Clay
>
> --
>
> ___
> Python tracker
> <http://bugs.python.org/issue3959>
> ___
>
--
___
Python tracker
<http://bugs.python.org/issue3959>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3959] Add Google's ipaddr.py to the stdlib
pmoody added the comment: > I should think you would seek the opinion of those developers who > actually do have plans to use an IP address library. That's what this has been doing for the last 8 1/2 months. > As far as I can > tell, every developer in that category, outside of Google, that has > commented on this issue here or in python-dev has advocated a > different API. Is there some sort of conspiracy theory-ish reason that a google software engineer might be somehow unfairly influenced? Cheers, /peter -- ___ Python tracker <http://bugs.python.org/issue3959> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue27628] ipaddress incompatibility with ipaddr: __contains__ between networks
Changes by pmoody : -- assignee: pmoody -> ___ Python tracker <http://bugs.python.org/issue27628> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17400] ipaddress.is_private needs to take into account of rfc6598
pmoody added the comment: I don't see anyway to actually assign this bug to myself, but I'll get a patch for this. -- nosy: +pmoody ___ Python tracker <http://bugs.python.org/issue17400> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17400] ipaddress.is_private needs to take into account of rfc6598
pmoody added the comment: Is the request that is_private should return true for all reserved/non-routable addresses? The docstrings refer to specific rfcs which don't cover most of the addresses listed in the wikipedia page. I haven't done a lot of network programming in the last couple of years, so what do folks think the least surprising result here would be? -- ___ Python tracker <http://bugs.python.org/issue17400> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17400] ipaddress.is_private needs to take into account of rfc6598
pmoody added the comment: So I'm not convinced that 6598 space should be treated like 1918 space. Specifically, the second paragraph of the rfc states: Shared Address Space is distinct from RFC 1918 private address space because it is intended for use on Service Provider networks. However, it may be used in a manner similar to RFC 1918 private address space on routing equipment that is able to do address translation across router interfaces when the addresses are identical on two different interfaces. Details are provided in the text of this document. which I read as, "It's not private like rfc1918 space, but sometimes certain people can treat it similarly." Are there more convincing arguments for treating 6598 like 1918? -- ___ Python tracker <http://bugs.python.org/issue17400> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22800] IPv6Network constructor sometimes does not recognize legitimate netmask
pmoody added the comment: > # We only support CIDR for IPv6, because expanded netmasks are not > # standard notation. Yes, that's correct. I can double check this, but when I wrote ipaddress, I had yet to encounter a v6 netmask in anything other than cider notation. -- ___ Python tracker <http://bugs.python.org/issue22800> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22800] IPv6Network constructor sometimes does not recognize legitimate netmask
pmoody added the comment: Hey Chris, What's the usecase for this? the netmask notation doesn't appear to be common for v6 (at all), so I'm hesitant to add support for this if it's just something like an academic exercise. Cheers, peter -- ___ Python tracker <http://bugs.python.org/issue22800> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22800] IPv6Network constructor sometimes does not recognize legitimate netmask
pmoody added the comment: If you have the ability to use cidr, then closing this as wontfix is my preference. I've heard that there might be some network vendors that are starting support the mask notation for v6 addresses though, so this may end up getting implemented at some point in future anyway. -- resolution: -> wont fix status: open -> closed ___ Python tracker <http://bugs.python.org/issue22800> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
