The perfect Python

[Jean-François Ménard]

Tanks for the reply Martijn!

The points I made in my primary post were in regard to medium to larges
projects.
For smalls ones, I agree that Python, in his present state, is quite usable.
But, past a certain point, I found it harder and harder to maintain.

> > 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.

I agree with you that __foo__ stands out clearly. But, as I said, as Python
evolve it seems to have more and more of these __things__, and they loose
their dinstinctivity. That's why I think that some of them, if not all of
them, should go away.
I also have the feeling that some of them where created to avoid a new
keyword (backward compatibility...). More on this later.
I think that, on a short term, it seems a good strategy. But on a long term,
it will hurt python simplicity and accessibility.
>
> > 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
>
I know about this. And that's my point.
Look at this code:
*************
from Interface import Base
class Hello(Base):
""" The Hello interface provides greetings. """
def hello(self, name):
""" Say hello to the name """
class HelloComponent:
__implements__ = Hello
*********
Is it obvious to you that Hello is an interface? Not to me. Why? Because, to
avoid a new keyword, the keyword "class" is used instead of "interface".
It's an interface, not a class, no? It feels like a hack to me.
And you see this __implement__ variable? Why? The class "implements" this
interface, doesn't it?
Let me ask you otherwise. If python didn't exist, and you'd design it's
syntax from scratch, would you choose this syntax? If so, why classes
declarations don't look like:
*********
Class Hello:
__inherit__ = BaseClass
__implements__ = Hello
*********
See what I mean?

> > - 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.
>
About the interface thing, I agree with you. But what if the class don't
implement any ? Do you have to create an interface for each class, only to
determine methods and variables scopes ?
Doesn't sound this bad to mebut I'm asking myself again: Design from
scratch, what would I do?
> > - 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.
>
Yes, I began to use them recently. It's fantastic.
But it's not exactly the same. I'd say: having both wouldn't hurt...
> > - 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.
>
When using a good python editor, repeating # for a large block is not really
a problem. But I wonder, is it a good idea to rely on tools to circumvent
languages shortcomings?
I guess I would also ask it the other way around: why not? :)
> > - Class variables.
>
> Don't we already have them? What should these do?
>
Well, yes, Python have them. :/
> > - 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.
>
I know, it seems confusing. After the post, I wasn't sure anymore about this
one too...
But I still think it's better that having two distincts things: a property
foo and a variable _foo. This way, you can ensure that the property *will*
be accessed via the setter and getter, and cannot be modified directly via
_foo="something".
I guess that if *real* private scope could be used, then the problem would
go away...
> > - 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]
I agree with you. Maybe something else ?...
> > 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. :)
As you note, how to implement this is another question... ;)
>
> > 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 __..
>
No, sorry, I know that these methods names are a little confusing, but they
where just *normals* method to show how to access properties (unified
access). I guess I should had skipped them, it was obvious.
> [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. :)
>
Yes, it's more verbose. But I think that for someone whith no Python
notions, it's more obvious too.
But, it's just my opinion... ;)
Cheers!
Jeff