Ideas for Python 3

[Josiah Carlson]

I've read the link you posted, and I've previously taken a look at

I am currently neutral on the idea of prototypes, still waiting for
anyone to show me a good use case, so I can include it in my webpage.
I still have "cloning" of instances in my proposal, but you will
notice they are at the bottom of the list of benefits at
http://ece.arizona.edu/~edatools/Python/PrototypeSyntax.htm

Considering that you provide an animal heirarchy use-case to illustrate
what you propose, I'd say that you're a bit on the positive side of neutral.

I don't believe I understand the idea of "cloning", at least in terms of
prototypes. In my mind it brings up either using a copy() method on
instances, or using instance1.__dict__.update(instance2.__dict__) to
transfer instance variables. Unless there is more (or an actual)
description about what a "clone" is, I can't say whether it is a benefit
or drawback.

I typically get enthusiastic about something when I first see it, then
I learn a little more, and some of the new tricks/features drop to the
bottom of my list. What remains of my original enthusiasm for Prothon
is still in the unification of methods and functions.

I guess I must be an "Expert", because unifying methods and functions
doesn't seem to be necessary to me. While some (including yourself)
state that it would make learning portions of Python easier, never
having had issues handling lambdas, functions, class methods, static
methods, or instance methods, I don't know what people have issues with.

Really the question is: "Is there a problem with current function,
method, etc., syntax?" If there is a problem, the next question is,
"What are people having problems understanding?" At some point there
would likely be examples provided that show where the user was confused.
Documenting those examples to explain the syntax, I believe, would be
sufficient, but then again, I RTFM.

In terms of instance variables and accessing via .variable, I would
imagine the lack of 'this' (for C++ or Java programmers) or 'self' (for
Python programmers) to be somewhat disconcerting, and though '.' is used
to denote a namespace heirarchy in functions, modules, classes, etc.,
having it lead a an instance variable or function suffers from the same
"punctuation-itis" that is listed as a drawback for various function
definition syntaxes.

For those that I come across who are hung up on the handful of syntaxes
available for functions/methods, I point out that really only two are
generally needed (function(), instance.method()). The others are merely
there to make life easier for 'advanced' users, and if are not labeled
as such, should be (class.method(instance) is pretty useful, as can be
lambda, and are the two 'advanced' function types that I use). By only
introducing the two major syntaxes, whose only difference is the naming
of the referenced instance (for flexibility), I believe the vast
majority of people who had troubles before, would have very few now.

The key to finding what is fundamentally good in these other
languages, and what is just someone's personal preference for being
different, is keeping an open mind. It's astonishing how few people
can do that in comparing computer languages. I guess it is just
easier to be "anti" or "pro" and skip the investigation and thinking.

On that note, I am relatively closed-minded about (even suggested)
alterations to Python because it works so well for me /now/, I'm being
paid to write software with it /now/, of the alterations that are being
offered, I don't believe any would increase my productivity /soon if
ever/, and I find them to be both aesthetically unpleasing, as well as
relying on the assumption that people don't /currently/ understand Python.

I believe that the current learning curve of Python is sufficiently
gradual as to allow the vast majority of people to use it effectively.
Knowing the ins and outs of the entirety of the language is not
necessary, and even a reasonable subset excludes staticmethods,
metaclasses, etc.

I continue to find new surprises in Python. The ability to change
classes into prototypes by using descriptors is the latest exammple.
This seems like a drastic change, but it is all within the capability
of Python.

Being able to use prototypes, without prototype syntax, is not changing
the language syntax. The fact that Python doesn't need prototype syntax
to have prototypes, I believe, is an argument against altering Python's
syntax.

Prothon does have some changes that are more drastic, but in my
opinion have no real benefit over Python. I measure drastic by how
much effort it will take to translate existing Python programs to
Prothon. By this measure, the unification of functions and methods is
not a drastic change. I believe it will be possible to automatically
translate all Python methods into the new form. So if we categorize
syntax changes as ( Compatible / Migratable / Totally Different ), the
proposed changes are in the middle.

Function/method unification is certainly migratable, I've never claimed
otherwise. In fact, with a good refactoring tool, it is trivial (and
actually a search+replace will go a long ways towards migrating). The
'.' prefix "punctuation-itis" I described earlier, coupled with your
statement that __self__ is magical (more or less so doesn't matter
much), suggests that together, they are trying to replace an easy to
understand magic, with another easy to understand magic. The only
/real/ change that the function unification is advocating, is the
replacement of an explicit name for something that is passed implicitly,
with an implicit name for something that is passed implicitly, and the
replacement of an explicit instance name with no name at all. Which is
better is debatable, but I prefer the current Python syntax, due to the
reduced number of implicit items (only the instance is implicit, as
compared with the instance, name, and instance references in prototype
syntax).

- Josiah

 

[David MacQuigg]

Considering that you provide an animal heirarchy use-case to illustrate
what you propose, I'd say that you're a bit on the positive side of neutral.

The animal hierarchy is intended as a vehicle to demonstrate *all* the
features of the proposal. The "with" statement, and the ability to
"clone" instances are actually outside of that hierarchy, and are
easily separable. Taking them out won't hurt the main part of the
proposal, and I probably should do that on the next revision, just to
avoid having the whole proposal valued on a feature that can't be
justified. On the other hand, maybe I should leave these in as
"throw-aways", so if the proposal ever does get near implementation,
they can cut these features instead of something important. :>)

I don't believe I understand the idea of "cloning", at least in terms of
prototypes. In my mind it brings up either using a copy() method on
instances, or using instance1.__dict__.update(instance2.__dict__) to
transfer instance variables. Unless there is more (or an actual)
description about what a "clone" is, I can't say whether it is a benefit
or drawback.

It's real hard to get a clear statement from the prototype advocates,
but my understanding is that they want to eliminate all classes, and
just make instances, one from another by "cloning". Cloning is
different than instantiation in Python, because all attributes are
copied to the clone. This means you cannot change an ancestor's
attribute and have it change for all descendents that don't explicitly
over-ride that attribute. This lack of an active "inheritance"
mechanism seems like a major disadvantage to me. Presumably there is
some counterbalancing advantage, but I have not been able to figure
that out.

I guess I must be an "Expert", because unifying methods and functions
doesn't seem to be necessary to me. While some (including yourself)
state that it would make learning portions of Python easier, never
having had issues handling lambdas, functions, class methods, static
methods, or instance methods, I don't know what people have issues with.

Really the question is: "Is there a problem with current function,
method, etc., syntax?" If there is a problem, the next question is,
"What are people having problems understanding?" At some point there
would likely be examples provided that show where the user was confused.
Documenting those examples to explain the syntax, I believe, would be
sufficient, but then again, I RTFM.

I've never been able to convince anyone based on an isolated example.
The problem is that even if I show something with a benefit as obvious
as the elimination of special syntax for a static method, the counter
is either static methods are simple, or you don't need them.

Take a look at the 96 pages devoted to OOP in Learning Python, 2nd ed.
This is generally considered the best introductory text on Python, and
it looks to me like it includes the right choice of topics, and is
well written. Then take a look at
http://ece.arizona.edu/~edatools/Python/Prototypes.doc In 8 1/2
pages, I provide a basic introduction to everything students will need
to write class hierarchies, work with bound and unbound functions, and
write programs that in Python would require static methods. If I were
to add some additional topics, examples and exercises, I think this
presentation would expand to 40 or 50 pages. This is something I
could usefully teach in 4 hours of the student's time ( lecture,
reading, and practice ).

The key to making this work is to build on of what the students
already know ( functions, modules, and global variables ). With the
unification I am proposing, there is almost nothing to learn in going
from modules to classes. It's just a different way to package data
and functions.

I could probably do almost the same in Python by ignoring all but the
most common method form. The problem is that ignoring these other
forms is not the same as ignoring metaclasses. The student is
unlikely to encounter a need for metaclasses, but the need for static
methods arises naturally. At least it seems natural to me, having not
been conditioned to avoid them. Not being able to call function from
a class without a special first argument, seems to me like not being
able to have the letter 'q' in a variable name.

There is extensive discussion of this topic on the thread "Unification
of Methods and Functions", including some examples of how to write
classes which avoid the need for static methods. So far, I have not
seen anything that is better as an introduction to OOP than my
original example. You might want to join in that discussion, if you
can add something to our understanding.

In terms of instance variables and accessing via .variable, I would
imagine the lack of 'this' (for C++ or Java programmers) or 'self' (for
Python programmers) to be somewhat disconcerting, and though '.' is used
to denote a namespace heirarchy in functions, modules, classes, etc.,
having it lead a an instance variable or function suffers from the same
"punctuation-itis" that is listed as a drawback for various function
definition syntaxes.

The issue is not .var vs self.var vs $var or any other variant. They
are all equally explicit, and everyone will have a different opinion
as to which is ugly or pretty. The issue is the different argument
sequences. To unify all forms of functions and methods, we need to
get 'self' out of the argument list. I know this seems like a trivial
change, but take a look at how many pages in Learning Python are
devoted to the different function and method forms.

For those that I come across who are hung up on the handful of syntaxes
available for functions/methods, I point out that really only two are
generally needed (function(), instance.method()). The others are merely
there to make life easier for 'advanced' users, and if are not labeled
as such, should be (class.method(instance) is pretty useful, as can be
lambda, and are the two 'advanced' function types that I use). By only
introducing the two major syntaxes, whose only difference is the naming
of the referenced instance (for flexibility), I believe the vast
majority of people who had troubles before, would have very few now.

If you can show me that static methods are not necessary, please join
the discussion under "Unification of Methods and Functions". We have
a fairly simple problem, an animal hierarchy, and some fairly simple
requirements. These are stated as an exercise at
http://ece.arizona.edu/~edatools/Python/Exercises/

On that note, I am relatively closed-minded about (even suggested)
alterations to Python because it works so well for me /now/, I'm being
paid to write software with it /now/, of the alterations that are being
offered, I don't believe any would increase my productivity /soon if
ever/, and I find them to be both aesthetically unpleasing, as well as
relying on the assumption that people don't /currently/ understand Python.

What I am proposing will be of no benefit to advanced users. But it
won't be a problem for them either. I would expect an advanced user
to learn the new simpler syntax in about five minutes. As for the
aesthetics, I would trust GvR to make a good choice, and after using
the new syntax for a while it will look just right.

What I like about GvR is that in spite of his genius, he can still
show concern for something as simple as the problem beginners have
with dividing two integers. That problem doesn't bother me or anyone
I know, but I like the fact that he fixed it.

I believe that the current learning curve of Python is sufficiently
gradual as to allow the vast majority of people to use it effectively.
Knowing the ins and outs of the entirety of the language is not
necessary, and even a reasonable subset excludes staticmethods,
metaclasses, etc.

Take a look at the link above for a simple problem that uses static
methods. The lack of static methods would seriously cramp my style.

Being able to use prototypes, without prototype syntax, is not changing
the language syntax. The fact that Python doesn't need prototype syntax
to have prototypes, I believe, is an argument against altering Python's
syntax.

It's an argument agains making prototypes ( 'with' statements and
cloning ) part of the core. It's irrelevant to the more important
parts of the proposal.

Function/method unification is certainly migratable, I've never claimed
otherwise. In fact, with a good refactoring tool, it is trivial (and
actually a search+replace will go a long ways towards migrating). The
'.' prefix "punctuation-itis" I described earlier, coupled with your
statement that __self__ is magical (more or less so doesn't matter
much), suggests that together, they are trying to replace an easy to
understand magic, with another easy to understand magic. The only
/real/ change that the function unification is advocating, is the
replacement of an explicit name for something that is passed implicitly,
with an implicit name for something that is passed implicitly, and the
replacement of an explicit instance name with no name at all. Which is
better is debatable, but I prefer the current Python syntax, due to the
reduced number of implicit items (only the instance is implicit, as
compared with the instance, name, and instance references in prototype
syntax).

Again, I'm not getting into the 'self' debate. The real issue is
unification. If that were to require putting 'self' into *all*
calling sequences, whether it was needed or not, that would be
preferrable to the current mess.

-- Dave