Hello,
While I think this should not be "on by default", I don't see the harm in
being able to opt-in to this behavior.
I also figured spending a few minutes attempting to write this would be fun:
https://gist.github.com/veloutin/2ec3e5246651f5de78442516d8e24fc1
François: sorry about the double
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?
>>> sayin
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 in
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
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 al
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.
>>>
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.
>>
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,
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
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 clas
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 introspec
Steven D'Aprano writes:
> Sometimes I think Python-as-a-teaching-language and Python-as-a-
> production-language are strongly opposed.
I haven't found that to be the case. Linters are quite effective, as
long as you discipline the students to use them. I don't think this
check is in the lint
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? W
On 26 November 2016 at 21:15, Paul Moore wrote:
> 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, an
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
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
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
have it.
Sorry, I want to have it but I dont want to pay the price in performance
cost..
> Here it's brought up from time to time and the response is usually "let a
Here's hopefully a working link; GitHub's rendering seems to be iffy:
https://nbviewer.jupyter.org/urls/gist.githubusercontent.com/nicktimko/5f08d6adfa1dbe1319c3bfc715ec0aa4/raw/37dd95cd92be7b7e5af01b98ce9e8e00a705b3f7/override_guard.ipynb
Knowing how to do some introspection with dunder magic att
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 respons
On Fri, Nov 25, 2016 at 02:21:28PM -0500, Nick Timkovich wrote:
> 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-override_guard-ipynb
All I get at t
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-override_guard-ipynb
(Pedants: Any performance hit will be constant-time and probably less than
a stray i
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
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
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
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 imag
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...
2016-11-22 23:49 GMT+01:00 Nick Timkovich :
> I think you could implement this yourself with metaclasses and it wouldn't
> have much (if any) performa
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 th
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/li
Hi there,
I like python easy extend class and reusse code, but sometime I overwrite
involontary some functions or variables from parents.
I think about a decorator to confirm overwrite is intended and put a warning if
is not present.
class A:
def hello(self):
print('Hello A')
clas
29 matches
Mail list logo
