Python evolution: Unease

holger krekel hpk at trillke.net
Tue Jan 4 17:08:38 EST 2005


Hi Roman, 

On Wed, Jan 05, 2005 at 00:44 +0300, Roman Suzi wrote:
> Python could have honest support of concepts. Everything else will be
> available with them.
> 
> That is the whole point that Python supports GP. It is only one step
> to do concepts right (and GvR it seems want type-checking into Python 3.0
> anyway), so support for concepts/concept checking is very logical,
> isn't it?

As an innocent by-dropper into this thread: 

a) do you know Armin Rigo's "semantic model" page dealing 
   with concepts? 

   http://arigo.tunes.org/semantic_models.html

b) do you have some concise definition of what you mean 
   by "concept"? 

Myself, i appreciate the combination of testing and python's 
flexibility so much that i don't long for type declarations, 
at least not to the degree that would warrant syntax additions. 

Now for interfaces, for me this references more a documentation issue
than a syntax one: I'd like to have a full-featured runtime browser 
that allows to quickly navigate cross-referenced life python objects. 
Back and forth in execution time, preferably.  This probably requires 
the interpreter to help, track and record more information (which is one 
of the possibilities with PyPy).  It doesn't neccessarily require any new 
syntax though.  

And I don't really see the point of adding interface
hierarchies to already large frameworks.  To me this adds to -
what i call - "naming complexity", i.e. the number of names a
programmer needs to remember to deal with a library or
framework.  For me, it's not really the syntax that is the
problem with interfaces in Zope3 or twisted, but the sheer
amount of names (each indicating certain concepts and
behaviours) i am confronted with.  

Not sure why i am saying all this here 
but have fun, 

    holger



More information about the Python-list mailing list