Michael Tobis <[EMAIL PROTECTED]> wrote: ... > .x = 1 > .def foo(): > . if False: > . global x > . x = 2 > .foo() > .print x > > prints "1"
Wrong: >>> x = 1 >>> def foo(): ... if False: ... global x ... x = 2 ... >>> foo() >>> print x 2 And indeed, that IS the problem. > Pythonistas appear to be averse to any declarations (in the sense of > compiler directives) besides "global". Many of us consider ``global'' a nasty wart, too. > Anyway, it's this sort of reference-modifier that's at issue here, You can play with references as much as you like, as long as they're *COMPOUND* names (attributes, or even, if you with, items). Just leave *BARE* names alone, and nobody will jump all over you. > It's not difficult for me to imagine at least two other things I'd want > to do with references: 1) make them immutable (making life easier for > the compiler) 2) make them refer only to objects with certain > properties (strong duck-typing). Look at Enthought's ``Traits'' for some highly developed infrastructure along these lines -- for *COMPOUND* names only, of course. No ``making life easier for the compiler'', but for example ease of generation of forms and other view/controller implementations from a model, etc. If you're keen to hack on the compiler to take advantage of such information for code generation purposes, your experimentation will be easier once the AST branch is folded back into the 2.5 CVS head; if it's not about code generation but just runtime (so not really about the compiler but rather about the virtual machine), pypy (see codespeak.net) may help you similarly, already today. If you're not keen to hack, experiment, and prove that dramatic speedups can be obtained this way, then I doubt that musing about ``helping the compiler'' in a purely theoretical way is gonna do any good whatsoever. > On the other hand, I think compiler writers are too attached to > cleverly divining the intention of the programmer. Much of the effort > of the compiler could be obviated by judicious use of declarations and > other hints in cases where they matter. Correct code could always be Ah, somebody who's never hacked on C compilers during the transition from when ``judicious use of 'register' '' (surely a classic example of such an "other hint") was SO crucial, to where it doesn't matter in the least -- except that it's an ugly wart, and the clutter stays. Used to be that C compilers didn't do register allocation with any skill nor finesse, but did let you give a hint by using "register" as the storage class of a variable. Smart programmers studied the generated machine code on a few architectures of interest, placed "register" appropriately, studied what changes this made to the generated code, and didn't forget to check on all different machines of interest. Most C programmers just slapped "register" where they GUESSED it would help, and in far too many cases they were horribly wrong, because intuition is no good guide to performance improvement; I have witnessed examples of code where on certain machine/compiler combinations inserting a "#define register auto" to disable the GD ``register'' made some functions measurably FASTER. Then "graph-coloring" register allocators came into their own and in the space of a few years ``register'' blissfully became just about irrelevant; nowadays, I believe all extant compilers simply ignore it, at least in suitable optimization mode. Of course, for backwards compatibility, "register" remains in the language: total, absolute, absurd deadweight -- one extra little difficulty in learning the language that has absolutely no reason to exist, gives zero added value, just clutters things up to no purpose whatsoever. So much for the ``judicious'' use of performance hints: it just doesn't happen enough in the real world, to put up with the aggravations until compiler technology has gotten around to making a certain hint irrelevant, and the totally useless conceptual and coding clutter forevermore afterwards. Those who can't learn from history are condemned to repeat it. Maybe some of us just know some history better (perhaps by having lived it) and don't need yet another round of repetition? Optional declarations to ease compiler optimizations were at the heart of Dylan, and looked like a great idea, but Dylan's success surely wasn't such as to enourage a repeat of this ``soft typing'' experiment, was it now? Of course, it's always hard to pinpoint one reason out of a language's many features -- e.g., Dylan had macros, too, maybe THOSE were more of a problem than soft-typing. In theory, I do like the idea of being able to give assertions about issues that a compiler could not reasonably infer (without analyzing the whole program's code, which is another idea that never really panned out for real-life programs as well as one might hope), and having a mode where those assertions get checked at runtime and another where the compiler may, if it wishes, rely on those assertions for code optimization purposes. In practice, having never seen this theoretically nice idea work really WELL in real life, despite it being tried out in a huge number of ways and variations many, MANY times, I'd have to be convinced that a particular incarnation is working well by seeing it make a truly impressive performance difference in some prototype implementation. AST-branch for the compiler side, and pypy for the runtime side, are developing in good part just in order to ALLOW easy experimentation, by coding only Python (and maybe generating some pyrex, if the point of some idea is making some sparkling machinecode). Intuitions about performance are far too often completely off the mark: performance effects just NEED to be shown as working well in practice, before any credence can be put into reasoning that this, that or the other tweak "should" speed things up wondrously. > socks off yet again, but I can't see counting on it. So the successor > to Fortran (presuming it isn't C++, which I do presume) may be > influenced by Python, but probably it won't be Python. You appear to assume that Fortran is dead, or dying, or is gonna die soon. I assume Mr. Beliavski will do a great job of jumping on you for this, so I can save the effort of doing do myself;-). Alex -- http://mail.python.org/mailman/listinfo/python-list
