(kicking an old thread)

On Mon, Jan 5, 2009 at 11:21 AM, Guido van Rossum
<report@bugs.python.org> wrote:
>
> Guido van Rossum <guido@python.org> 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).
>
> Since I haven't used either module and am not particularly interested in
> this functionality, I'm withdrawing myself from the set of experts who
> can decide which is better.
>
> Duncan McGreggor asked some questions on python-dev; here are my responses:
>
>>  * do we want to limit it to IP (i.e. no EUI/MAC support)?
>
> I don't want to exclude EUI/MAC support, but it seems quit a separate
> (and much more specialized) application area, so it's probably best to
> keep it separate (even if it may make sense to use a common (abstract
> or concrete) base class or just have similar APIs).
>
>>  * do we want a single module or is a package acceptable?
>
> I don't care either way.
>
>>  * other thoughts?
>
> How about a merger?

so we've talked about this on the ipaddr/netaddr lists and it seems
like a merger is pretty unlikely.  ipaddr and netaddr have some pretty
fundamental design differences, to the point where a merger wouldn't
mean a complete re-write of one or the other (in which case we're back
to picking one over the other).

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?

for ipaddr's part, trunk is now pep8 compliant (with some backwards
compatible aliases).  I also know that David hasn't stopped adding
features to netaddr as well.

So, where do we go from here?

Cheers,
/peter

> _______________________________________
> Python tracker <report@bugs.python.org>
> <http://bugs.python.org/issue3959>
> _______________________________________
>