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@gmail.com | Brisbane, Australia