The perfect Python

[Max M]

Martijn Faassen wrote:

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

A more direct discussion about the implementation can be found here:
http://www.zope.org/Wikis/Interfaces/InterfaceUserDocumentation


And as far as strict enforcment of the interface there is:
http://www.lemburg.com/files/python/mxProxy.html

# first, create a 'factory' that accepts a class and a list of names
# in the interface.

FooFactory = Proxy.ProxyFactory(Foo,('aMethod','bMethod'))

# now, instances of FooFactory will be protected:

foo = FooFactory()

foo.aMethod()   # this will work
foo.bMethod()   # this will also work
foo.cMethod()   # this will raise a Proxy.AccessError


>>   - Private and Public scopes.  Explicitly.  No more __name_mangling
> 
> 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?


I usually do:

def doSomethingWithPrivate(self):
     name = self.__name
     if name:
         return '<b>%s</b>' % name
     return ''

instead of:

def doSomethingWithPrivate(self):
     if self.__name:
         return '<b>%s</b>' % self.__name
     return ''

When the __ is repeated to many time. Naturally this is to short and 
stupid an example. But rebinding the __name to a more sensible name in 
the method makes a lot of sense.

You save the dictionary lookup every time it is used, you loose the 
"self." and you loose the '__' ... all good things


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


Unit testing is better. But you can at least have pre and postconditions 
by using assert in the beginning and end of your methods.


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

Don't agree. Multiline comments are fine.


Python is so plastic and flexible that you can do in code what in other 
languages would recquire new features.

regards Max M