On Sat, Jan 3, 2009 at 15:12, Armin Rigo <[email protected]> wrote: > Hi,
> Your writing style is too annoying to answer properly :-( Sorry for that, I don't usually do it. I'm trying to do advocacy of my position, but sometimes I realize there's a subtle boundary with flaming; and most of that flaming is actually addressed to CPython developers. > I will not try to answer all of the points you mention; > instead, let's just point out (as others have done) that > the picture is more complex that you suppose, because it > includes a lot of aspects that you completely ignore. Tradeoffs are always involved, but in lots of cases, in the Python community, misaddressed concerns about simplicity of the Python VM, and ignorance of literature on Virtual Machines, lead to mistakes. And I think we mostly agree on the facts underlying this statement, even if we express that with different harshness. I don't claim to be an expert of VM development, not at all. But since there is a big disagreement between what I learned during 3 months of lessons (which was a first course on VM development) and CPython, either one is wrong; my professor suggests that the Python side is wrong and that implementers of Smalltalk, Self, and other languages have some point. And all the evidence I could find (including your project) agrees with that, on topics like: - threading in the interpreter - garbage collection vs reference counting - tagged pointers - hidden classes (i.e. V8 maps, which mostly date back to the early '90s). If anybody is interested, this is the homepage of the course, with the needed references (most of the links to papers are not directly accessible, but the papers can be downloaded from other sources): http://www.daimi.au.dk/~amoeller/VM/ == __DEL__ SEMANTICS === > I > know definitely that with changes to the semantics of the > language, Python could be made seriously faster. > PyPy is > not about this; it's a collection of people who either > don't care too much about performance, or believe that > even with these semantics Python *can* be made seriously > fast -- it's just harder, but not impossible. Just to make sure: I don't advocate changing semantics which have value for the programmer; I advocate changing semantics when they have problems anyway, like for this case, or for the int/long distinction, which created problems both for tagged integers and for implementers. Those two posts pointed out by Carl are interesting: http://morepypy.blogspot.com/2008/02/python-finalizers-semantics-part-1.html http://morepypy.blogspot.com/2008/02/python-finalizers-semantics-part-2.html I'm interested about the costs of guaranteeing destructor calls in topological order, I might reconsider my position on that particular point; however, "topological-order-unless-a-cycle-is-found" is IMHO a worse semantics than "no-topological-order", and that's what actually matters, because it complicates implementation without being easier to use correctly, because using fields requires proving that the object cannot be part of a cycle, and that requires in turn an analysis of the internals of other objects; this shouldn't be required to the programmer since data hiding mostly forbids relying on this. It would maybe be more useful to implement "reverse topological order" and to clear all pointers to children of an object, to make sure that nobody tries to rely on undefined behaviour, at least for Java, but maybe also for Python. === SUMMARY === So, the full Python semantics (i.e. __del__ is like a C++ destructor) are surely easier to use than Java/.NET finalizers, and are safe, because one cannot get NULL pointers; but they have for the huge problem of memory leaks; I'm undecided about "topological-order-unless-a-cycle-is-found"; Java finalizers are something that nobody should use; Python weakrefs still allow resurrection, which causes slowdown as documented by Boehm; Java weakrefs involve a fair amount of boilerplate code and they also require the programmer to decide where the reference queue should be polled, but at least they are quite difficult (if not impossible) to misuse. Regards -- Paolo Giarrusso _______________________________________________ [email protected] http://codespeak.net/mailman/listinfo/pypy-dev
