On Thu, Jan 11, 2018 at 8:45 PM, Steve Dower <steve.dower@python.org> wrote:

I certainly have code that joins __module__ with __name__ to create a fully-qualified name (with special handling for those builtins that are not in builtins), and IIUC __qualname__ doesn't normally include the module name either (it's intended for nested types/functions).

In fact __qualname__ should never include the module. It should however include the containing class(es). E.g. for # __main__.py: class Outer: class Inner: def f(self): pass print(Outer.Inner.f.__name__) # 'f' print(Outer.Inner.f.__qualname__) # 'Outer.Inner.f' print(Outer.Inner.f.__module__) # '__main__' IMO the current __module__ for these objects is just wrong (since they aren't in builtins -- even though they are "built in"). So in principle it should be okay to set it to 'types'. (Except I wish we didn't have the types module at all, but that's water under the bridge.) In practice I expect there to be some failing tests. Maybe investigate this for Python 3.8?

Can we make it visible when you import the builtins module, but not in the builtins namespace?

That would violate the very definition of the builtins module. PS. There are probably many more of these. E.g. NoneType, dict_keys, etc. --Guido On 12Jan2018 0941, Victor Stinner wrote:

...

I like the idea of having a fully qualified name that "works" (can be resolved).

I don't think that repr() should change, right?

Can this change break the backward compatibility somehow?

Victor

Le 11 janv. 2018 21:00, "Serhiy Storchaka" <storchaka@gmail.com <mailto:storchaka@gmail.com>> a écrit :

Currently the classes of functions (implemented in Python and builtin), methods, and different type of descriptors, generators, etc have the __module__ attribute equal to "builtins" and the name that can't be used for accessing the class.

>>> def f(): pass ... >>> type(f) <class 'function'> >>> type(f).__module__ 'builtins' >>> type(f).__name__ 'function' >>> type(f).__qualname__ 'function' >>> import builtins >>> builtins.function Traceback (most recent call last): File "<stdin>", line 1, in <module> AttributeError: module 'builtins' has no attribute 'function'

But most of this classes (if not all) are exposed in the types module.

I suggest to rename them. Make the __module__ attribute equal to "builtins" and the __name__ and the __qualname__ attributes equal to the name used for accessing the class in the types module.

This would allow to pickle references to these types. Currently this isn't possible.

>>> pickle.dumps(types.FunctionType) Traceback (most recent call last): File "<stdin>", line 1, in <module> _pickle.PicklingError: Can't pickle <class 'function'>: attribute lookup function on builtins failed

And this will help to implement the pickle support of dynamic functions etc. Currently the third-party library that implements this needs to use a special purposed factory function (not compatible with other similar libraries) since types.FunctionType isn't pickleable.

-- --Guido van Rossum (python.org/~guido)

On Thu, Jan 11, 2018 at 8:45 PM, Steve Dower <steve.dower@python.org> wrote:

I certainly have code that joins __module__ with __name__ to create a fully-qualified name (with special handling for those builtins that are not in builtins), and IIUC __qualname__ doesn't normally include the module name either (it's intended for nested types/functions).

In fact __qualname__ should never include the module. It should however include the containing class(es). E.g. for # __main__.py: class Outer: class Inner: def f(self): pass print(Outer.Inner.f.__name__) # 'f' print(Outer.Inner.f.__qualname__) # 'Outer.Inner.f' print(Outer.Inner.f.__module__) # '__main__' IMO the current __module__ for these objects is just wrong (since they aren't in builtins -- even though they are "built in"). So in principle it should be okay to set it to 'types'. (Except I wish we didn't have the types module at all, but that's water under the bridge.) In practice I expect there to be some failing tests. Maybe investigate this for Python 3.8?

Can we make it visible when you import the builtins module, but not in the builtins namespace?

That would violate the very definition of the builtins module. PS. There are probably many more of these. E.g. NoneType, dict_keys, etc. --Guido On 12Jan2018 0941, Victor Stinner wrote:

...

I like the idea of having a fully qualified name that "works" (can be resolved).

I don't think that repr() should change, right?

Can this change break the backward compatibility somehow?

Victor

Le 11 janv. 2018 21:00, "Serhiy Storchaka" <storchaka@gmail.com <mailto:storchaka@gmail.com>> a écrit :

Currently the classes of functions (implemented in Python and builtin), methods, and different type of descriptors, generators, etc have the __module__ attribute equal to "builtins" and the name that can't be used for accessing the class.

>>> def f(): pass ... >>> type(f) <class 'function'> >>> type(f).__module__ 'builtins' >>> type(f).__name__ 'function' >>> type(f).__qualname__ 'function' >>> import builtins >>> builtins.function Traceback (most recent call last): File "<stdin>", line 1, in <module> AttributeError: module 'builtins' has no attribute 'function'

But most of this classes (if not all) are exposed in the types module.

I suggest to rename them. Make the __module__ attribute equal to "builtins" and the __name__ and the __qualname__ attributes equal to the name used for accessing the class in the types module.

This would allow to pickle references to these types. Currently this isn't possible.

>>> pickle.dumps(types.FunctionType) Traceback (most recent call last): File "<stdin>", line 1, in <module> _pickle.PicklingError: Can't pickle <class 'function'>: attribute lookup function on builtins failed

And this will help to implement the pickle support of dynamic functions etc. Currently the third-party library that implements this needs to use a special purposed factory function (not compatible with other similar libraries) since types.FunctionType isn't pickleable.

-- --Guido van Rossum (python.org/~guido)