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

DrKJam drkjam at gmail.com
Wed Jun 3 01:50:53 CEST 2009


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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20090603/974cf544/attachment.htm>


More information about the Python-Dev mailing list