Ideas for Python 3

[Josiah Carlson]

>>I've read the link you posted, and I've previously taken a look at 
>>Prothon.  Prototype syntax does not suit my taste in programming 
>>languages.  If Python 3.0 becomes Prothon, I'll fork the most recent 
>>Python 2.x codebase that I prefer, maintaining it myself if necessary.
>>
>>Just as my anti-prototype perspective colors my opinions on what is 
>>reasonable, I would imagine that your pro-prototype perspective colors 
>>yours.
> 
> 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 would also expect that someone who enjoys using lisp or 
>>perhaps SML would have their opinion on what is reasonable, colored by 
>>their preferences.  Considering that Python is not a prototype-based 
>>language today in 2.3 (or the forthcoming 2.4 in the fall), having it 
>>become one in Python 3 would be quite a drastic change, quite literally 
>>like going from Python 2.3 to Prothon.
> 
> 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