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 -- http://mail.python.org/mailman/listinfo/python-list
