[Zope] Zope needs this (and Dynamo has it)

['Martijn Faassen']

Alexander Staubo wrote:
> > From: Martijn Faassen [mailto:faassen@vet.uu.nl]
[I list a number of projects about improving Python]

> People are indeed working on Python, but not to the extent of more
> popular projects like Linux or even, I believe, Perl.

I don't know enough about Perl to judge this, but to me, there's
plenty of activity out there. Of course there could always be more,
but lots is happening.. We have _three_ independent implementations of
Python, for instance (Python, JPython and Vyper, and then there are
projects like Python2C).

> Compiler/language projects have, historically, not thrived in the
> collaborative world of open source software -- for very specific reasons
> inherent in the concept itself of languages and compilers. Still, I'm
> very impressed with the evolution of next-gen GCC (formerly EGCS).

Sure, it's not easy to do. I would debate that compiler/languages have
not thrived in the open source world, though. There seem to be
quite a few successful open source languages around.

[assessment of Vyper with which I agree]

> Anyway, while I have not been monitoring the Python type/interface SIG,
> it seems to be moving quite slowly.

That's the nature of discussion lists, almost. There are some prototype
implementations of type-checking systems for Python, though (I think
two or three independent ones, in fact).

[Python people say speed is generally not the problem]
> > It is _less_ of a problem, but most Pythoneers are indeed 
> > interested in
> > speeding of the language. I haven't heard of zealots who want to hold
> > back speedups, as long as it doesn't do away with the power.
> 
> I'm not saying they're holding back, but rather they're dismissing speed
> and scalability as being a problem. I firmly believe that speed is
> Python's number of problem today, and it's keeping Python from being
> used in more applications.

Hm, but in my experience Python has been shown to be plenty fast enough
for the majority of applications. You're probably right though, and I
agree completely that a faster Python would be very nice.

> Python has plenty of problems, but they're tiny by comparison and imho
> they're mostly artifacts of Python's currently somewhat anemic syntax
> (eg., only two kinds of loops, no "switch", no protected members, no
> constants, no syntax for declaring mutability).

I suggest you go discuss these things on comp.lang.python. :)

I don't miss switch. Functions are first class objects, and dictionaries
can be used instead of switch when necessary. Also, good object oriented
design tends to kill switch statements anyway.

I think the two loops are fine, though it would be nice to have the
current constructs to know about iterators. I believe Guido is
taking that into consideration. Also there's the list-comprehension
proposal which may help here. 

I don't think you'll see protected members any time soon.

I'm not sure what you mean with syntax for declaring mutability, though
it sounds interesting.

> Imho Python's second big problem is what you might call, in lack of a
> better term (I'm not wearing my compiler-writer hat right now, sorry),
> contractual semantics -- anything from static typing (pass a string to a
> function that takes an int and you get either a compilation error or an
> exception) to interfaces (the ability to enforce semantic compatibility)
> to design-by-contract constructs.

The types-sig is reaching consensus about optional static typing and
Guido does want to include that into the language in the future (beginnings
in 1.7, full implementation in Python 3000 aka Python 2). Interfaces are
being considered too, and Jim Fulton in fact has an interfaces proposal
out there (that may get used in Zope's code base).

I think using a unit testing framework can substitute for design by 
constract constructs myself.

[snip]
> > It'll be pretty difficult to make a beast like Zope exploit 
> > type-hints, though, I think.
> 
> I disagree, but there's only one way to find out -- implement it (or
> simulate it very carefully).

Okay.

[snip code generator extension idea]

Something like that would definitely be neat. The hard part would be
in the translation process, of course. The other part is in the
interfacing with regular Python; do you allow your translated function
to refer to other Python objects? If you do, you're opening a can of
worms. If you don't, then it starts to look like the 'Swallow' subset
of Python I proposed once; a strict subset of Python with added full type
annotations, which is translatable into C or native machine code.

> It would be an interim solution for certain CPU-intensive modules, in
> anticipation of such built-in functionality in CPython itself. Possibly.

If you're starting such a project I want to hear more about it!

[snip]
> > All true. Anyway, the only thing you're wrong about is that 
> > Pythoneers aren't
> > interested in improving performance. They are, but I grant 
> > you they're not
> > performance nuts like users of C or C++. :)
> 
> Well, I guess they're too busy arguing about whether Python should allow
> assignments as expressions so you could do "while line = f.readline():".
> ;-)

Not to mention indentation! Anyway, the people who keep bringing these
things up don't tend to be the Python nuts (mostly they're the newbies).

Regards,

Martijn