On 8 Aug 2013 02:48, "Larry Hastings" <la...@hastings.org> wrote: > > On 08/05/2013 09:59 PM, Nick Coghlan wrote: >>> >>> ___________________________________________________________________ >>> Question 2: Emit code for modules and classes? >>> >>> [...] Originally Clinic didn't ask for full class and module information, you just >>> specified the full dotted path and that was that. But that's ambiguous; >>> Clinic wouldn't be able to infer what was a module vs what was a class. And >>> in the future, if/when it generates module and class boilerplate, obviously >>> it'll need to know the distinction. [...] >> >> Note that setuptools entry point syntax solves the namespace ambiguity >> problem by using ":" to separate the module name from the object's >> name within the module (the nost test runner does the same thing). I'm >> adopting that convention for the PEP 426 metadata, and it's probably >> appropriate as a concise notation for clinic as well. > > > So you're proposing that xml.etree.ElementTree.dump() be written as "xml.etree:ElementTree.dump", and datetime.datetime.now() be written as "datetime:datetime.now"? And presumably *not* specifying a colon as part of the name would be an error.
Assuming there's no way to tell argument clinic all the functions and classes in a given C file belong to the same module, then yes, you would need the colon in every name to indicate the module portion. > > >>> ___________________________________________________________________ >>> Question 5: Keep too-magical class decorator Converter.wrap? >> >> You misunderstand me: I believe a class decorator is the *wrong >> >> solution*. I am saying Converter.wrap *shouldn't exist*, and that the >> logic for what it does should be directly in Converter.__init__. > > > Well, nobody liked it, everybody hated it, so I'll go with what you proposed, though with the name converter_init() for the custom converter init function. My future code-reading self thanks you :) Cheers, Nick. > > > /arry
_______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
