I've just subscribed to python-dev again after being pointed towards this thread (thanks Raymond).<br><br>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.<br>
<br>It would be a shame to see all the hard work go to waste on Y.A.P.I.M. :-<br><br> <a href="http://code.google.com/p/netaddr/wiki/YetAnotherPythonIPModule">http://code.google.com/p/netaddr/wiki/YetAnotherPythonIPModule</a><br>
<br>There is a veritable graveyard of stuff out there! Some good, some not so good.<br><br>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.<br>
<br>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.<br>
<br>Having had quite a while to think about this over the last few months, this is what I would ideally like to see.<br><br>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?<br>
<br>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 ;-)<br>
<br>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?<br><br>Whoever overseas this would need to be someone with a fairly neutral perspective on all of this.<br>
<br>Dave M.<br><br>