I think you could implement this yourself with metaclasses and it wouldn't have much (if any) performance hit per-call or per-instantiation (just a bit slower when creating the class definition). It's a bit heavy-handed-hand-holding–if you ask me–but if you want to do it, the language gives you the ability. On Tue, Nov 22, 2016 at 3:24 PM, Adrián Orive Oneca < adrian.orive.oneca@gmail.com> wrote:

This is just a convenience utility that would impact performance. This kind of enhancements, in my opinion, should be taken care by the IDEs, not by the interpreters.

_______________________________________________ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/

On 23 November 2016 at 08:08, François Leblanc wrote:

It's why I'd prefer this integrate in language, but if there no way to get it without performance cost I will have a look to a pylint solution...

The point here is that if there is a way to get it without a performance cost (I can't imagine there would be, it's got to add a check for whether you're overriding a method at a minimum, but you may be able to come up with something) then you can do that within the language as it stands. It may need a specialised metaclass, but that's not a problem. At least, if it *is* an issue to you, you can argue for having it be the behaviour of the default metaclass once you've demonstrated that it works and doesn't hurt performance. And if there is a performance hit, then having the behaviour as opt-in based on a custom metaclass means that people can choose if they want to pay that cost. Paul

Related thread https://mail.python.org/pipermail/python-ideas/2016-July/041095.html On Nov 23, 2016 20:30, "François Leblanc" wrote:

I can imagine using a metaclass specialized witch can be activate or desactivate but the cost of decorator call still be here...

I think its will be a good improvement if we can provide a solution for this, and i ask myself if this can be set

in interpreter with a flag to activate for exemple and with no performance cost without the flag set, so you

will have the choice and a good way to check youre code.

To have no performance cost perhaps the best way it's to use docstring and pylint...

2016-11-23 10:10 GMT+01:00 Paul Moore :

...

On 23 November 2016 at 08:08, François Leblanc wrote:

...

It's why I'd prefer this integrate in language, but if there no way to get it without performance cost I will have a look to a pylint solution...

The point here is that if there is a way to get it without a performance cost (I can't imagine there would be, it's got to add a check for whether you're overriding a method at a minimum, but you may be able to come up with something) then you can do that within the language as it stands. It may need a specialised metaclass, but that's not a problem. At least, if it *is* an issue to you, you can argue for having it be the behaviour of the default metaclass once you've demonstrated that it works and doesn't hurt performance. And if there is a performance hit, then having the behaviour as opt-in based on a custom metaclass means that people can choose if they want to pay that cost.

Paul

_______________________________________________ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/

You can do it at run-time, if you so desire, without a measurable performance hit with a metaclass. Here's a hacky demo: https://gist.github.com/nicktimko/5f08d6adfa1dbe1319c3bfc715ec0aa4#file-over... (Pedants: Any performance hit will be constant-time and probably less than a stray import that you don't need. If you're worried about optimizing constant-time things, I think you have larger problems.) On Thu, Nov 24, 2016 at 5:48 PM, Victor Stinner wrote:

Similar or related issue recently open and quickly closed: http://bugs.python.org/issue28776 "Duplicate method names should be an error"

In short, such job should be done by linters. I'm quite sure that many of them already implement such check.

Victor _______________________________________________ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/

This idea is being kicked around from forum to forum and nobody wants to have it. Here it's brought up from time to time and the response is usually "let a linter do it". In mypy (which is essentially a powerful linter) it was proposed ( https://github.com/python/mypy/issues/1888) and the response was essentially "better go to python-ideas or bugs.python.org". It's also been proposed as a PEP 484 feature: https://github.com/python/typing/issues/269#issuecomment-243765549 . I think one reason why such proposals are unwelcome to experienced users may be that when done right this is totally legitimate, and the requirement to use an @override decorator is just making code more verbose with very little benefit. (I could see a benefit -- if this is used consistently it could make spelunking a large codebase easier, because you would know which methods are overrides. Something like mypy could then enforce its use. But an IDE could also just highlight method overrides differently, maybe PyCharm or PyDev already do that?) -- --Guido van Rossum (python.org/~guido http://python.org/%7Eguido)

Le 26 nov. 2016 4:27 AM, "Guido van Rossum" a écrit :

This idea is being kicked around from forum to forum and nobody wants to

Here it's brought up from time to time and the response is usually "let a

In mypy (which is essentially a powerful linter) it was proposed ( https://github.com/python/mypy/issues/1888) and the response was essentially "better go to python-ideas or bugs.python.org".

It's also been proposed as a PEP 484 feature: https://github.com/python/typing/issues/269#issuecomment-243765549 .

I think one reason why such proposals are unwelcome to experienced users may be that when done right this is totally legitimate, and the requirement to use an @override decorator is just making code more verbose with very

have it. Sorry, I want to have it but I dont want to pay the price in performance cost.. linter do it". It's true, but in other hand because the subject come back from time to time, perhaps something better can be imagine the need is here. little benefit. (I could see a benefit -- if this is used consistently it could make spelunking a large codebase easier, because you would know which methods are overrides. Something like mypy could then enforce its use. But an IDE could also just highlight method overrides differently, maybe PyCharm or PyDev already do that?) The goal is not to make the code more verbose at all, it's to make code more sure in big or/and collaborative projects. The goal it's to give the possibility to secure the use of one of the more powerful feature of python. I think this kind of mistake may slow the time development and consequently afraid manager of using python in business environnement. Last time i have extend a Tkinter Top le vel and get in trouble with some comportement, I've just introduce a configuration function in my extended class. We often give same name for same functionnalities and that is the trouble if its not volontary. In case the function or variable is runtime defined its very hard to detect the error and pylint tools like will not help...

-- --Guido van Rossum (python.org/~guido)

_______________________________________________ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/

On 26 November 2016 at 07:16, Nick Coghlan wrote:

On 26 November 2016 at 13:26, Guido van Rossum wrote:

...

I think one reason why such proposals are unwelcome to experienced users may be that when done right this is totally legitimate, and the requirement to use an @override decorator is just making code more verbose with very little benefit.

It's also the case that if we're going to provide decorators to help with class definitions, there are more valuable things that we can do beyond merely warning about accidental method and attribute overrides.

This comment made me think about another potential issue with the @override proposal. If overriding a method without using the decorator were to produce a warning, how would that interact with custom class decorators or metaclasses that inject methods into a class? Would they have to take special care to detect and mark overrides? While it's true that if a custom metaclass injects an unintended override, that's just as much a problem as if the user explicitly writes one, the problem arises for the end user of such a custom metaclass, who will get an obscure warning about internals that they probably don't know how to fix. Nothing insurmountable, sure, but it does act as a reminder that a change like this could have pretty wide reaching implications... Paul

If we can sawp base class object with a flag It would be possible to use a special base object that could warn for this kind of problem? This can let write specifics metaclass witch replace base object by default, and when all is checked for end user don't use the flag... Does it is possible? What do you think about? Le 26/11/2016 à 12:26, Nick Coghlan a écrit :

...

On 26 November 2016 at 07:16, Nick Coghlan wrote:

...

On 26 November 2016 at 13:26, Guido van Rossum wrote:

...

I think one reason why such proposals are unwelcome to experienced users may be that when done right this is totally legitimate, and the requirement to use an @override decorator is just making code more verbose with very little benefit. It's also the case that if we're going to provide decorators to help with class definitions, there are more valuable things that we can do beyond merely warning about accidental method and attribute overrides. This comment made me think about another potential issue with the @override proposal. If overriding a method without using the decorator were to produce a warning, how would that interact with custom class decorators or metaclasses that inject methods into a class? Would they have to take special care to detect and mark overrides? It would potentially be even more annoying than that - if we did something like this without being sufficiently careful about it, you'd need to use the decorator any time you overwrote a special method

On 26 November 2016 at 21:15, Paul Moore wrote: that's actually implemented on "object". Ditto for method overrides when inheriting from an abstract base class, or any other base class that defines an API where the base class method implementation raises NotImplementedError.

By contrast, if it's opt-in via a class decorator, then folks that want additional definition time assistance from the interpreter can request that explicitly, while existing code remains unaffected.

Cheers, Nick.

Le 26 nov. 2016 3:23 PM, "Nick Coghlan" a écrit :

On 26 November 2016 at 22:24, France3 wrote:

...

replace base object by default, and when all is checked for end user don't use the flag...

Does it is possible? What do you think about?

There's no need to do this in a base class, since it can be done via external introspection. That introspection could live in at least a couple of different places:

- a class decorator, which checks for unmarked overrides at class definition time - a test utility, that given a module name, imports the module, finds any defined classes, and checks them for unmarked overrides

All an override marker would have to do to enable that introspection is to set a particular attribute on the method definition.

Cheers, Nick.

-- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia

I think that it's will be hard to take care of all situations this way... Moreover having a way to rewrite object base class open more perspectives from my point of view.

On Mon, Nov 28, 2016 at 10:11 AM, Chris Barker wrote:

Am I missing something?

Given Python's dynamic nature, there is simply no way to know if a method is overriding a superclass' method until it is called -- and, now that I think about it even then you don't know.

At compile time, none of the superclasses may have the given method.

At run time, a method could be monkey patched into the superclass before the subclass' instance is created.

In fact, at run time, the superclass could get the method added after instances are created.

At calling time, the subclass' method will be found, and used, and the search stops there -- no way to know if there is one with the same name further up the MRO.

This is simply incompatable with a language this dynamic.

Not so fast! Python is also so dynamic that you can easily create a metaclass (or a class decorator) that does the checking (assuming reasonable behavior of all classes involved) at class definition time. Given that the use of such a metaclass will be voluntary, for classes with unreasonable behavior it should simply not be applied. I'm not sure yet if it is desirable to have such a metaclass or class decorator in the stdlib, nor have I thought through its design. Such a design should first be deployed via PyPI and then we can judge its effectiveness based on how popular it becomes. (There may already be one, I've not done that research either.) -- --Guido van Rossum (python.org/~guido)

On Mon, Nov 28, 2016 at 1:32 PM, Chris Barker wrote:

On Mon, Nov 28, 2016 at 10:22 AM, Guido van Rossum wrote:

...

At calling time, the subclass' method will be found, and used, and the

...

search stops there -- no way to know if there is one with the same name further up the MRO.

This is simply incompatable with a language this dynamic.

Not so fast! Python is also so dynamic that you can easily create a metaclass (or a class decorator) that does the checking (assuming reasonable behavior of all classes involved) at class definition time.

but that's class definition time -- can't classes be dynamically mangled later on -- after subclasses have been defined?

They can, and they @override can be bypassed. I don't see that as a condemnation of @overload -- it just means that it's not perfect, which is fine with me (given that we're talking about monkey-patching here).

If I have this right the mro is set at class definition time, so it is knows which classes are in the tree -- but class objects themselves are mutable -- methods can be added later on. so a subclass could have a method that isn't overriding anything when it's defined, but ends up overriding something later on, 'cause the base class changed under it.

Isn't this why the mro is searched at method calling time? rather than a static table being used? (if not -- wouldnt that be a nice optimization?)

Granted -- this kind of late class mangling has got to be pretty unusual (and maybe only useful for mocking, or??) but it is there.

Which is why it could be useful to have some syntax or convention for specifying "I'm intending to override a method", that linters or type checkers, or whatever external tool, can use. But it can't be enforced at runtime in the language.

Depends on how much enforcement you need. Bike locks also don't typically enforce that your bike doesn't get stolen... -- --Guido van Rossum (python.org/~guido)

On Mon, Nov 28, 2016 at 1:44 PM, Chris Barker wrote:

On Mon, Nov 28, 2016 at 1:37 PM, Guido van Rossum wrote:

...

They can, and they @override can be bypassed. I don't see that as a condemnation of @overload -- it just means that it's not perfect, which is fine with me (given that we're talking about monkey-patching here).

sure -- but this all strikes me as kind of like type checking -- there is a lot of use for robust code, but we don't want it at run-time in the language.

Also -- the ship has kinda sailed on this - maybe a @not_override would make more sense.

Isn't the goal to make sure you don't accidentally override a method? saying "I know I'm overriding this" is less useful than "I'm not intending to override anything here"

I think you're fighting a straw man. I never said @override should be added to the language. I said that it would be useful to have a 3rd party metaclass or a class decorator that implements it which packages may voluntarily use to constrain their subclasses (or their own uses -- different designs are possible). -- --Guido van Rossum (python.org/~guido)

On 29 November 2016 at 08:01, Chris Barker wrote:

On Mon, Nov 28, 2016 at 1:50 PM, Guido van Rossum wrote:

...

...

Also -- the ship has kinda sailed on this - maybe a @not_override would make more sense.

Isn't the goal to make sure you don't accidentally override a method? saying "I know I'm overriding this" is less useful than "I'm not intending to override anything here"

I think you're fighting a straw man. I never said @override should be added to the language. I said that it would be useful to have a 3rd party metaclass or a class decorator that implements it which packages may voluntarily use to constrain their subclasses (or their own uses -- different designs are possible).

I know -- I just happened to add that to a reply to you...

That was for the OP, or anyone else thinking of writing such a thing.

And I still think it would better be added to a linting tool than at run-time -- but let whoever writes it figure that out.

Writing linting tools for Python class hierarchies is pretty hard in the general case, since you have to account for the fact that the module level control flow logic is Turing complete (and many linters simply don't try, instead saying "don't do that if you want the linter to work properly"). By contrast, a class decorator or metaclass can do the checks at runtime by walking the MRO, just as ABCMeta can look for @abstractmethod declarations that haven't been overridden in a subclass, and SQL Alchemy can map subclass inheritance to table linkages. If you look at the way attrs writes its automatic __init__ methods for example, it creates a single flat __init__ based on the definition time MRO: https://attrs.readthedocs.io/en/stable/how-does-it-work.html That's the nice part about this kind of thing being opt-in: the definition time tooling *doesn't* have to cope with the full extent of Python's dynamic nature, as it can expect the user to be cooperating with the tool to some degree, and "you're not cooperating" can be a valid error to throw. Cheers, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia