Idea about method parameters

[Markus Schaber]

Greg Weeks <weeks at vitus.scs.agilent.com> schrub:

> Markus Schaber (markus at schabi.de) wrote:
> : Now I'd love to have the possibility to shorten this by typing:
> 
> : class A:
> :     def m(self, self.value):
> :         pass # or the other work to be done
> 
> I don't mean this personally, but this sort of suggestion fills me
> with
> dread.  If every suggestion that might shrink the code a bit were
> adopted,
> we would have a language as repulsive as Perl.  It isn't that the
> suggestions are necessarily bad individually.  The problem is the
> mindset -- evidentally widespread -- that one should add things to the
> language
> simply because some programmer somewhere will like it.  This is the
> road to hell.

Agreed.

And this is exactly why I begun this discussion here. I wanted to know 
whether there are more (enough) programmers that will like it, what bad 
side effects it has, and whether it is worth any effort.

If you deny every change just because there always is a programmer who 
will like it, then I'm shure you have the choice between no change and 
a straight way to intercal.

There already were lots of changes in python, some of them even 
breaking old code (an own __future__ mechanism has been introduced do 
deal with it). And there always was a discussion whether it is good(tm) 
or bad(tm).

But I think we should discuss the pro and contra points of the 
proposal. Just doing no change because adopting every change is a 
straight way to hell is shurely the wrong way.

markus
-- 
"The strength of the Constitution lies entirely in the determination of 
each citizen to defend it. Only if every single citizen feels duty 
bound to do his share in this defense are the constitutional rights 
secure." -- Albert Einstein