[Python-Dev] PEP czar for PEP 3144?

[Nick Coghlan]

Does anyone object to me naming myself PEP czar for PEP 3144?

I've collated the objections to the original proposal on a few
different occasions throughout the (long!) PEP review process, and as
noted in the Background section, the latest version of the PEP [1] has
addressed the key concerns that were raised:

- the "strict" flag for Network objects is gone (instead, the
validation differences between IP Network and IP Interface definitions
are handled as different classes with otherwise similar interfaces)
- the factory function naming scheme follows PEP 8
- some properties have been given new names that make it clearer what
kind of object they produce
- the module itself has been given a new name (ipaddress) to avoid
clashing with the existing ipaddr module on PyPI

There's also basic-but-usable module documentation available
(http://code.google.com/p/ipaddr-py/wiki/Using3144).

So, unless there are any new objections, I'd like to:
- approve ipaddress for inclusion in Python 3.3
- grant Peter Moody push access as the module maintainer
- create a tracker issue to cover incorporating the new module into
the standard library, documentation and test suite

(There are still a few places in both the PEP and the preliminary
documentation that say "ipaddr" instead of "ipaddress", but those can
be cleaned up as the module gets integrated).

I don't personally think the module API needs the provisional
disclaimer as the core functionality has been tested for years in
ipaddr and the API changes in ipaddress are just cosmetic ones either
for PEP 8 conformance, or to make the API map more cleanly to the
underlying networking concepts. However, I'd be willing to include
that proviso if anyone else has lingering concerns.

Regards,
Nick.

[1] http://www.python.org/dev/peps/pep-3144/

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia