RE: [Zope] Zope needs this (and Dynamo has it)
From: 'Martijn Faassen' [mailto:faassen@vet.uu.nl] Sent: Thursday, March 09, 2000 1:15 PM To: Zope Mailing List (E-mail) Subject: Re: [Zope] Zope needs this (and Dynamo has it)
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).
True enough, though I'd have liked to see more, and I'd have liked to contribute more, too, which is to say, I'd like to contribute at *all* -- no time for that at the moment, however. Ironically, I'm too busy using it to improve it. I find it ironic that JPython is even *slower* than CPython. Curious -- is anybody using it for anything worthwhile?
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.
I'm not disputing the success of these languages. Perl, Python, PHP, Pike -- they're all quite successful at what they aim to be (*). But people tend to use languages rather than contributing to their development. You can't just evolve a language indiscriminantly, which is why we have Guido and Larry, the benevolent dictators. You can't just go, "oh, and I added iterated loops today". Every damn little feature requires at least some kind of ratification process. Languages are much more susceptible to breaking. (*) Except possibly Pike. I'm ashamed to say it, but I find myself oddly attracted to this language, if mostly because of its speed and interesting resemblance to C. Pike is a good example of "how to make a powerful language/interpreter system that's also very fast". Pike has had a type system from the outset, which is a definite edge over Python.
[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).
Where? The type system SIG has a funny intro: "Recently, the types SIG has come under attack for inactivity, and in response Paul Prescod has offered to guide the SIG towards accomplishing a single specific goal: to develop an optional static typing system for Python. The December 1999 archives of the SIG show the discussion that lead to this decision." Reading this stuff now. It's interesting. I hope they get it right. Maybe I'll chip in. What's interesting about Dylan is that, because it relies on static information such as type hints and class/method relationships to be efficient, the developers of Functional Developer (formely Harlequin Dylan) are facing a design problem related to how they compile programs. They've actually put all of the various libraries into shared DLLs. Unfortunately, this means they lose the benefits of the optimizations that can be made through the use of static compiler information. When you load up the [latest beta of the] Developer IDE and compile a program, it consumes a whopping 45MB of RAM. And it's damn slow. The absence of such optimizations is one reason for this hogging tendency. So they're planning on providing a "whole program delivery" option whereby all libraries would be statically linked.
[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.
I have several apps where I would rather use Python, but where speed is so significant that I would either end up writing a lot of the code in C++ for speed (which is painful due to the lack of integration between the two languages -- Python classes can't inherit from stuff in the C++ extension, for example). I also have a database-centric Zope app that causing me headache. The ZODB is *way* too immature to replace a database right now -- fine for the kind of stuff that runs on zope.org, not for us. ream
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
_______________________________________________ Zope maillist - Zope@zope.org http://lists.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope-dev )
Alexander Staubo wrote: [snip]
I find it ironic that JPython is even *slower* than CPython. Curious -- is anybody using it for anything worthwhile?
I think I heard somewhere that it's now equal in speed to CPython, but I'm not sure. People use it to script Java components and such. It seems to be reasonably popular for things like that in Java-land. [snip explanation why open-source like collaboration is harder for languages] It's hard for language *design*, yes, but it's less hard when you're doing language implementation (for instance a faster one), and it's easier still when you're writing libraries and such. And it does happen for language design as well -- the Python static type design is currently being fleshed out (in bursts) by the types-SIG (though of course Guido does final approval about what goes into Python proper). [type system prototypes for Python]
Where?
Hm, I'm not entirely sure how to find it other than digging through the types-SIG mailing list. Try something mid-january.
The type system SIG has a funny intro: "Recently, the types SIG has come under attack for inactivity, and in response Paul Prescod has offered to guide the SIG towards accomplishing a single specific goal: to develop an optional static typing system for Python. The December 1999 archives of the SIG show the discussion that lead to this decision."
Reading this stuff now. It's interesting. I hope they get it right. Maybe I'll chip in.
You'll find some of my silly messages too. :) The types SIG came quite a long way after Guido proposed closing it down for inactivity. It's a bit more quiet now, I believe. [snip discussion on Dylan] [snip]
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.
I have several apps where I would rather use Python, but where speed is so significant that I would either end up writing a lot of the code in C++ for speed (which is painful due to the lack of integration between the two languages -- Python classes can't inherit from stuff in the C++ extension, for example).
There are various tools out there for Python which do offer this kind of functionality, though, I think? Check at the vaults of parnassus sometime: http://www.vex.net/parnassus
I also have a database-centric Zope app that causing me headache. The ZODB is *way* too immature to replace a database right now -- fine for the kind of stuff that runs on zope.org, not for us. ream
Why not use a relational database? Is it too immature that way? Regards, Martijn
participants (2)
-
'Martijn Faassen' -
Alexander Staubo