[Python-Dev] "PyObject *module" for module-level functions?
Guido van Rossum
guido at python.org
Tue Nov 5 00:45:03 CET 2013
On Mon, Nov 4, 2013 at 3:36 PM, Nick Coghlan <ncoghlan at gmail.com> wrote:
> On 5 Nov 2013 08:49, "Larry Hastings" <larry at hastings.org> wrote:
> > When Clinic generates a function, it knows what kind of callable it
> represents, and it names the first argument (the "PyObject *") accordingly:
> > module-level function ("self"),
> > method ("self"),
> > class method ("cls"), or
> > class static ("null").
> > I now boldly propose that for the first one, the module-level function,
> the PyObject * parameter should be named "module". The object passed in is
> the module object, it's not a "self" in any conventional sense of the word.
> > This would enhance readability, as I assert the name "self" there is
> confusing. The argument is rarely used on module-level functions, and very
> little code is converted right now using Clinic anyway. I therefore assert
> this change would break very little code, and the code that did get broken
> by this change could be fixed as part of the process of converting it to
> > But now would be the time to make this change, before doing the big push
> to convert to Clinic. (A couple of weeks ago would have been even
> > +1? -1?
> +1 from me, as they're not really methods of the module instance (i.e.
> dynamically bound when retrieved from the module), even though they behave
> a little like they are.
> Instead of relying on the descriptor protocol (which doesn't trigger
> because module level functions are stored in an instance namespace), we
> play games when creating the Python level callables during module creation
> in order to prebind the module object
+1 from me too. This finally fixes a silly mistake I made well over two
--Guido van Rossum (python.org/~guido)
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Python-Dev