[Python-Dev] PEP czar for PEP 3144? (original) (raw)

Nick Coghlan ncoghlan at gmail.com
Mon Feb 20 16:09:22 CET 2012

On Mon, Feb 20, 2012 at 11:55 PM, Antoine Pitrou <solipsis at pitrou.net> wrote:

On Mon, 20 Feb 2012 23:23:13 +1000 Nick Coghlan <ncoghlan at gmail.com> wrote:

Does anyone object to me naming myself PEP czar for PEP 3144? “Tsar is a title used to designate certain European Slavic monarchs or supreme rulers.” Is this our official word?

PEP czar/tsar and BDFOP (Benevolent Dictator for One PEP) are the two names I've seen for the role. I don't have a strong preference either way (just a mild preference for 'czar').

There's also basic-but-usable module documentation available (http://code.google.com/p/ipaddr-py/wiki/Using3144). Mmmh, some comments: - a network can be "in" another network? Sounds strange. Compare with  sets, which can be ordered, but not contained one within another.  The idea of an address or network being "in" an interface sounds even  stranger.

Ah, I'd missed that one. Yes, I think this a holdover from the main ipaddr module which plays fast and loose with type correctness by implicitly converting between networks and addresses in all sorts of places. It doesn't have Network and Interface as separate types (calling them both "Networks") and it appears the current incarnation of the Interface API still retains a few too many Network-specific behaviours.

I agree the "container" behaviour should be reserved for the actual Network API, with Interface objects behaving more like Addresses in that respect.

I also agree Network subset and superset checks should follow a set-style API rather than overloading the containment checks.

There are actually a few other behaviours (like compare_networks() that should probably be moved to the Network objects, and accessed via the "network" property for Interface objects.

- iterhosts()? Why not simply hosts()?

And I missed that one, too. Perhaps that provisional marker wouldn't be such a bad idea after all...

One requirement for integration would be fleshing out the standard library version of the documentation to include a full public API reference for the module and public classes, which will also help highlight any lingering naming problems, as well as areas where APIs that currently return realised lists should probably be returning iterators instead (there's currently iter_subnets() and subnet(), which should just be a single subnets() iterator).

- “A TypeError exception is raised if you try to compare objects of  different versions or different types.”: I hope equality still works?

It looks like it's supposed to (and does for Address objects), but there's currently a bug in the _BaseInterface.eq impl that makes it return None instead of False (the method impl should be returning NotImplemented, just as _BaseAddress does, with the interpreter than reporting False if both sides return NotImplemented).

There's currently an implicit promotion of Address objects to Interface objects, such that "network_or_interface == address" is the same as "network_or_interface.ip == address".

So yes, with the appropriate boundaries between the different types of objects still being a little blurred, I think a "provisional" marker is definitely warranted. Some of the APIs that are currently available directly on Interface objects should really be accessed via their .network property instead.

Cheers, Nick.

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

More information about the Python-Dev mailing list