Python evolution: Unease
hpk at trillke.net
Tue Jan 4 17:08:38 EST 2005
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
b) do you have some concise definition of what you mean
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
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,
More information about the Python-list