Hi everyone, for those new to the discussion, I am the author of PEP 487, which has been discussed here: https://mail.python.org/pipermail/python-ideas/2015-February/032249.html
> The concern is twofold: it breaks proper information hiding/DRY, *and* > it fails silently. It should not be necessary for clients of package > A1 (that uses a decorator built using package B2) to mixin a metaclass > or decorator from package C3 (because B2 implemented its decorators > using C3), just for package A1's decorator to work properly in the > *client package's class*. (And then, of course, this all silently > breaks if you forget, and the breakage might happen at the A1, B2, or > C3 level.) I am just not capable to understand things at such an abstract level, would it be possible to give a simple example on what and how you did things in python 2? > IOW, there's no need to modify the core just to have *that* feature, > since if you control the base class you can already do what PEP 487 > does in essentially every version of Python, ever. If that's all PEP > 487 is going to do, it should just be a PyPI package on a > stdlib-inclusion track, not a change to core Python. It's not > actually adding back any of the dynamicness (dynamicity? > hookability?) that PEP 3115 took away. That was my point. You can find the PyPI package at: https://pypi.python.org/pypi/metaclass Greetings Martin _______________________________________________ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
