Mailman 3 July 2013 - docs

[issue18334] type(name, bases, dict) does not call metaclass' __prepare__ attribute
by Nick Coghlan 01 Jul '13

01 Jul '13

Nick Coghlan added the comment: Unfortunately, it's not that simple, as calling type(name, bases, namespace) is *exactly* what a subclass will do as part of creating the type object. >From inside the type implementation, we can't tell the difference between "properly called from the child type" and "improperly called without preparing the namespace first". ---------- _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue18334> _______________________________________

1 0

[issue18334] type(name, bases, dict) does not call metaclass' __prepare__ attribute
by Nikolaus Rath 01 Jul '13

01 Jul '13

Nikolaus Rath added the comment: In that cases, maybe type(name, cls, clsdict) should actually raise an error if there's a metaclass with __prepare__ involved? Presumably that would break only code that was already broken, but it would convert previously hidden behavioral bugs into an explicit expressions raised at the right point. ---------- _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue18334> _______________________________________

1 0

[issue18334] type(name, bases, dict) does not call metaclass' __prepare__ attribute
by Nick Coghlan 01 Jul '13

01 Jul '13

Nick Coghlan added the comment: I think we should actually go further, and explicitly defer to http://docs.python.org/3/library/types#dynamic-type-creation for dynamic type creation. Type shouldn't be called with arbitrary bases any more, precisely *because* doing so breaks __prepare__ handling. It's only safe to call a metaclass directly with arbitrary bases if you call types.prepare_class first: mcl, namespace, kwds = types.prepare_class(name, bases) cls = mcl(name, bases, namespace, **kwds) You can only skip types.prepare_class if you *know* you already have the right metaclass (such as when there aren't any base classes defined). ---------- _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue18334> _______________________________________

1 0

[issue18334] type(name, bases, dict) does not call metaclass' __prepare__ attribute
by R. David Murray 01 Jul '13

01 Jul '13

R. David Murray added the comment: "Intentional" is not perhaps the exactly right term, but it is working as expected. There was a thread about this on python-dev ("PEP 3115 compliant dynamic type creation" and "adding types.build_class for 3.3"), that ultimately resulted in the addition of the 'new_class' function to the types module. The documentation should probably just say that types doesn't handle metaclass __prepare__, and provide a link to the new_class function. ---------- assignee: -> docs@python components: +Documentation -Interpreter Core nosy: +docs@python, ncoghlan, r.david.murray versions: +Python 3.4 _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue18334> _______________________________________

1 0

[issue18331] Document that runpy.run_path and run_module copy the module globals
by Nick Coghlan 01 Jul '13

01 Jul '13

Nick Coghlan added the comment: As Richard said, the __globals__ attributes of the functions are pointing at the real module dictionary, which may have been cleared when the temporary module was destroyed. However, I just checked the docs and they don't actually mention the fact that run_path and run_module currently return a copy of the globals - they say they "return the resulting module globals dictionary." Since I would prefer it if the functions actually worked as advertised, I suggest we document the namespace copying as a CPython implementation detail, rather than as a guaranteed feature. That way we can eliminate these copy operations once the module namespace purging has been eliminated. Some related references: Don't purge module dicts before shutdown: issue 18214 Don't purge module dicts at all: issue 812369 More robust finalisation semantics: PEP 442 We should also tidy up the headings in the data model reference ( http://docs.python.org/3/reference/datamodel.html#the-standard-type-hierarc…) so we can link directly to the section that mentions the CPython module clearing implementation detail this behaviour is designed to work around. ---------- assignee: -> docs@python components: +Documentation -Library (Lib) nosy: +docs@python stage: -> needs patch title: runpy.run_path gives functions with corrupted .__globals__ -> Document that runpy.run_path and run_module copy the module globals type: behavior -> enhancement versions: +Python 2.7, Python 3.4 _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue18331> _______________________________________

1 0