Nick Coghlan added the comment:
Eric and I discussed this further this morning. We were interested in two main
points:
1. When no custom namespace is used, we definitely shouldn't double the storage
requirements for the class object
2. If a custom namespace is used, it would be nice to make it available to both
the __init_class__ hook *and* to class decorators
The design we came up with for doing so is for type.__new__ to include the
equivalent of:
if type(namespace) != dict:
cls.__namespace__ = types.MappingProxyType(namespace)
The practical downside of that approach is that it still doubles the storage
requirements for every class that uses a custom namespace, even if the custom
namespace isn't actually needed after creation. The upside is that you can
write a class decorator that needs ordering information and say "to use this
decorator, you must also specify 'namespace=collections.OrderedDict()'"
There's also a major complexity downside to that approach - the distinction
between __dict__ and __namespace__ is somewhat subtle, especially since
__namespace__ won't see later changes made through setattr() and delattr(), and
__dict__ won't see changes made through any external references to the custom
namespace.
That means my current inclination is to instead change the signature of
__init_class__ to accept a read-only view of the execution namespace as a
second parameter. Decorators won't have access to the details lost by the
copying of attributes into an ordinary dict unless used with a metaclass or
base class that takes steps to attach it to the created class object. I can
live with that limitation, and it means we only have to properly document the
"the contents of the class execution namespace are copied into an ordinary dict
instance when the class is created" behaviour of type to explain why
__init_class__ has the second parameter.
----------
_______________________________________
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue17044>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
