Guido van Rossum wrote:
As an aside, is it planned that sys.exc_traceback,type and value will start emitting DeprecationWarnings any time soon? [...]
It's hard to put a deprecation warning on these, because they're just module attributes.
This came up a day or two ago in c.l.py too. Bernhard Herzog suggested:
...
Well, this *is* the recommended trick when you absolutely, really need to trap module attribute access. I don't expect access to sys attributes to be time-critical, with a possible exception for sys.stdout (which is used internally by the print statement). But I think attribute access, even with a warnings check, can be fast enough.
I looked into the execution path of PyObject_GenericGetAttr. This first finds the type dictionary and sees if it can find something there. So access to special objects appears to be quite fast. The drawback is that only after searching all of the mro dicts, _PyType_Lookup gives up, and then the instance dict is inspected.
The big problem is that it would require a major rewrite of the sys module, wouldn't it?
I used a derived module class for my stackless module as well, just in order to define a couple of extra atributes, not aware of the extra costs for this. This is of course not so cheap, and with the current implementation, only the special attributes of sys would become rather cheap, which would in fact involve some work to do, because most probably most of the sys attributes might be considered special. Maybe, assuming that only very few sys attributes should grow special treatment, a special getattro() would make sense that looks into the instance(module) dict, first? Some half-baked thoughts: From another POV, modules are always just singletons, nobody really wants to create a new module type. Instead, they want a module with special attributes, which is a singleton instance. I think that after module creation, the class is no longer needed so much, since a module is created once. In a way, I think one would not want to create instances at all, but to let this single type act as class and instance at the same time. In practice, this could mean that a module is like a new type, which slot definitions, which define slots in the same object, plus the extra dictionary for ordinary module citizens. The type "module" becomes a metatype. The new modules become types which cannot create instances, but which carry both slot definitions and slots. just a rough idea -- chris -- Christian Tismer :^) <mailto:tismer@tismer.com> Mission Impossible 5oftware : Have a break! Take a ride on Python's Johannes-Niemeyer-Weg 9a : *Starship* http://starship.python.net/ 14109 Berlin : PGP key -> http://wwwkeys.pgp.net/ work +49 30 89 09 53 34 home +49 30 802 86 56 pager +49 173 24 18 776 PGP 0x57F3BF04 9064 F4E1 D754 C2FF 1619 305B C09C 5A3B 57F3 BF04 whom do you want to sponsor today? http://www.stackless.com/