On 8 Aug 2013 02:48, "Larry Hastings"
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