Hi all, Please be mindful when replying, even if some of the lurker know who some of you are and can figure out that some of the reply to this thread below this message are sarcastic, not all readers can. Your messages can also be cited out of context. Thus many messages in this thread can be misinterpreted, and can be/are hurtful (regardless of previous misinterpretation).
Please try to give the example. Some of the recent exchanges are typically the kind of things that are driving contributors away, or even just repel users from following what's happening on Python-*. Honestly I like to hear about ideas here, but if it's to have to read these kind of exchanges, I'm starting to lean toward unsubscribing. I'll remind you that Brett Cannon wrote an email to this list only 9 days ago to remind people to be civil. Also when you are subscribed to the mailing list a link to the code of conduct is appended to every mails: Code of Conduct: http://python.org/psf/codeofconduct/ Regards, -- Matthias On Wed, Nov 16, 2016 at 1:27 AM, Paul Moore <p.f.mo...@gmail.com> wrote: > On 16 November 2016 at 08:51, Mikhail V <mikhail...@gmail.com> wrote: >> What semantics it will fundamentally break or so hard to implement? > > I'm afraid I don't have time at the moment to fully review your email, > but my first impression is that you are proposing that the name "self" > be treated specially. It's going to be very difficult to convince > people that this is a good idea. > > In the first instance, if you're talking about "self" being a keyword, > that would break the current usage of "self" as a normal variable > name, which is used by convention in all class methods to represent > the current object. If you're not aware, in > > class A: > def method(self): > ... > > the use of self as the variable name is *convention*. You could use > any other name just as well. If self were a keyword, it couldn't be > used here. > > So making "self" a keyword would be a major change. > > In addition, consider code like this: > > class A(int): > def method(self): > myvar = 1 > myvar = self + 1 > return myvar > > foo = A(5) > foo.method() > > This is legitimate code at the moment. It sets "myvar" to 6 (self is > an integer subclass with value 5, which the code adds 1 to) and > returns that. Your proposal would change that to return 2. > > The problem here is that when considering language changes, you can't > just consider code that you consider "correct". You have to take > account of the fact that other people may be writing code that is to > your eyes bizarre and unmaintainable - but if it does what they want > it to, and it works according to the language specification, they have > a right to expect that the behaviour won't get changed (at least not > without due consideration of the backward compatibility process). So > proposals that change the behaviour of currently working code have to > be *very* careful to consider all edge cases. > > This is probably the biggest hurdle for people proposing changes to > Python to get over. Backward compatibility isn't pleasant to deal with > - it's frustrating and demotivating to have a good idea blocked > because code that seems senseless "might break". But that's part of > the price we have to pay for Python being a hugely popular language. > > Hope this is useful. > 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/ _______________________________________________ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
