On 2018-05-16 17:31, Petr Viktorin wrote:
The larger a change is, the harder it is to understand
I already disagree here...
I'm afraid that you are still confusing the largeness of the *change*
with the complexity of the *result* after the change was implemented.
A change that *removes* complexity should be considered a good thing,
even if it's a large change.
That being said, if you want me to make smaller changes, I could do it.
But I would do it for *you* personally because I'm afraid that other
people might rightly complain that I'm making things too complicated.
So I would certainly like some feedback from others on this point.
Less disruptive changes tend to have a better backwards compatibility story.
Maybe in very general terms, yes. But I believe that the "disruptive"
changes that I'm making will not contribute to backwards
incompatibility. Adding new ml_flags flags shouldn't break anything and
adding a base class shouldn't either (I doubt that there is code relying
on the fact that type(len).__base__ is object).
In my opinion, the one change that is most likely to cause backwards
compatibility problems is changing the type of bound methods of
extension types. And that change is even in the less disruptive PEP 576.
Mark Shannon has an upcoming PEP with an alternative to some of the
issues.
I'm looking forward to a serious discussion about that. However, from a
first reading, I'm not very optimistic about its performance implications.
Currently, the "outside" of a function (how it looks when introspected)
is tied to the "inside" (what happens internally when it's called).
Can we better enable pydoc/IPython developers to tackle introspection
problems without wading deep in the internals and call optimizations?
I proposed complete decoupling in https://bugs.python.org/issue30071 and
that was rejected. Anyway, decoupling of introspection is not the
essence of this PEP. This PEP is really about allowing custom built-in
function subclasses. That's the hard part where CPython internals come
in. So I suggest that we leave the discussion about introspection and
focus on the function classes.
But, it still has to inherit from base_function to "look like a
function". Can we remove that limitation in favor of duck typing?
Duck typing is a Python thing, I don't know what "duck typing" would
mean on the C level. We could change the existing isinstance(...,
base_function) check by a different fast check. For example, we
(together with the Cython devs) have been pondering about a new "type"
field, say tp_cfunctionoffset pointing to a certain C field in the
object structure. That would work but it would not be so fundamentally
different from the current PEP.
*PS*: On friday, I'm leaving for 2 weeks on holidays. So if I don't
reply to comments on PEP 575 or alternative proposals, don't take it as
a lack of interest.
Jeroen.
_______________________________________________
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
