Paul Rubin a écrit :
Bruno Desthuilliers <bruno.42.desthuilli...@websiteburo.invalid> writes:
But those occasions are rare enough that having to
enable the feature by saying (e.g.) "@dynamic" before the class
definition doesn't seem like a problem,
This imply that you (as the library author) pretend to know by advance
when your users (programmers) will have a need for dynamism and when
they won't.
We're not talking about libraries here.
Yes we are. If the default is "non-dynamic", then a class author is in
charge of explicitely allowing it when *he* see fits.
But in fact, we do have
extensible and non-extensible versions of certain libraries (pickle,
StringIO)
what we have are python-coded and highly optimized C-coded versions of
the same libraries. FWIW, in both cases, the python version came first,
and the C implementation followed when it was clear that for these
specific libs, the less-dynamic C version's perf improvement justified
giving up on dynamism, *given that:*
so that the user can pick the one that suits their requirements.
As long as it's up to the *user* to choose, that's ok. Your "@dynamic"
class decorator doesn't have the same implications.
--
http://mail.python.org/mailman/listinfo/python-list
