On 2018-05-16 17:31, Petr Viktorin wrote:
Less disruptive changes tend to have a better backwards compatibility story. A less intertwined change makes it easier to revert just a single part, in case that becomes necessary.
I'll just repeat what I said in a different post on this thread: we can still *implement* the PEP in a less intertwined and more gradual way. The PEP deals with several classes and each class can be changed separately.
However, there is not much point in starting this process if you don't intend to go all the way. The power of PEP 575 is really using this base_function class in many places.
A PEP just adding the class base_function as base class of buitin_function_or_method without using it anywhere else would make no sense by itself. Still, that could be a first isolated step in the implementation.
If PEP 575 is accepted, I would like to follow it up with PEPs to add more classes to the base_function hierarchy (candidates: staticmethod, classmethod, classmethod_descriptor, method-wrapper, slot wrapper, functools.lru_cache).
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
