Re: [Python-Dev] Issues with Py3.1's new ipaddr

[DrKJam]

I've just subscribed to python-dev again after being pointed towards this
thread (thanks Raymond).

I'd be the first to accept failings and oddities in the interface of my own
library. Since its release netaddr has taken its own interesting set of
twists and turns. However, all along I have tried to be responsive and
accommodating with regard to my users needs and requests for new features
and bug fixes. There has been a lot of useful feedback which I have
faithfully incorporated into netaddr's codebase.

It would be a shame to see all the hard work go to waste on Y.A.P.I.M. :-

http://code.google.com/p/netaddr/wiki/YetAnotherPythonIPModule

There is a veritable graveyard of stuff out there! Some good, some not so
good.

The netaddr/ipaddr-py merge went awry and our projects decided to remain
separate. I don't see any benefit in raking over those old coals; it's all
water under the bridge.

That being said, based on the passion in this thread, the decision to
include ipaddr-py into the stdlib seems to be proving too hasty and
contentious for some. It really might be worth taking a step back and taking
heed of those concerns.

Having had quite a while to think about this over the last few months, this
is what I would ideally like to see.

A sensible discussion from a *broad* base of network admins, sysadmins and
developers using Python on the formulation of a reasonable functional
specification and design for a brand new library (without the associated
baggage and vested interests of any particular implementation). This would
be an opportunity for us to nail our respective problems and differences
while simultaneously bringing together most of the Python community behind
code that WE WILL ACTUALLY USE. If this is going in the stdlib surely that
is doubly important?

If possible, I would particularly like to see input from Victor Stinner, the
current IPy maintainer. There as some wrinkles and failings in IPy's
interface and implementation but its actually not as bad as I first thought
having actually spent some time implementing its interface (mostly
successfully) as a facade on top of netaddr. See the netaddr repo if you are
interested and *no* it is not supported code ;-)

Would this actually be feasible or am I just a hopeless optimist? Should we
formulate a PEP even though calls for that have so far been rejected?
Possibly PEPs don't apply to libraries?

Whoever overseas this would need to be someone with a fairly neutral
perspective on all of this.

Dave M.
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 3144: IP Address Manipulation Library for the Python Standard Library

[DrKJam]

Good evening fellow Pythonistas,

Considering a PEP is now available I'd like to join this discussion and
raise several points with regard to both the PEP and the ipaddr reference
implementation put forward with it.

1) Firstly, an offering of code.

I'd like to bring to your attention an example implementation of an IP
address library and interface for general discussion to compare and contrast
with ipaddr 2.0.x :-

http://netaddr.googlecode.com/svn/branches/exp_0.7.x_ip_only

It is based on netaddr 0.7.2 which I threw together earlier today.

In essence, I've stripped out all of what could be considered non-essential
code for a purely IP related library. This branch should be suitable for
*theoretical* consideration of inclusion into some future version of the
Python standard library (with a little work).

It is a pure subset of netaddr release 0.7.2, *minus* the following :-

- all IEEE layer-2 code
- some fairly non-essential IANA IP data files and lookup code
- IP globbing code (fairly niche)

Aside: Just a small mention here that I listened carefully to Clay McClure's
and others criticisms of the previous incarnation of ipaddr. The 0.7.x
series of netaddr breaks backward compatibility with previous netaddr
releases and is an "answer" of sorts to that discussion and issue raised
within the Python community. I hope you like what I've done with it.

For the purposes of this discussion consider this branch the "Firefox to
netaddr's Mozilla" or maybe just plain old "netaddr-ip-lite" ;-)

2) I refute bold claim in the PEP that :-

"Finding a good library for performing those tasks can be somewhat more
difficult."

On the contrary, I wager that netaddr is now a perfectly decent alternative
implementation to ipaddr, containing quite a few more features with little
of the slowness for most common operations, 2/3x faster in a lot of cases,
not that we're counting. What a difference a year makes! I also rate IPy
quite highly even if it is getting a little "long in the tooth". For a lot
of users, IPy could also be considered a nice, stable API!

By the same token I'm happy to note some convergence between the ipaddr and
netaddr's various interfaces, particularly in light of discussions and
arguments put forward by Clay McClure and others. A satisfactory compromise
between the two however still seems a way off.

3) I also disagree with the PEP's claim that :-

"attempts to combine [IPv4 and IPv6] into one object would be like
trying to force a round peg into a square hole (or vice versa)".

netaddr (and for that matter IPy) cope with this perceived problem
admirably.

netaddr employs a simple variant of the GoF Strategy design pattern (with
added Python sensibility). In the rare cases where ambiguity exists between
IPv4 and IPv6 addresses a version parameter may be passed to the constructor
of the IPAddress class to differentiate between them. Providing an IP
address version to the constructor also provides a small performance
improvement.

IPv4 and IPv6 addresses can be used interchangably throughout netaddr
without causing issue during operations such as sorting, merging (known in
the PEP as "address collapsing") or address exclusion.

Don't try and do this with the current reference implementation of ipaddr :-

>>> collapse_address_list([IPv4Address('1.1.1.1'),
IPv6Address('::1.1.1.1')])
[IPv4Network('1.1.1.1/32')]

OUCH! Even if this isn't allowed (according to the documentation), it should
raise an Exception rather than silently passing through.

I actually raised this back in May on the ipaddr bug tracker but it hasn't
received any attention so far :-

http://code.google.com/p/ipaddr-py/issues/detail?id=18

Compare this with netaddr's behaviour :-

>>> cidr_merge([IPAddress('1.1.1.1'), IPAddress('::1.1.1.1')])
[IPNetwork('1.1.1.1/32'), IPNetwork('::1.1.1.1/128')]

That's more like it.

4) It may just be me but the design of this latest incarnation of ipaddr
seems somewhat complicated for so few lines of code. Compared with ipaddr,
netaddr doesn't use or require multiple inheritance nor a seemingly
convoluted inheritance heirarchy. There isn't a need for an IP() type
'multiplexer' function either (although I might be missing an important use
case here). But, then again, this may just be my personal preference talking
here. I prefer composition over inheritance in most cases.

In netaddr, if a user wants to represent an IP address (without netmask),
they should use the IPAddress class, if they want to represent and IP
address with some form of mask, they should use the IPNetwork class.

5) The ipaddr library is also missing options for expanding various
(exceedingly common) IP abbreviations.

>>> from netaddr import IPNetwork

>>> IPNetwork('10/8', True)
IPNetwork('10.0.0.0/8')

netaddr also handles classful IP address logic, still pervasive throughout
modern IP stacks :-

>>> IPNetwork('192.168.0.1', True)
IPNetwork('192.168.0.1/24')

Note that these options are disabled by default, to keep u

Re: [Python-Dev] PEP 3144: IP Address Manipulation Library for the Python Standard Library

[DrKJam]

I've started a very basic (work in progress) entry on the netaddr wiki to
track various aspects of this discussion that might not be in a format
suitable for publishing to the list or are too lengthy. It will also allow
my ascii art diagrams to render correctly ;-)

http://code.google.com/p/netaddr/wiki/PEP3144

I will be updating it as free time become available to me over the coming
days. Feel free to make comments on the wiki page itself if you want me to
make any changes. Duncan McGreggor should be able to make changes if I am
not available for whatever reason :-

If anyone has suggestions for a better place to put this, please shout (but
not too loudly please Peter M. ;-)

Thanks,

Dave M.

PS - Can't wait for Google Wave which would make this kind of thing so much
easier ;-)
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 3144: IP Address Manipulation Library for the Python Standard Library

[DrKJam]

2009/8/25 Peter Moody 

> On Mon, Aug 24, 2009 at 3:24 PM, DrKJam wrote:
>

[SNIP]


> As it was left in early June, a pep and design modifications were
> requested before ipaddr would be considered for inclusion, but if this
> is going to start *another* drawn out ipaddr/netaddr thread, perhaps
> the mailman admin(s) could setup a new SIG list for this.  I
> personally hope that's not required; yours has been the only
> dissenting email and I believe I respond to all of your major points
> here.


The PEP process is the perfect forum for spending some time scrutinizing and
discussing this topic in more detail. I will be raising further points in
future when I've had time to fully evaluate both the PEP and the reference
implementation of ipaddr.

At this stage, it is premature to assume the reference implementation
provided along with the PEP is necessarily complete, only requiring a few
bug fixes to get through the approval process.


> > 1) Firstly, an offering of code.
> >
> > I'd like to bring to your attention an example implementation of an IP
> > address library and interface for general discussion to compare and
> contrast
> > with ipaddr 2.0.x :-
> >
> > http://netaddr.googlecode.com/svn/branches/exp_0.7.x_ip_only
> >
> > It is based on netaddr 0.7.2 which I threw together earlier today.
> >
> > In essence, I've stripped out all of what could be considered
> non-essential
> > code for a purely IP related library. This branch should be suitable for
> > *theoretical* consideration of inclusion into some future version of the
> > Python standard library (with a little work).
> >
> > It is a pure subset of netaddr release 0.7.2, *minus* the following :-
> >
> > - all IEEE layer-2 code
> > - some fairly non-essential IANA IP data files and lookup code
> > - IP globbing code (fairly niche)
> >
> > Aside: Just a small mention here that I listened carefully to Clay
> McClure's
> > and others criticisms of the previous incarnation of ipaddr. The 0.7.x
> > series of netaddr breaks backward compatibility with previous netaddr
> > releases and is an "answer" of sorts to that discussion and issue raised
> > within the Python community. I hope you like what I've done with it.
> >
> > For the purposes of this discussion consider this branch the "Firefox to
> > netaddr's Mozilla" or maybe just plain old "netaddr-ip-lite" ;-)
> >
> > 2) I refute bold claim in the PEP that :-
> >
> > "Finding a good library for performing those tasks can be somewhat
> more
> > difficult."
> >
> > On the contrary, I wager that netaddr is now a perfectly decent
> alternative
> > implementation to ipaddr, containing quite a few more features with
> little
> > of the slowness for most common operations,
>
> I think you mean refuse,


No, I meant refute.


> b/c this certainly wasn't the case when I
> started writing ipaddr. IPy existed, but it was far too heavyweight
> and restrictive for what I needed (no disrespect to the author(s)
> intended). I believe I've an email or two from you wherein you
> indicate the same.
>

The comment made on IPy, to which I believe you are referring, was in
response to you incorrectly comparing netaddr and IPy's implementation
(assuming conditional logic was used within each method to support IP
versioning). As already stated netaddr gets around this with a strategy
design pattern approach (apologies to readers for using the "Gang of Four"
acronym with regard to this).

IPy is heavyweight? How so? It is a mere 1200 lines including comments and
deals with IPv4 and IPv6 addressing, much like ipaddr (albeit with fewer
features). There are certainly issues you could raise against it (otherwise
we wouldn't be here), but being heavyweight is not one of them.

I would actively encourage authors of said library (Victor Stinner is listed
as the current maintainer) to get involved in the discussion of this PEP. It
is their legacy that this work is picking up from.

Incidentally, I've noticed a few bug fix releases come through for IPy on
PyPI in the last month so that project certainly seems alive and well.

I think the PEP currently doesn't provide appropriate weight to the efforts
of others in this area.

FYI, here is a wiki entry I've been maintaining for a while now to this end
:-

http://code.google.com/p/netaddr/wiki/YetAnotherPythonIPModule


>
> > 2/3x faster in a lot of cases,
> > not that we're counting. What a difference a year makes!
> > I also rate IPy quite highly even if it is getting a little "long in the
> tooth".
> > For a

Re: [Python-Dev] PEP 3144: IP Address Manipulation Library for the Python Standard Library

[DrKJam]

I've posted several of issues to the ipaddr bug tracker for consideration.
They shouldn't be major discussion topics so I'll leave them off the list.

The following are a few feature requests that might possibly require further
discussion here. If they are no-brainers that don't require any further
mulling over, can we have a few votes -1/+1 to get a feel for the importance
and I'llI convert them into tickets.

1) Additional is_ boolean properties.

IPv6Address.is_ipv4_compat
IPv6Network.is_ipv4_compat

Returns True if this address/network is IPv4-compatible IPv6 e.g.
::192.0.2.0 or ::192.0.2.0/124, False otherwise.

IPv6Address.is_ipv4_mapped
IPv6Network.is_ipv4_mapped

Returns True if this address/network is IPv4-compatible IPv6 e.g.
:::192.0.2.0 or :::192.0.2.0/124, False otherwise.

IPvXAddress.is_reserved
IPvXNetwork.is_reserved

Possible list of IPv4 networks and ranges to be used for this purpose :-

#IANA Reserved but subject to allocation
39.0.0.0/8
128.0.0.0/16
191.255.0.0/16
192.0.0.0/24
223.255.255.0/24

#   Reserved for Future Use
240.0.0.0/4

#   Reserved multicast
234.0.0.0 - 238.255.255.255
225.0.0.0 - 231.255.255.255

Possible list of IPv6 networks to be used for this purpose :-

FF00::/12
::/8
0100::/8
0200::/7
0400::/6
0800::/5
1000::/4
4000::/3
6000::/3
8000::/3
A000::/3
C000::/3
E000::/4
F000::/5
F800::/6
FE00::/9

IPvXAddress.is_unicast
IPvXNetwork.is_unicast

True if addresses or networks are within unicast ranges.

2) An IPvXRange class (representing an arbitrary start and end IP address).
This is in addition to the existing summarize_address_range() function.

There are use cases were an actual object representing an arbitrary range
rather than a basic tuple containing two IPvXAddress objects or a list of
IPvXNetwork objects is just simple to handle, more appropriate and less
hassle overall. Willing to expand on the interface for this.

3) Support for IPv4-mapped/compatible IPv6 conversion functions.

It would be handy to have methods to convert backwards and forwards between
actual IPv4 addresses and networks to their IPv6 mapped or compatible
counterparts.

Basic examples :-

IPv4 -> IPv6

>>> IPv6Address(':::192.0.2.0').ipv4()
IPv4Address('192.0.2.0')

>>> IPv6Address('::192.0.2.0').ipv4()
IPv4Address('192.0.2.0')

IPv4 -> IPv6

>>> IPv4Address('192.0.2.0').ipv6()
IPv6Address(:::192.0.2.0') Prefer IPv4-compatible as the default (RFC
4291)

>>> IPv4Address('192.0.2.0').ipv6(ipv4_mapped=True)
IPv6Address('::192.0.2.0')

By the same token we should provide the same functionality for IP network
classes (with the necessary CIDR prefix conversions) :-

>>> IPv6Network(':::192.0.2.0/120').ipv4()
IPv4Network('192.0.2.0/24')

>>> IPv4Network('192.0.2.0/24').ipv6()
IPv6Network(':::192.0.2.0/120')

>>> IPv4Network('192.0.2.0/24').ipv6(ipv4_mapped=True)
IPv6Network('::192.0.2.0/120')

If address ranges overflow boundaries the necessary exceptions can be
thrown.

4) IP set based classes.

This is a big topic, so I'll save it for a subsequent post. What are the
general feelings about having something like this in ipaddr? It might be
deemed a little heavyweight but it is a really sweet option for the power
user. Combined with the new speed of collapse_address_list() this could be
handy and fast.

That's all for now,

Dave M.

2009/8/27 Peter Moody 

> On Thu, Aug 27, 2009 at 10:37 AM, Peter Moody wrote:
> > On Thu, Aug 27, 2009 at 10:24 AM, David Moss wrote:
> >> Peter,
> >>
> >> I would like to apologise if I have caused you any offense.
> >
> > Thanks. Accepted.
> >
> >> Please can we
> >> put the animosity behind us and stick to pulling together the best IP
> >> library possible as part of this PEP?
> >
> > pep-3144 should hopefully soon be updated on python.org/dev/peps with
> > this past week's suggestions (including a discussion on the ipaddr
> > class design).  The updated ipaddr reference code should also still be
> > available for 'svn co' at
> > https://ipaddr-py.googlecode.com/svn/branches/2.0.x
>
> er, make that http://ipaddr-py.googlecode.com/svn/branches/2.0.x
>
> https seems to ask for a password.
>
> > Cheers,
> > /peter
> >
> >> Regards,
> >>
> >> Dave M.
> >>
> >
>
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 3144 review.

[DrKJam]

Please can we have the following RFCs added to the references section that
cover many of the aspects covered by this PEP?

RFC 791 - Internet Protocol
RFC 1918 - Address Allocation for Private Internets
RFC 3330 - Special-Use IPv4 Addresses
RFC 4291 - IPv6 Addressing Architecture
RFC 4632 - Classless Inter-domain Routing (CIDR): The Internet Address

Dave M.
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

[Python-Dev] Fwd: PEP 3144 review.

[DrKJam]

>
> Antoine Pitrou wrote:
> > Peter Moody  hda3.com> writes:
> >> the address with all of the hosts bits masked to zero is most commonly
> >> referred to as the network address. same as the address with all of
> >> the host bits set to one is called the broadcast address. calling it
> >> something like base_address or min_address will cause quite a bit more
> >> confusion.
> >
> > Quite a bit less IMO. I'm not a network specialist, but the "network
> address"
>
> Nah, network address is perfectly explicit - it's what you get when you
> bitwise and any host within that network with the netmask.
>
> Where it becomes confusing is that we have a property called "network"
> that returns an IPAddress object rather than an IPNetwork object.
>
> People that are network specialists would grasp that fairly easily, but
> we try to design standard library APIs so that they're novice friendly
> as well. And the above situation isn't novice friendly.
>
> To be honest, given the indexing behaviour, I'm -1 on the idea of giving
> the network address or broadcast address attribute names *at all*.
> Consider:
>
>  network_address = my_net[0]
>  broadcast_address = my_net[-1]
>
> The only way the network address could match the number of characters in
> the indexing method is if you just called it the network id (i.e.
> my_net.id). For the broadcast address, there is no name that even comes
> close to matching the indexing approach for brevity.
>
> And since IPNetwork is a container for IPAddress instances, the indexing
> approach means there is zero ambiguity regarding the return type.
>
> -1 from me. I'm happy to see indexing made available alongside specific
properties/methods that expose the network (without mask) and broadcast
addresses for a given network object, but not to remove them from the
interface entirely in favour of indexing alone.

While it seems like a good idea, in practice it just won't work or will at
least be sub-optimal and violates the rule of least surprise (for IP
libraries anyway). I struggled along with this approach in several early
versions of netaddr but had to cave in to pressure from users after repeated
questions about where to find the broadcast and network (without mask)
addresses!

Granted, there are decisions to be made about exactly what the
properties/methods should be named to avoid ambiguity, but they are
important enough to be given access to in their own right. Details in
docstrings help too ;-) 'network' and 'broadcast' are very much the
convention used pretty much everywhere (including libraries found in other
languages such as Ruby and Perl).

IPv6 doesn't support the notion of a broadcast address as part of a CIDR
network block at all. AFAIK, it is a perfect legitimate for the last address
in an IPv6 block to be used to configure a network interface. The IPv6
network object interface should possibly leave out the broadcast
property/method altogether although there are reasons to keep it in for the
sake of completeness and API consistency. The pros and cons of this need to
be considered.

BTW, has anyone considered use of the term *CIDR to refer to an address +
mask object? It would certainly be less controversial than *Network which
already has too many overlapping meanings elsewhere in the interface?
Obviously we'd still have the issue of what to do with the host bits to the
right of the supplied mask (keep or discard). This is not a clear cut choice
of one or the other as it is entirely based on context. For configuring
routes, you would likely always want to discard these bits (or at least
Cisco does when adding routes). For configuring a network interface you
would most certainly want to keep them!


> Cheers,
> Nick.
>
> --
> Nick Coghlan   |   ncogh...@gmail.com   |   Brisbane, Australia
> ---
> ___
> Python-Dev mailing list
> Python-Dev@python.org
> http://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> http://mail.python.org/mailman/options/python-dev/drkjam%40gmail.com
>
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 3144 review.

[DrKJam]

2009/9/26 "Martin v. Löwis" 

> > I don't think the RFCs forbid the zero address being used
>
>
> RFC 1122 does: "IP addresses are not permitted to have the value 0 or -1
> for any of the , , or  number> fields (except in the special cases listed above)."
>
> The current version of the PEP and reference implementation do not mention
or deal with IPv4 classful addressing (A, B, C, D and E). It would be good
to know if any of this (admittedly older yet no less important)
functionality is going to be supported. If the library is to concentrate
solely on classless addressing (i.e. CIDR) please can this be stated in
future revisions of the PEP.


> RFC 3021 modifies this requirement, allowing the zero address to
> be used for an 31-bit prefix.
>
> Regards,
> Martin
> ___
> Python-Dev mailing list
> Python-Dev@python.org
> http://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> http://mail.python.org/mailman/options/python-dev/drkjam%40gmail.com
>
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 3144 review.

[DrKJam]

2009/9/26 Daniel Stutzbach 

> On Sat, Sep 26, 2009 at 2:07 PM, DrKJam  wrote:
>
>> The current version of the PEP and reference implementation do not mention
>> or deal with IPv4 classful addressing (A, B, C, D and E). It would be good
>> to know if any of this (admittedly older yet no less important)
>> functionality is going to be supported. If the library is to concentrate
>> solely on classless addressing (i.e. CIDR) please can this be stated in
>> future revisions of the PEP.
>>
>
> Classful addressing was deprecated more than 15 years ago!
>
> Quoting RFC 4632: "With the full deployment of CIDR on the Internet, such
> scenarios are no longer operationally relevant."


Interesting as evidence of classful IPv4 behaviour seems fairly pervasive in
current IP stacks and software that supports IPv4 addressing (e.g.
PostgreSQL inet and cidr data types).

Here's an excerpt from the 'ifconfig' man page (taken from an Ubuntu 9.04
install) :-
^^^
...
netmask addr

Set the IP network mask for this interface. This value defaults to the usual
class A, B or C network mask (as derived from the interface IP address). but
it can be set to any value.
...
^^^

The point being that you can't always assume /32 implicitly for all use
cases.

Here is how IP addresses without an explicit prefix or netmask are currently
handled :-

>>> import ipaddr
>>> ipaddr.IPv4Network('10.0.0.1')
IPv4Network('10.0.0.1/32')

It may not be something we want to support (you could always force the end
user to specify a prefix or netmask explicitly). This is fair enough, but
let's indicate that it's a considered choice. Somewhere in the PEP text is
might be a good place for treatment of this topic.

> --
> Daniel Stutzbach, Ph.D.
> President, Stutzbach Enterprises, LLC <http://stutzbachenterprises.com>
> "The plumage don't enter into it. It's stone dead."
>
>
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 3144 review, and the inclusion process

[DrKJam]

2009/9/28 Peter Moody 

> [cc += david moss]
>
> On Mon, Sep 28, 2009 at 9:39 AM, Guido van Rossum 
> wrote:
> > On Sun, Sep 27, 2009 at 5:32 PM, Antoine Pitrou 
> wrote:
> >> Peter Moody  hda3.com> writes:
> >>>
> >>> I've never said otherwise. In fact, from an email last night, "If what
> >>> the community requires is the library you've described, then ipaddr is
> >>> not that library." The changes *you* require make ipaddr significantly
> >>> less useful to me. I'm not prepared to make those changes in an
> >>> attempt seek acceptance to the stdlib, especially if the stdlib is in
> >>> such flux that I'll get to do this again in 18 months.
> >>
> >> Well, then I'm not sure why we have a PEP at all.
> >> If you don't want any significant changes and if you consider it to be
> *your*
> >> library, ipaddr can remain a third-party package that interested people
> can
> >> easily install (no pun ;-)) since AFAIK it's pure Python. It will also
> make
> >> maintenance easier for you, while freeing us (core developers) from
> having to
> >> bother about it in our daily development tasks.
> >>
> >> At least that's what I would advocate right now - not sure about what
> others
> >> think.
> >
> > I think Peter is pretty frustrated by the many attacks on "his"
> > library. There are probably a number of different things going on
> > simultaneous: Peter has been driven into the defense by attacks both
> > reasonable and unreasonable, there have been misunderstandings all
> > around, teasing out use cases (by both parties) has been a problem.
> >
> > Things might have gone differently if the PEP had started out with
> > multiple authors. Maybe it's not too late to add one or more other
> > interested parties to the PEP with the purpose of making the PEP more
> > clearly the result of a consensus-gathering process.  Any volunteers?
>
> David called me a little over a week ago and expressed an interest in
> doing exactly this cross continent/ocean coordination has been a
> little difficult thus far and I'm not certain what his feelings on
> this are now.
>
>
Sure, I'm happy to volunteer and help out. Let's have a good hard look at
all this and see what we can come up with.


> > At the same time I don't think a complete reset of the proposed API is
> > necessary.  I am rather more thinking of judicious API tweaks in order
> > to cover some new use cases, without requiring a complete rewrite or
> > destroying the usability of the proposal for Peter's original use
> > cases. (In general I am pretty happy with the ipaddr code and API; it
> > looks like what I would have done, but then I am blissfully unaware of
> > some of the issues brought up in this thread.)
> >
> > --
> > --Guido van Rossum (home page: 
> > http://www.python.org/~guido/
> )
> > ___
> > Python-Dev mailing list
> > Python-Dev@python.org
> > http://mail.python.org/mailman/listinfo/python-dev
> > Unsubscribe:
> http://mail.python.org/mailman/options/python-dev/python-dev%40hda3.com
> >
>
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] address manipulation in the standard lib

[DrKJam]

A merger sounds like a good way forward.

It shouldn't be as painful as it might sound initially and there should be
lots of room for some early big wins.

Contentious Issues
--

*** Separate IP and CIDR classes

The IP and CIDR object split in netaddr is going to require some further
discussion. They are mostly related to what operations to keep and which to
drop from each. More on this later on when I've had some time to think about
it a bit more.

*** Using the Stategy pattern

I'd like to see us use the GoF strategy pattern in a combined solution with
a single IP class for both v4 and v6, with separate strategy classes (like
netaddr), rather than two separate IPv4 and IPv6 classes returned by a
factory function (like ipaddr). Again this might require a bit of further
discussion.

Killer Features
---

Here's a list of (hopefully uncontroversial) features for a combined module

*** Maintain ipaddr speeds

Impressive stuff - I like it!

***  PEP-8 support

*** Drop MAC and EUI support

I'm happy to let the MAC (EUI-48) and EUI-64 support find a good home in a
separate module. Guido's sense of this being something separate is spot on
despite the apparent benefits of any code sharing. Where necessary, the
separate module can import whatever it needs from our combined module.

***  Pythonic behaving of IP objects

IP address objects behave like standard Python types (ints, lists, tuples,
etc) dependent on context.

This is mainly achieved via copious amounts of operator overloading.

For example, instead of :-

>>> IP('192.168.0.0/24').exclude_addrs('192.168.0.15/32')
['192.168.0.0/29', '192.168.0.8/30', '192.168.0.12/31', '192.168.0.14/32']

you could just implement __sub__ (IP object subtraction) :-

>>> IP('192.168.0.0/24', format=str) - IP('192.168.0.15/32')
['192.168.0.0/29', '192.168.0.8/30', '192.168.0.12/31', '192.168.0.14/32']

Achieving the same results but in a more Python friendly manner.

Here's a list of operators I've so far found decent meanings for in netaddr
:-

__int__, __long__, __str__, __repr__, __hash__
__eq__, __ne__, __lt__, __le__, __gt__, __ge__
__iter__, __getitem__, __setitem__, __len__, __contains__
__add__, __sub__, __isub__, __iadd__

***  Constants for address type identification

Identifying specific address types with a constant is essential. netaddr has
the module level constants AT_INET and AT_INET6 for IPv4 and IPv6
respectively. I'll be the first to agree that AT_* is a bit quirky. As we
are looking to something for the stdlib we should use something more, well,
standard such as AF_INET and AF_INET6 from the socket module.

Is AF_INET6 fairly widely available on most operating systems these days?
Not sure how socket constants have fared in Google's App Engine socket
module implementation for example. If not, we can always define some
specifically for the module itself.

***  Use the Python descriptor protocol to police IP objects attribute
assignments

This makes IP object properties read/writable rather than just read-only.

I discovered this on the Python mailing list a while back in the early days
of netaddr's development. They are excellent and open up a whole new world
of possibilities for keeping control of your objects internal state once you
allow users write access to your class properties.

***  Formatter attributes on IP objects to controls return value
representations

Sometimes you just want the string or hex representation of an address
instead of grokking IP objects the whole time. A useful trick when combined
with descriptor protocol above.

***  Use iterators

I notice ipaddr doesn't currently use the 'yield' statement anywhere which
is a real shame. netaddr uses iterators everywhere and also defines an
nrange() function built as an xrange() work-a-like but for network addresses
instead of integers values (very similar).

***  Add support for IPv4 address abbreviations

Based on 'old school' IP classful networking rules. Still useful and worth
having.

***  Use slices on IP objects!

There's nothing quite like list slices on a network object ;-) I've got some
horrendous issues trying to get this going with Python n-bit integers for
IPv6 so I'd love to see this working correctly.

***  Careful coding to avoid endianness bugs

I spent a decent chunk of development time early on doing endian tests on
all basic integer conversion operations. Any combined solution must be rock
solid and robust in this area. It's all too make naive assumption and get
this wrong. OK, so it's a pet hate of mine! I'm looking forward to Python
stdlib buildbot support in this area ;-)

***  Display of IP objects as human-readable binary strings

Sometimes it's just nice to see the bit patterns!

***  Python 'set' type operations for collections of IP objects

Intersection, union etc between network objects and groups of network
objects. More nice to have than essential but would be interesting to see
working. I've spent time thinking about it but haven'

[Python-Dev] Availability of IPv6 support in the socket module

[DrKJam]

Are there any current plans for 2.7/3.1 to have inet_pton() and inet_ntop()
made available via the socket module?

Not sure how feasible or difficult doing this would be across all support
Python platforms but it would certainly be useful, especially now there is
talk about adding IPv4/IPv6 address manipulation support to the standard
library (http://bugs.python.org/issue3959).

This would provide handy C-level speed ups to IPv6 operations on
interpreters where the socket module is available. Google App Engine's
Python interpreter is one place where I believe inet_ntoa/aton and possibly
inet_ntop/pton are not and will not be made available (by design). In such
cases, a library could easily resort to ubiquitous (slightly slower)
pure-Python fallbacks.

Also, does anyone have a feeling for how available thet AF_INET6 constant is
is across all Python's many supported platforms?

Thanks,

David Moss
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Availability of IPv6 support in the socket module

[DrKJam]

2009/1/14 DrKJam 

> Are there any current plans for 2.7/3.1 to have inet_pton() and inet_ntop()
> made available via the socket module?
>
> Not sure how feasible or difficult doing this would be across all support
> Python platforms but it would certainly be useful, especially now there is
> talk about adding IPv4/IPv6 address manipulation support to the standard
> library (http://bugs.python.org/issue3959).
>
> This would provide handy C-level speed ups to IPv6 operations on
> interpreters where the socket module is available. Google App Engine's
> Python interpreter is one place where I believe inet_ntoa/aton and possibly
> inet_ntop/pton are not and will not be made available (by design). In such
> cases, a library could easily resort to ubiquitous (slightly slower)
> pure-Python fallbacks.
>
> Also, does anyone have a feeling for how available thet AF_INET6 constant
> is is across all Python's many supported platforms?
>
> Thanks,
>
> David Moss
>


A real RTFM moment. I'm using Windows and I see Linux has had this support
since 2.3 or earlier. Please ignore.
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

[Python-Dev] PyPI trove classifiers for alternate language implementations

[DrKJam]

Would it be possible to have trove classifiers added to PyPI specifically
for PyPy and possibly also Jython and IronPython?

Regards,

David Moss
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com