Self Nanny

[Lloyd Zusman]

Mark Hathaway <hathawa2 at marshall.edu> writes:

> >> Gaetan Corneau <corg at copernic.com> writes:
> >>
> >> [ ... ]
> 
> > Lloyd Zusman wrote:
> >
> > [ ... ]
> 
> Personally, I'd rather not ever have to write 'self' or 'self.anything'.
> It contributes nothing to the code and doesn't describe what I'm trying
> to write. It's extra verbosity without any payoff.
> 
> Was there a problem with doing it the other way around...
> 
>   [ ... examples snipped ... ]
> 
> where the roles are reversed. All object attributes are
> referred to by their names and any class (global) attributes
> are specified by "local.". This would decrease tremendously
> the need to write 'self.' and would still easily allow the
> differentiation of class-wide attributes from object attributes.
>
> Which do you write more of? Object attribute names.
> Why make that the more verbose version?

In Section 9.4 of the official Python tutorial (did you read it?),
Guido says this about his reasons for the explicit 'self':

  There is no shorthand for referencing data attributes (or other
  methods!) from within methods. I find that this actually increases
  the readability of methods: there is no chance of confusing local
  variables and instance variables when glancing through a method.

  Conventionally, the first argument of methods is often called
  self. This is nothing more than a convention: the name self has
  absolutely no special meaning to Python. (Note, however, that by not
  following the convention your code may be less readable by other
  Python programmers, and it is also conceivable that a class browser
  program be written which relies upon such a convention.)

You may disagree with this.  Nonetheless, this expresses Guido's
reasoning (or at least a part of it).  If you haven't done so already,
I suggest you read all the existing Python documentation.

And did you know that Python was first created some 10 years ago?  And
did you know that in the early stages of its development, many people
such as yourself raised the issues that you are now raising?  And did
you know that now, Python is a mature language and that there are
millions of lines of Python code in use in production applications all
over the world?

... and even if somehow this 'self' change ever were to happen in
Python, all the existing production applications would be very
expensive to change in terms of time and money.


> > LZ:
> >
> > Of course #3 can be done (technically speaking).  And in return for it
> > getting done, would you volunteer to donate your personal time to
> > change all the existing lines of Python code in the world that this
> > change would break?
> 
> This is both true and annoying. In our search for better ways to do
> things we keep running into this barrier that languages are written,
> tried and much time & effort put into that trial. Then when someone
> says, "Couldn't we do it better this way?", the answer is, "But, we've
> put so much work into this..."

So tell the truth: do you really think that this 'self' change is so
much of an improvement over the way that Python works today that it
would justify changing 100 percent of all existing Python programs
that contain method definitions?

Also, keep in mind that there indeed have been many many useful and
meaningful "Couldn't we do it better this way?"  discussions about the
implictness or explicitness of 'self' ... they took place maybe 5-10
years ago when Python was still in the design and debate stage of
development.

But since at least a few years ago, you can no longer think of Python
as a "trial" language.  As I mentioned, there are now millions of
lines of Python being used in real, production-grade applications
today.

If there was a new or young language being considered, discussion of a
behavior change like this would be quite useful and quite appropriate.
It's just that you're way too late to expect a such a major,
legacy-code-breaking change in a language which already has so much
existing production-grade code out there.


There is an undocumented and probably unintended behavior of the
Python 'append' method that people have been exploiting in certain
applications.  Recently, it was decided that in the next major release
of Python, this undocumented behavior will no longer work, and that
the 'append' method will then behave only as documented.  This change
will affect some existing Python applications, but many fewer than
would be affected by this suggested 'self' alteration.

And even in the case of this very small change which removes an
*undocumented* behavior of a method, Guido has recently given us a 3-4
month warning so that the small percentage of code which currently
uses this undocumented behavior could be altered.  And even with this,
there are costs involved in existing, production applications, and
some people are requesting that the change to 'append' not be made.

Given the impact of this tiny change to remove an undocumented
behavior of one method, can you imagine how much of a cost (money and
time) there would be in changing to an implicit 'self'?  As I
mentioned above, this change would require 100 percent of all method
definitions to be changed in all existing Python code.


> Somehow there has to be a willingness to put the effort in and then,
> if it's not as perfect as we'd like, throw it away and start with
> another piece of whole cloth.  [ ... ]

That's quite appropriate for a new or very young computer language.
But you're several years and a few millions of lines of production
code too late for Python.

It's very appropriate to "start over" when creating a new language.
For example, Stroustrup did that to C when inventing C++.  Larry Wall
did that when creating Perl.  Guido did that when creating Python.

And I invite you to do that with the new language that *you* could
create to supersede Python.  What's stopping you from doing that?


> [ ... ] Well, perhaps we could write a translator to convert the old
> to the new. That wouldn't take quite as much man-power, would it?

Even the best translator cannot be counted on to work in all cases.
Therefore, even after running an existing program through this
hypothetical translator, significant testing would have to be
performed to make sure that the converted program still works as it's
supposed to.  And for production applications where time and money is
on the line, this testing would be essential.  Hence, even with a code
translator, the greatest amount of expensive testing would have to be
done in those places where the downtime of an application would cost
the most.


> > Or barring that, would you be willing to pay for the time of all the
> > others who would have to do this work?
> 
> Pay? Who paid the first time? Didn't most of the Python code come
> about because people liked the language and just wrote stuff to be
> distributed via the internet for free? O.K. here's a penny. Ya
> satisfied?

The time and money I'm talking about wouldn't be for development
... it would be to compensate all the people who would have to expend
their own time and money to convert current, production Python
applications so that they would once again work once this hypothetical
change would go into effect.  And remember, this change would break
nearly 100 percent of all existing Python programs.

Would you be willing to explain what advantage this proposed change
would give to people already running these existing applications to
justify the large time and money cost of changing all of them?

The only potential advantages that anyone ever mentioned about having
an implicit 'self' are (1) that a certain small subset of new Python
users might find Python a little easier to learn if it handled 'self'
closer to the way that they are used to C++ handling 'this'; and (2)
that a small minority of existing Python coders find the explicit
'self' to be annoying.

Are there other advantages you see to this proposed change that would
justify the huge time and money cost of converting all the existing
Python programs?


> I know you're saying people's time & effort is considerable. All I'm
> saying is there should be ways to move to new better ways of doing
> things without having to face such stiff resistance.

I wholehearedly agree.  We should always move towards better ways of
doing things.  That's one of the main reasons that people invent new
computer languages.  Therefore, as I've suggested before: given that
it's years too late to make such a drastic change in Python, why not
propose a new language that has the better features that you are
suggesting?  I consider that to be a very worthwhile endeavor.


> > This is not an issue about "caring" about C++ programmers.  I am a C++
> > programmer, and literally hundreds of my colleagues over the past
> > decade or so have been C++ programmers.  Many of these people have
> > tried Python.  And *none* of them have ever even made a complaint
> > about the explicit "self" of Python.  You are the first C++ programmer
> > I have encountered who has ever raised this as an issue.  That's one
> > out of hundreds of people.
> 
> Perhaps they are simply more accepting of what is, and don't
> challenge it.  That doesn't mean they haven't thought about it. I'm
> not a C++ programmer, so I don't know either.

Well, perhaps there is a Great Silent Majority of Python users out
there who have been seething with resentment about 'self' having to be
explicit, and who will rise up and revolt to rally behind a leader who
finally raises his or her voice to fight the Python Establishment.

But I doubt it.

... especially given how much this has already been discussed over the
past 5-10 years with the end result being the Python language we see
today.

What is much more likely is that there are some people who would be
willing to participate in the design and development of a new O-O
scripting language which differs from Python and other existing
languages in ways that these people feel are important.  Would you be
willing to be part of that effort?


> > And as I have mentioned in another post, I challenge you to come up
> > any signficant number of people who would be glad to use Python if
> > only it didn't have an explicit "self".
> 
> It's not just about that issue. It's about an effort to move toward
> something better. You're not against that altogether, are you?

As you can tell from reading what I have already written above and
elsewhere, I am not against that at all, and in fact I'm for it.


> > Your arguments have always been clear.  And they are still rather
> > unconvincing.
> >  Lloyd Zusman
> >  ljz at asfast.com
> 
> 
> A closed mind can't even be convinced by the truth or a stick up side
> the head.

Please re-read this post and my others.

I have said this before and I'll say it again: this sort of feature
would be perfectly valid to discuss for a new language, or one that is
still in the design and debate stage of development ... and I
encourage you and others to do just that.  It's just too late to
effect the change in Python, given the amount of expensive work it
would take to re-tool the existing applications that are out there to
accomodate this change, and given the low amount of desire for such a
change among most Python users.

Also, if you somehow think that this is a new and undebated
suggestion, you might want to go back and try to find some of those
earlier debates about the way that Python handles 'self' that took
place 5-10 years ago when at that time it *was* a young language.

-- 
 Lloyd Zusman
 ljz at asfast.com