The perfect Python

[Martijn Faassen]

Even though some other poster said yawn, I'll help with the 500 post
meandering thread with some comments and pointers.

"Jean-Fran?ois M?nard" <jeanfrancoismenard at msn.com> wrote:
[snip nice intro]
> I understand that backward compatibility is important too, but the latests
> extensions to Python begin to seem locked by past decisions.  I don't like
> this tendency to __this__ and __that__ everything.

> We loose in readability,
> accessibility and clarity, in my opinion...

Actually I find the __foo__ pattern helps with readability. Whenever an
object is doing something special it looks special. Stands out clearly, so
I disagree there. I must say initially coming from C++ where __ sort of 
implies 'voodoo implementation name mangling details' this did initially
strike me as odd, but once I got used to it I came to appreciate it a lot.

> The Perfect Python (c):
> 
> What is missing ?  Well, I'm not a language designer, but I can say what *I*
> miss.
> 
>    - Interfaces.  Behavior checking is not enough.

I think (from your code sample below) we already have such a thing,
without special syntax. Take a look here for the recent code (download
tarball at the bottom):

http://cvs.zope.org/Zope3/lib/python/Interface/

and for examples of its use look for IFoo.py style files in the Zope 3
sources, to be found here:

http://cvs.zope.org/Zope3

>    - Private and Public scopes.  Explicitly.  No more __name_mangling

Isn't __ explicit enough? It can be debated of course, but _ gives clear
intention of the programmer that it should be treated as private. No 
no name mangling is involved; usually I prefer this pattern as the name mangling
can get in the way if I *do* want to do something I know is dangerous.

It's less typing than the explicit 'public/private' specifications, and seems
to do enough. It's not hard to learn or recognize. Not so bad overall;
how would adding explicit scopes help?

Note that with interfaces there's a notion of what methods are really public 
as well; they're on the interface.

>    - Design by contract. Pre and Post conditions.  Could save hours of
> debugging.

Did you try unit testing? It's not exactly the same, but you can do 
similar things.

>    - Block comments.  """ """ should be for documentation.

What's wrong with repeating #? I find that easy enough whenever I want a
block comment, which isn't that often (at least not more than a few lines).
'#' is for 'how' and docstring are for 'what'; my code doesn't have a lot of
long texts on the how.

>    - Class variables.

Don't we already have them? What should these do?

>    - A cleaner Property declaration.  No separate _variable. Saw too many
> newbie posts about that.

Looking at the sample code down there it seems you're getting an attribute
from nowhere with the same name as the property itself. Very confusing!
And often enough with properties there *is* no _variable; this is just one
way to implement the property.

>    - No more self in functions declarations.  In OOP, this *can* be
> implicit. (I know, this is controversial stuff)

No big opinion about this. The explicitness of 'self' is sometimes 
useful, though (as in 'self, other', as well as some ways to hang functions
off classes during runtime).

[snip]
> public interface MyInterface implements (OtherInterface1, OtherInterface2):
>    """ Comments """
>    private PrivateClassVariable

Privacy on an interface? Doesn't make much sense to me.

[snip]

[snip /* .. */ comment..ick, lots of # is easier to recognize and far less
ugly]
>    public property MyProperty:
>        """ Comments """
>        get():
>            """ Comments """
>            return self.MyProperty
>        set(newValue):
>            """ Comments """
>            self.MyProperty = newValue

As I said before, this one seems extremely confusing. How does the system
know this doesn't lead to recursion? You could come up with some rule about
this involving 'if the getter/setter access an attribute with the same 
name as the property they're working for then don't use it as a property but
as an attribute', but that doesn't help. :)

>    private propertyCall():
>        """ Uniform call """
>        return self.MyProperty
> 
>    private propertySet(newValue):
>        """ Uniform call """
>        self.MyProperty = "new value"

I guess these are __special__ methods without the __. They're much easier
to recognize *with* the __..

[snip pre/post conditions]

> I have no idea how this could be implemented.  Maybe a PerfectPython
> interpretor could be developped on top of the standard interpretor?
> 
> Any comments?  Anybody interested to start the project? ;)

Overall I think the look of this code is rather more verbose than current
Python code and doesn't add that much in features or clarity to make this 
extra verbosity worth it to me. So I'll have to pass this one. :)

Regards,

Martijn
-- 
History of the 20th Century: WW1, WW2, WW3?
No, WWW -- Could we be going in the right direction?