[Python-Dev] PEP czar for PEP 3144?

[Nick Coghlan]

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