Movatterモバイル変換

[Python-Dev] PEP czar for PEP 3144?

• Previous message:[Python-Dev] PEP czar for PEP 3144?
• Next message:[Python-Dev] PEP czar for PEP 3144?
• Messages sorted by:[ date ][ thread ][ subject ][ author ]

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 twonames I've seen for the role. I don't have a strong preference eitherway (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 mainipaddr module which plays fast and loose with type correctness byimplicitly converting between networks and addresses in all sorts ofplaces. It doesn't have Network and Interface as separate types(calling them both "Networks") and it appears the current incarnationof the Interface API still retains a few too many Network-specificbehaviours.I agree the "container" behaviour should be reserved for the actualNetwork API, with Interface objects behaving more like Addresses inthat respect.I also agree Network subset and superset checks should follow aset-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 viathe "network" property for Interface objects.> - iterhosts()? Why not simply hosts()?And I missed that one, too. Perhaps that provisional marker wouldn'tbe such a bad idea after all...One requirement for integration would be fleshing out the standardlibrary version of the documentation to include a full public APIreference for the module and public classes, which will also helphighlight any lingering naming problems, as well as areas where APIsthat currently return realised lists should probably be returningiterators 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), butthere's currently a bug in the _BaseInterface.__eq__ impl that makesit return None instead of False (the method impl *should* be returningNotImplemented, just as _BaseAddress does, with the interpreter thanreporting False if both sides return NotImplemented).There's currently an implicit promotion of Address objects toInterface objects, such that "network_or_interface == address" is thesame as "network_or_interface.ip == address".So yes, with the appropriate boundaries between the different types ofobjects still being a little blurred, I think a "provisional" markeris definitely warranted. Some of the APIs that are currently availabledirectly on Interface objects should really be accessed via their.network property instead.Cheers,Nick.-- Nick Coghlan   |  ncoghlan at gmail.com   |   Brisbane, Australia

• Previous message:[Python-Dev] PEP czar for PEP 3144?
• Next message:[Python-Dev] PEP czar for PEP 3144?
• Messages sorted by:[ date ][ thread ][ subject ][ author ]