Re: [issue3959] Add Google's ipaddr.py to the stdlib

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 fro

[issue3959] Add Google's ipaddr.py to the stdlib

Changes by Alexander Belopolsky : -- nosy: +belopolsky ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http://ma

[issue3959] Add Google's ipaddr.py to the stdlib

Gregory P. Smith added the comment: This issue is closed. Please take discussion up on a mailing list. -- ___ Python tracker ___ ___

[issue3959] Add Google's ipaddr.py to the stdlib

Clay McClure added the comment: On Tue, Jun 2, 2009 at 2:52 AM, pmoody wrote: >> 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

[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 ha

[issue3959] Add Google's ipaddr.py to the stdlib

Clay McClure added the comment: On Tue, Jun 2, 2009 at 2:18 AM, Martin v. Löwis wrote: >> I'd like to see the issues fixed upstream, and the library removed >> from Python until it is satisfactory to the developers who will >> actually use it. To my knowledge, every developer (outside of Googl

[issue3959] Add Google's ipaddr.py to the stdlib

Martin v. Löwis added the comment: > I'd like to see the issues fixed upstream, and the library removed > from Python until it is satisfactory to the developers who will > actually use it. To my knowledge, every developer (outside of Google) > who has commented on the issue has indicated a prefe

[issue3959] Add Google's ipaddr.py to the stdlib

Gregory P. Smith added the comment: > 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 addres

[issue3959] Add Google's ipaddr.py to the stdlib

Clay McClure added the comment: On Tue, Jun 2, 2009 at 1:21 AM, Martin v. Löwis wrote: >> I will go ahead and open issues on code.google.com. > > If you want to see them fixed in Python, please report them to this > tracker. I'd like to see the issues fixed upstream, and the library removed f

[issue3959] Add Google's ipaddr.py to the stdlib

Martin v. Löwis added the comment: > I will go ahead and open issues on code.google.com. If you want to see them fixed in Python, please report them to this tracker. -- ___ Python tracker _

[issue3959] Add Google's ipaddr.py to the stdlib

Martin v. Löwis added the comment: > Consider applications that need to validate addresses (or networks, > but not both) supplied as user input: > > address = ipaddr.IP(input) If that is a frequent need, it would be reasonable to add an API address = ipaddr.IP(input, allow_mask=False) which

[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

[issue3959] Add Google's ipaddr.py to the stdlib

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

[issue3959] Add Google's ipaddr.py to the stdlib

Clay McClure added the comment: On Mon, Jun 1, 2009 at 8:05 PM, R. David Murray wrote: > In pre-CIDR days, assuming a prefixlen of 24 for a 192.168.x.x address > made sense.  Nowadays it is better not to make that assumption.  So I > find ipaddr's default of 32 to be "safer" than using a class

[issue3959] Add Google's ipaddr.py to the stdlib

Clay McClure added the comment: On Mon, Jun 1, 2009 at 7:51 PM, pmoody wrote: >> 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 0xfff

[issue3959] Add Google's ipaddr.py to the stdlib

Clay McClure added the comment: On Mon, Jun 1, 2009 at 4:51 PM, pmoody wrote: > 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

[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

[issue3959] Add Google's ipaddr.py to the stdlib

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

[issue3959] Add Google's ipaddr.py to the stdlib

R. David Murray added the comment: In pre-CIDR days, assuming a prefixlen of 24 for a 192.168.x.x address made sense. Nowadays it is better not to make that assumption. So I find ipaddr's default of 32 to be "safer" than using a class based default. The larger point, however, is that there _i

[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 se

[issue3959] Add Google's ipaddr.py to the stdlib

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

[issue3959] Add Google's ipaddr.py to the stdlib

R. David Murray added the comment: > >>> 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. Further, if you were to add a specifically '

[issue3959] Add Google's ipaddr.py to the stdlib

Martin v. Löwis added the comment: > ipaddr makes no distinction between two fundamentally different > concepts -- to my mind, that is a serious flaw. Do you have an application in mind where this lack of distinction would prevent writing the application in a straight-forward way? IOW, could yo

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

[issue3959] Add Google's ipaddr.py to the stdlib

Clay McClure added the comment: Strangely, the leading line of my last response was eaten by the bug tracker. It read: >>> 1 == (1,) -- ___ Python tracker ___ _

[issue3959] Add Google's ipaddr.py to the stdlib

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

[issue3959] Add Google's ipaddr.py to the stdlib

Martin v. Löwis added the comment: > 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 i

[issue3959] Add Google's ipaddr.py to the stdlib

Gregory P. Smith added the comment: On Mon, Jun 1, 2009 at 9:39 AM, Clay McClure wrote: > > Since Python 2.7 and 3.1 have not yet shipped, I hope it's not too late > to continue this discussion. I have no vested interest in either ipaddr or > netaddr, but I am interested in seeing a well-design

[issue3959] Add Google's ipaddr.py to the stdlib

Clay McClure added the comment: Since Python 2.7 and 3.1 have not yet shipped, I hope it's not too late to continue this discussion. I have no vested interest in either ipaddr or netaddr, but I am interested in seeing a well-designed and usable IP address library included in the stdlib. >From

[issue3959] Add Google's ipaddr.py to the stdlib

Gregory P. Smith added the comment: r72210 pep8-ified the test names. -- status: open -> closed ___ Python tracker ___ ___ Python-bugs

[issue3959] Add Google's ipaddr.py to the stdlib

Changes by Guido van Rossum : -- ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/

[issue3959] Add Google's ipaddr.py to the stdlib

Matthew Smart added the comment: Woo! On May 1, 2009 5:48 PM, "Gregory P. Smith" wrote: Gregory P. Smith added the comment: I merged ipaddr into py3k. I can't lookup the revision number (r72186?) at the moment since svn.python.org is having problems. anyways, thanks pmoody & other ipaddr d

[issue3959] Add Google's ipaddr.py to the stdlib

Gregory P. Smith added the comment: I merged ipaddr into py3k. I can't lookup the revision number (r72186?) at the moment since svn.python.org is having problems. anyways, thanks pmoody & other ipaddr developers! Now that the library is -in- (before the 3.1 beta cutoff :), non-API changing

[issue3959] Add Google's ipaddr.py to the stdlib

Antoine Pitrou added the comment: Not at all, it's just nicer. -- ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe

[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: >> >

[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? > > -- > > _

[issue3959] Add Google's ipaddr.py to the stdlib

Antoine Pitrou added the comment: Is there any chance the test methods in test_ipaddr can be PEP8-ified? -- ___ Python tracker ___ ___

[issue3959] Add Google's ipaddr.py to the stdlib

Gregory P. Smith added the comment: Committed to trunk (2.7) in r72173. I'll merge it into py3k later this afternoon. -- priority: normal -> release blocker versions: -Python 2.7 ___ Python tracker __

[issue3959] Add Google's ipaddr.py to the stdlib

Gregory P. Smith added the comment: benjamin.peterson mentioned this in his whats new in 3.1 lightning talk at pycon today and completely by chance, I had made showing a couple examples of ipaddr the topic of my own lightning talk ~30 minutes later. :) Anyways I hope to commit this for 3.1 and

[issue3959] Add Google's ipaddr.py to the stdlib

Gregory P. Smith added the comment: I'll take care of this. My goal is to do it before PyCon. -- assignee: -> gregory.p.smith ___ Python tracker ___ ___

[issue3959] Add Google's ipaddr.py to the stdlib

Antoine Pitrou added the comment: You should post a message on python-dev and put your patch on Rietveld, this will give you more chances to find an interested developer. ___ Python tracker _

[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öw

[issue3959] Add Google's ipaddr.py to the stdlib

Duncan McGreggor added the comment: > If changes to ipaddr could make things easier for netaddr's support > of advanced features, please do propose those changes! Thanks, Guido -- we will :-) We'll be watching closely for that and participating as much as possible.

[issue3959] Add Google's ipaddr.py to the stdlib

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 t

[issue3959] Add Google's ipaddr.py to the stdlib

Guido van Rossum added the comment: If changes to ipaddr could make things easier for netaddr's support of advanced features, please do propose those changes! ___ Python tracker ___ _

[issue3959] Add Google's ipaddr.py to the stdlib

Duncan McGreggor added the comment: Antione, We're (netaddr) going to try to use ipaddr if possible, but there are operations which we are providing to API users that aren't directly supported by ipaddr. We haven't yet determined the level of effort involved in trying to work with ipaddr's bas

[issue3959] Add Google's ipaddr.py to the stdlib

Antoine Pitrou added the comment: Probably it has already been said, but for the record: is ipaddr's current API ok for other libraries (mainly: netaddr) to build upon it and provide compatible extensions or replacements, or would netaddr become an incompatible alternative to the stdlib-provided

[issue3959] Add Google's ipaddr.py to the stdlib

Changes by Jean-Paul Calderone : -- nosy: -exarkun ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.

[issue3959] Add Google's ipaddr.py to the stdlib

Changes by David Moss : -- nosy: -drkjam ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org

[issue3959] Add Google's ipaddr.py to the stdlib

Guido van Rossum added the comment: I don't think a PEP is needed, and I do think ipaddr.py is ready for inclusion. All that you really need is a core developer to champion the inclusion. ___ Python tracker ___

[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 fa

[issue3959] Add Google's ipaddr.py to the stdlib

David Moss added the comment: For reference, here are the (cross-posted) links to the discussion on the (now failed) netaddr/ipaddr merge talks :- http://groups.google.com/group/netaddr/browse_thread/thread/f80b7c69e459 02b7 http://groups.google.com/group/ipaddr-py- dev/browse_thread/thread/2b

[issue3959] Add Google's ipaddr.py to the stdlib

Changes by Gregory P. Smith : -- nosy: +gregory.p.smith ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http://m

[issue3959] Add Google's ipaddr.py to the stdlib

Martin v. Löwis added the comment: > As such, and given the recent work made to ipaddr to make it > stdlib-friendly, my vote would be to include ipaddr in Python while > netaddr can continue growing, providing its user base with diverse > functionality while hopefully taking advantage of ipaddr

[issue3959] Add Google's ipaddr.py to the stdlib

Martin v. Löwis added the comment: > 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? The bug doesn't have enough visibility, so it definitely needs to be discussed in public. > So, where do we go from here?

[issue3959] Add Google's ipaddr.py to the stdlib

Duncan McGreggor added the comment: Well, here are my thoughts on the matter: * ipaddr is relatively small, fast, and focuses on some core functionality * netaddr is designed to be very flexible (sometimes at the cost of a little speed), leaning more towards a network calculation/address manip

[issue3959] Add Google's ipaddr.py to the stdlib

Changes by Ezio Melotti : -- nosy: +ezio.melotti ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.pyt

[issue3959] Add Google's ipaddr.py to the stdlib

Guido van Rossum added the comment: Beats me. I personally haven't had the pleasure to use either so I can't decide. Maybe a vote or a bake-off? ___ Python tracker ___ __

[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

[issue3959] Add Google's ipaddr.py to the stdlib

Changes by Adam Olsen : -- nosy: +Rhamphoryncus ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.pyth

[issue3959] Add Google's ipaddr.py to the stdlib

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

[issue3959] Add Google's ipaddr.py to the stdlib

Changes by Paul Nasrat : -- nosy: +pnasrat ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.or

[issue3959] Add Google's ipaddr.py to the stdlib

Martin v. Löwis added the comment: > 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. I think Guido's original message summarizes that: a module that

[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 men

[issue3959] Add Google's ipaddr.py to the stdlib

David Moss added the comment: > David, in the event of netaddr's complete or partial inclusion, > are you +1 with this and the maintenance of an ip/net library > in Python? Yes, I would be very happy to help with this. > If there's going to be lots of discussion, perhaps it should be > take

[issue3959] Add Google's ipaddr.py to the stdlib

Antoine Pitrou added the comment: If there's going to be lots of discussion, perhaps it should be taken to python-dev? ___ Python tracker ___ _

[issue3959] Add Google's ipaddr.py to the stdlib

Duncan McGreggor added the comment: >> As for shutting down any project that is chosen, does such an action not >> leave older Python versions out in the cold? Shouldn't the project >> remain open to support Python versions < 2.7, with a highly visible note >> that the code is included in 2

[issue3959] Add Google's ipaddr.py to the stdlib

Changes by Antoine Pitrou : -- nosy: +pitrou ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.

[issue3959] Add Google's ipaddr.py to the stdlib

Martin v. Löwis added the comment: > Perhaps the following might be a prudent course: This sounds all good. It is better if the experts in a domain make a recommendation, than if some random committer makes a choice. > As for shutting down any project that is chosen, does such an action not >

[issue3959] Add Google's ipaddr.py to the stdlib

Duncan McGreggor added the comment: I am a contributor to netaddr, having deprecated my own old and crufty IP address library in its favor. JP's comments on the library in this ticket are included in the set of reasons that I initially chose it to replace my own. When I first looked at the i

[issue3959] Add Google's ipaddr.py to the stdlib

Changes by STINNER Victor : -- nosy: -haypo ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.

[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, /pete

[issue3959] Add Google's ipaddr.py to the stdlib

Martin v. Löwis added the comment: > One point I will make is on licensing. netaddr is BSD, so you can do > whatever you want with it and contribute as you see fit. That is not sufficient for inclusion to Python. We also want support from the author (along with a promise to eventually give up t

[issue3959] Add Google's ipaddr.py to the stdlib

Martin v. Löwis added the comment: > I think this might be worth a look before any hard and fast decisions > are made :- > > http://code.google.com/p/netaddr/ Looking at code isn't really helpful for determining whether it can be included into Python. What matters more is whether the authors w

[issue3959] Add Google's ipaddr.py to the stdlib

David Moss added the comment: ipaddr appears to be on a fast track for "batteries included" status without much consultation in the wider Python community. As BDFL it's ultimately Guido's call, but it would be disappointing to see one solution being chosen wholesale without much additional discu

[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

[issue3959] Add Google's ipaddr.py to the stdlib

Jean-Paul Calderone 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'm not sure which API in

[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 addr

[issue3959] Add Google's ipaddr.py to the stdlib

Jean-Paul Calderone added the comment: Performance shouldn't be a major concern here. Utility is more important and the implementation can be optimized later. My initial impression of netaddr is pretty good. One thing it has going for it is documentation. The netaddr google page gives a real

[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,

[issue3959] Add Google's ipaddr.py to the stdlib

David Moss added the comment: I think this might be worth a look before any hard and fast decisions are made :- http://code.google.com/p/netaddr/ -- nosy: +drkjam ___ Python tracker ___

[issue3959] Add Google's ipaddr.py to the stdlib

Martin v. Löwis added the comment: > Now that 2.6 and 3.0 are out of the way, how should we move forward? I think some committer needs to take charge and work with the authors on merging the code. If pmoody wants commit access, that should be set up, and he should add it himself in a commit-aft

[issue3959] Add Google's ipaddr.py to the stdlib

Benjamin Peterson added the comment: Now that 2.6 and 3.0 are out of the way, how should we move forward? Will a PEP be required? ___ Python tracker ___ __

[issue3959] Add Google's ipaddr.py to the stdlib

Changes by Giampaolo Rodola' <[EMAIL PROTECTED]>: -- nosy: +giampaolo.rodola ___ Python tracker <[EMAIL PROTECTED]> ___ ___ Python-bugs-

[issue3959] Add Google's ipaddr.py to the stdlib

STINNER Victor <[EMAIL PROTECTED]> added the comment: Another Python library: http://erlug.linux.it/~da/soft/iplib/ ___ Python tracker <[EMAIL PROTECTED]> ___ __

[issue3959] Add Google's ipaddr.py to the stdlib

STINNER Victor <[EMAIL PROTECTED]> added the comment: Ooops, the website: http://software.inl.fr/trac/wiki/IPy ___ Python tracker <[EMAIL PROTECTED]> ___ ___

[issue3959] Add Google's ipaddr.py to the stdlib

STINNER Victor <[EMAIL PROTECTED]> added the comment: I'm the maintainer of IPy library. Another library for IPv4/IPv6 manipulation. The code is old (was written for Python 2.2?), but released under BSD license. Main issue of this library: it's unable to manipulation "invalid ranges": 10.20.4.

[issue3959] Add Google's ipaddr.py to the stdlib

Guido van Rossum <[EMAIL PROTECTED]> added the comment: On Wed, Sep 24, 2008 at 9:07 PM, Martin v. Löwis <[EMAIL PROTECTED]> wrote: > Martin v. Löwis <[EMAIL PROTECTED]> added the comment: > I see a list of owners in the code (although it's difficult to infer > real names or email addresses from

[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]>

[issue3959] Add Google's ipaddr.py to the stdlib

Martin v. Löwis <[EMAIL PROTECTED]> added the comment: I see a list of owners in the code (although it's difficult to infer real names or email addresses from that list). I think we should not include the code without their explicit approval. The question will then always be: what is the officia

[issue3959] Add Google's ipaddr.py to the stdlib

Changes by pmoody <[EMAIL PROTECTED]>: -- nosy: +pmoody ___ Python tracker <[EMAIL PROTECTED]> ___ ___ Python-bugs-list mailing list Uns

[issue3959] Add Google's ipaddr.py to the stdlib

Changes by Michael Shields <[EMAIL PROTECTED]>: -- nosy: +shields ___ Python tracker <[EMAIL PROTECTED]> ___ ___ Python-bugs-list mailin

[issue3959] Add Google's ipaddr.py to the stdlib

Changes by Matthew Smart <[EMAIL PROTECTED]>: -- nosy: +mattsmart ___ Python tracker <[EMAIL PROTECTED]> ___ ___ Python-bugs-list mailin

[issue3959] Add Google's ipaddr.py to the stdlib

Benjamin Peterson <[EMAIL PROTECTED]> added the comment: Almost time machine. :) ___ Python tracker <[EMAIL PROTECTED]> ___ ___ Python-bugs-list

[issue3959] Add Google's ipaddr.py to the stdlib

Guido van Rossum <[EMAIL PROTECTED]> added the comment: It would help if I added a link to the Google release: http://code.google.com/p/ipaddr-py/ Description: " An IPv4/IPv6 manipulation library in Python. This library is used to create/poke/manipulate IPv4 and IPv6 addresses and prefixes.

[issue3959] Add Google's ipaddr.py to the stdlib

Benjamin Peterson <[EMAIL PROTECTED]> added the comment: Where can we find this? -- nosy: +benjamin.peterson ___ Python tracker <[EMAIL PROTECTED]> ___

[issue3959] Add Google's ipaddr.py to the stdlib

New submission from Guido van Rossum <[EMAIL PROTECTED]>: Google just released ipaddr.py, a module that knows how to manipulate IP addresses (both IPv4 and IPv6). I have nothing to do with this module, but I suggest considering it for inclusion in the standard library. It fills a gap for addres