New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add Google's ipaddr.py to the stdlib #48209
Comments
Google just released ipaddr.py, a module that knows how to manipulate IP I have nothing to do with this module, but I suggest considering it for It fills a gap for address manipulations that will become more important |
Where can we find this? |
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 " |
Almost time machine. :) |
I see a list of owners in the code (although it's difficult to infer The question will then always be: what is the official master copy of I would prefer if the copy in Python (say, 2.7) becomes the master copy, I would object to a mere fork of the code (i.e. where one of the regular |
as one of the owners listed in the code.google.com project (same name), |
On Wed, Sep 24, 2008 at 9:07 PM, Martin v. Löwis <report@bugs.python.org> wrote:
I know they *want* this to happen, no worries on this front.
I'm in favor of this, and I believe the authors at Google are too --
Agreed. |
I'm the maintainer of IPy library. Another library for IPv4/IPv6 |
Ooops, the website: http://software.inl.fr/trac/wiki/IPy |
Another Python library: http://erlug.linux.it/~da/soft/iplib/ |
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 If he doesn't want to do the integration, some committer needs to In any case, we would need a copyright form signed, unless Guido can
I doubt that; a quick announcement to python-dev might be sufficient |
I think this might be worth a look before any hard and fast decisions |
I'm biased ;) but I don't see what netaddr provides over ipaddr. it pmoody@mini - 04:52 PM - ~/Downloads/ipaddr-1.0.1 pmoody@mini - 04:52 PM - ~/Downloads/netaddr-0.5.2 dealing with netmasks, the difference is even greater. pmoody@mini - 04:49 PM - ~/Downloads/netaddr-0.5.2
(and it doesn't seem to deal with hostsmasked addresses). it also seems to be layed out in an unintuitive way, treating address |
Performance shouldn't be a major concern here. Utility is more My initial impression of netaddr is pretty good. One thing it has going There are a lot of minor things about ipaddr-py which are off-putting. Regarding the treatment of addresses versus address ranges, I prefer This is far from a complete review of either library, obviously. I've |
hm, all addresses have a subnet, even if its an implied /32, so and my expectation was always that method names, etc. would have to be also, ipaddr does make extensive use of pydoc, but you're right, the happy (PST) new year. Cheers, |
I'm not sure which API in netaddr you're referring to. If you want to |
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=<class 'netaddr.address.Addr'>) when looking through the code.google.com wiki, I couldn't find any
and still having two separate classes represent the same thing seems odd to me. |
ipaddr appears to be on a fast track for "batteries included" status There is no point in wrangling over the individual features of one As for netaddr it is intended to cover more ground that all the other http://code.google.com/p/netaddr/wiki/YetAnotherPythonIPModule This may preclude its suitability for the standard library in any event In answer to various specific issues raised about netaddr. The need for separate IP and CIDR classes is set out in the FAQ page :- http://code.google.com/p/netaddr/wiki/NetAddrFAQ FYI, AddrRange is a (not yet abstract) base class with a start and end With netaddr, I wanted to avoid the 'super object' syndrome that seems In any event confusion will hopefully be dealt with as the docs improve. As for performance, netaddr's current speed for certain operations areas One point I will make is on licensing. netaddr is BSD, so you can do At the present time, contributing to ipaddr for anyone outside Google Regardless of whatever decision is taken, netaddr will always be |
Looking at code isn't really helpful for determining whether it can |
That is not sufficient for inclusion to Python. We also want support |
As Guido had mentioned in a previous message, this is along the lines Cheers, |
I am a contributor to netaddr, having deprecated my own old and crufty When I first looked at the ipaddr code a month ago, the features I was Perhaps the following might be a prudent course:
As for shutting down any project that is chosen, does such an action not |
This sounds all good. It is better if the experts in a domain
Of course - hence I said "eventually". The project could continue to |
Fantastic! Thanks for the clarification. David, in the event of netaddr's complete or partial inclusion, are you Guido, what is your preference regarding feature set/size for an ip/net |
If there's going to be lots of discussion, perhaps it should be taken to |
Yes, I would be very happy to help with this.
Good idea. Peter M. and the ipaddr contributors, are you all happy to proceed in |
I'm fine with this. But as Duncan mentioned, some guidance from the Cheers, |
I think Guido's original message summarizes that: a module that |
I've been on vacation and unable to follow this, and won't have time to Since I haven't used either module and am not particularly interested in Duncan McGreggor asked some questions on python-dev; here are my responses:
I don't want to exclude EUI/MAC support, but it seems quit a separate
I don't care either way.
How about a merger? |
r72210 PEP-8-ified the test names. |
Since Python 2.7 and 3.1 have not yet shipped, I hope it's not too late From reading the comments in this issue, it seems most of the discussion When looking for an IP address library for use in a network scanning and After reading the technical discussion on the ipaddr and netaddr lists,
This is not only incorrect, but it demonstrates a deep misunderstanding IPv4 *networks* have masks, of course, hence the name "netmask". These
Since networks are commonly represented in at least three forms, the API CIDR/prefix notation: "192.168.1.0/24"
This statement demonstrates an extremely narrow view of the problem At least three concepts deserve first-class treatment in any meaningful
To conflate these is a mistake. My hope is that now that a library has been selected, it can be improved To this end, now that ipaddr is moving to Python stdlib, will Google's Cheers, Clay |
On Mon, Jun 1, 2009 at 9:39 AM, Clay McClure <report@bugs.python.org> wrote:
Python 3.1 is as good as shipped. It is in the release candidate Improvements will have to wait for 2.7 and 3.2. In the mean time I
I think range notation parsing could be implemented pretty easily.
Too late for 3.1. But I see no reason for the existing API to be Subclass the existing classes and inherit from a mixin that keeps
You can sign a Python Software Foundation contributor agreement No Google CLA will ever be required to make changes to anything in the |
That is fairly unlikely. The 3.1 release candidate has been produced, |
On Mon, Jun 1, 2009 at 1:09 PM, Martin v. Löwis <report@bugs.python.org> wrote:
False
>>> ipaddr.IPv4('192.168.1.1') == ipaddr.IPv4('192.168.1.1/32')
True ipaddr makes no distinction between two fundamentally different ipaddr has many other quirks that, while not technically flaws, are To those arguing for ipaddr's inclusion in the stdlib, how many of you Clay |
Strangely, the leading line of my last response was eaten by the bug
|
On Mon, Jun 1, 2009 at 1:33 PM, Clay McClure <report@bugs.python.org> wrote:
>
> Clay McClure <clay@daemons.net> added the comment:
>
> On Mon, Jun 1, 2009 at 1:09 PM, Martin v. Löwis <report@bugs.python.org> 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
I haven't seen any new issues on code.google.com (and I haven't heard
have used it to develop software and will continue to use it to Cheers,
|
Do you have an application in mind where this lack of distinction |
As a network engineer I don't see any inherent problem with that equality. Further, if you were to add a specifically 'address-without-netmask' |
On Mon, Jun 1, 2009 at 5:02 PM, R. David Murray <report@bugs.python.org> wrote:
For an example of why 192.168.1.1 != 192.168.1.1/32, look no further # ifconfig en0 192.168.1.1/32 # ifconfig en0 192.168.1.1 Can you provide an example of when 192.168.1.1 does in fact equal
I don't follow. Assuming hypothetical Address and Network classes, as False That seems to me the correct behavior, since an address is in fact not Clay |
On Mon, Jun 1, 2009 at 4:41 PM, Clay McClure <report@bugs.python.org> wrote:
>
> Clay McClure <clay@daemons.net> added the comment:
>
> On Mon, Jun 1, 2009 at 5:02 PM, R. David Murray <report@bugs.python.org> 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<UP,BROADCAST,SMART,RUNNING,SIMPLEX,MULTICAST> mtu 1500
> inet 192.168.1.1 netmask 0xffffffff broadcast 192.168.1.1
> ...
>
> # ifconfig en0 192.168.1.1
> # ifconfig en0
> en0: flags=8863<UP,BROADCAST,SMART,RUNNING,SIMPLEX,MULTICAST> mtu 1500
> inet 192.168.1.1 netmask 0xffffff00 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
|
In pre-CIDR days, assuming a prefixlen of 24 for a 192.168.x.x address The larger point, however, is that there _is_ a mask associated with the As for the == thing, I agreed with you that address compared to network,
HypotheticalNetworkClass('192.168.1.1/32') should yield True, because, as I said above, in a CIDR world using a As for an example of when the equivalence is useful, it is useful every |
On Mon, Jun 1, 2009 at 4:54 PM, Martin v. Löwis <report@bugs.python.org> wrote:
Consider applications that use ipaddr.IPv4 objects to configure ifconfig: 255.255.255.0/32: bad value That's because ipaddr wrongly appends a prefix length to all Consider applications that need to validate addresses (or networks, 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") Given its myriad quirks, it is really rather surprising that ipaddr is Clay |
On Mon, Jun 1, 2009 at 5:47 PM, Clay McClure <report@bugs.python.org> wrote:
I'm not sure what you're trying to do here, can you elaborate?
i'm not sure what's onerous about this code. you're missing a
it's actually already been included, but that's beside the point. I'm
|
On Mon, Jun 1, 2009 at 4:51 PM, pmoody <report@bugs.python.org> wrote:
Fortunately, it's not up for debate: RFC-791 defines an IP address as
I will go ahead and open issues on code.google.com.
I'd like to hear from application developers outside of Google. The Clay |
On Mon, Jun 1, 2009 at 7:51 PM, pmoody <report@bugs.python.org> wrote:
The example demonstrates one case where the strings '192.168.1.1' and You're wrong on both fronts, since in fact all IP implementations Clay |
On Mon, Jun 1, 2009 at 8:05 PM, R. David Murray <report@bugs.python.org> wrote:
Sorry, but why should you determine what is better for my application?
Again, you're wrong. The mask that you see in ifconfig is associated That's why we call it a "netmask".
Host routes are routes like all others -- they have a destination
By "ip/hostmask" pair, you actually mean "ip/netmask" pair, and yes,
I'm not advocating classful routing, I'm merely stating (emphatically Clay |
On Mon, Jun 1, 2009 at 9:03 PM, pmoody <report@bugs.python.org> wrote:
Let's say I have a UI that prompts users for two pieces of Assuming the user has supplied this information: Interface address = '192.168.1.1' the following would get passed to ifconfig: ifconfig en0 192.168.1.1/32 netmask 255.255.255.0/32 Clearly this is not what we expect, nor even legal. The principle of We could work around this, of course, but why should we have to work
Your definition of onerous apparently differs from mine :) In my own applications, when I'm expecting a network, I use an
Rest assured, I've opened one issue and will open one or two more I'm sorry that you think "yelling" is unproductive. I happen to think Cheers, Clay |
On Mon, Jun 1, 2009 at 7:38 PM, Clay McClure <report@bugs.python.org> wrote:
>
> Clay McClure <clay@daemons.net> added the comment:
>
> On Mon, Jun 1, 2009 at 9:03 PM, pmoody <report@bugs.python.org> 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. my_ip = ipaddr.IP('%s/%s' % (ipaddress, netmask)) and then check for any exceptions. I'd then ifconfig en0 str(my_ip)
so ipaddr doing this validation for the user actually could make some ipaddr.IP(ip, network=False)
or
ipaddr.IP(net, network=True) anyway (more below)...
cool, I see that you did that. as an aside, this probably isn't the
I think debate is healthy, too. but I measure my success at a debate Cheers,
|
If that is a frequent need, it would be reasonable to add an API address = ipaddr.IP(input, allow_mask=False) which would raise an exception if a mask was specified (as an
With the current API, you don't need to write it in such a quirky if address.numhosts != 1:
raise TypeError("Expecting IP address, not network") would do as well.
Well, you deliberately make it appear more quirky than it actually is. |
If you want to see them fixed in Python, please report them to this |
On Tue, Jun 2, 2009 at 1:21 AM, Martin v. Löwis <report@bugs.python.org> wrote:
I'd like to see the issues fixed upstream, and the library removed Thanks, Clay |
Support for this can be added (its too late for Python 3.1). User if '/' in input:
raise TypeError("Expecting IP address")
address = ipaddr.IP(input) Or for a more pedantic test prior to calling ipaddr.IP. if re.match('^[0-9a-fA-F:.]+$', input):
raise TypeError("Invalid characters in IP address") Please file a feature request on bugs.python.org for this one if you |
That's not true - I'm outside of Google, and have not indicated such |
On Tue, Jun 2, 2009 at 2:18 AM, Martin v. Löwis <report@bugs.python.org> wrote:
You've indicated no preference either way, and have said: "I personally have no plans for using this library, or any other IP I should think you would seek the opinion of those developers who Clay |
That's what this has been doing for the last 8 1/2 months.
Is there some sort of conspiracy theory-ish reason that a google Cheers, |
On Tue, Jun 2, 2009 at 2:52 AM, pmoody <report@bugs.python.org> wrote:
From reading your comments and the code, it is clear that concepts The fact that developers outside Google seem to prefer a different API Clay |
This issue is closed. Please take discussion up on a mailing list. |
Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.
Show more details
GitHub fields:
bugs.python.org fields:
The text was updated successfully, but these errors were encountered: