Interviews With The Creators of Vyper and Stackless 73
Frank writes: "What most programmers probably think of when they talk about 'Python' is the specific implementation sometimes called 'CPython' (because it is implemented in C). However, Python as a language specification has been implemented several times in parallel with the evolution of Guido van Rossum's reference implementation. This article consists of annotated interviews with the creators of two of the non-standard Pythons -- Stackless and Vyper." A pair of interviews to make your head spin with talk of Literate Programming and the odd but neat concept of "continuations."
Re:Have you heard of Ruby? (Score:2)
I feel pretty much the same way. Ruby seems to be a step forward compared to Python in some respects, and a step backward in others. Overall it's a wash, and since Python already works very well for me I don't think I'd gain much by learning Ruby. That doesn't mean, though, that I would discourage anyone who doesn't already have a scripting language under their belt from choosing Ruby over Python. From what I can tell, they would learn better habits from Ruby than from Perl or Tcl.
Re:Continuation Passing Style... (Score:3)
When you have programmed using a functional language (Scheme for me) and used this way
of working it takes a bit to get back to Java/C!
The basic idea for those of you who are confused is to use recursion and get away with not using the stack for the calls. How you might ask... well first of all its easy when you are using a language like Scheme/Lisp which treats functions as first class data members! There is no difference b/w (well almost none) b/w data types and functions, each can be passed into a function and returned!
SO Normally when you make a recursive call you are just pushing down your current data into the stack and when you reach the base case you go back up the stack!
In case of Continuation Passing Style the idea is really very very neat! You basically make a recursive call and pass a function to that will be able to compute the answer with the data it needs! There is no stack. For example (Factorial of course)
(define fac
(lambda (n)
(if (<= n 0) 1
(* n (fac (- n 1)))))
Note you had to keep the info of where you were so you can recurse back doing the multiplications!
This data went into the stack!!! Now if you want to do this without stacks you can use a method that you build each time you go through the loop and so you build the answer on your way!!!
(define fact-cps
(lambda (n fun)
(if (\>= n 1)
(fun 1)
(fact-cps
(+ n -1)
(lambda(z)(fun (* n z))))))
This way of course you just build a formulae that will give you the answer! No stack.
There is a formal algo that you can take any recursive funtion and make it into CPS which is pretty cool till your professor thinks that a scheme interpreter in written in scheme should use CPS!! BUT i digress!! So you can seee that this is really a very powerful idea! It introduces a lot of neat tricks you can do! One of which is hte Y-Combinator... but taht I cant talk about cause i sit in amazement for sometime when i see it:)
Hmmm these are things i think you should sometime learn if you are in the computer world cause most of the time we stick with the real programming issues and dont see some of the cooler things! So this wont make you much money but you will see how sexy some of these ideas really are!! SCHEME RULZ!
Re:Have you heard of Ruby? (Score:1)
Yes, Perl is an extremely popular language. This is because it solves a problem for a lot of people. You can have all of this dispite the fact that its design leaves something to be desired.
Perl is not the end of language evolution and certainly Larry Wall has never claimed that it was. You really shouldn't have that much difficulty accepting this.
Thanks
Bruce
Re:Continuation Passing Style... (Score:1)
Re:Have you heard of Ruby? (Score:1)
Don't let the perl-like variables fool you, they are merely a convenience. If you wish, you can do things such as get a regular expression object and access its features instead of doing things the perl way. In fact the perl way is simply accessing features of the current object...
What about JPYTHON?? (Score:1)
Come on folks, I know there's an anti-Java contingent out there but when you discuss non-C implementations of Python you really shouldn't omit JPython.
Some key differences between JPython and CPython:
Syntax
- JPython has a different interpretation of floating point
literals. CPython doesn't allow 001.1 CPython should be
fixed.
- JPython supports continue in a try clause. CPython
should be fixed - but don't hold your breath.
Standard types, functions and behaviorInterviews on JPython and Python for .NET (Score:2)
Take a look at:
http://gnosis.cx/publish/tech_index.html
How about... (Score:2)
The stage 1 compiler would be a simple distribution of Python source files, and it would be run with the regular CPython installation. That would be used to compile itself into a binary Python compiler.
Why not? Develop Python programs with CPython. When you're done, compile it for speed.
Re:stick to the basics, please (Score:1)
jim
Re:Have you heard of Ruby? (Score:2)
But, since nobody uses Perl, due to its atrocious language design, this doesn't matter. :-)
Seriously, Perl the language has grown a lot since it was first released, and you can find yourself tripping (quite literally) over its roots. But an interesting part of Perl's design is that it's author, Larry Wall, has an academic background in Linguistics rather than CS, and had a pressing need to get something like perl working rather than a prime requirement that everything be perfect at the start.
But today's perl has lexical scoping and closures and many of the nice things people wish other scripting languages had (or had had sooner). Now that Perl6 is really going to happen (since Damian Conway is motivated to get all his language features implemented before the magic spell wears off :-)), I wouldn't be surprised to see a lot of the dubious stuff finally go away.
And there will be much rejoicing. But the claim that Perl's non-CS roots have somehow doomed it to obscurity or uselessness really seems quite far-fetched.
Re:Distributed Python? (Score:1)
Stackless Python only means that the state info for the current thread of execution is not saved on the C stack as you go along, but maintained elsewhere. The best selling point (to us here at CCP [ccpgames.com] at least) is the microthread support this allows, rather than create an operating system thread (and a seperate C stack) for every seperate task, we just allocate tiny Python microthreads, with little or no overhead.
Re:Continuations... in Javascript! (Score:1)
from what i understand, a continuation is a semantic element that allows you to save a place in the future execution of a block of code. the continuation can then be called (with local vars as parameters) at a later point in time.
http://www.tismer.com/research/stackless/spcpap
jim
can someone explain to me.... (Score:2)
Re:continuation history (Score:1)
Well, I'd say that ML is mostly a functional language. You can write code in an imperative style using references, but it gets painful really quickly. In the end it's easier to write functional code, and let ML do all the work of turning it into something imperative, what with it's tail-recursion elimination, automatic replacement of code that has repeated identical recursive calls (eg. to compute the nth fibonacci number, f(n) -> if n
Re:continuation history (Score:1)
Oh, arse. Yeah, I know, I should have used the preview button...
Anyway, as I was saying, to compute the nth fibonacci number,
f(n) -> if n <= 2 then n else f(n-1) + f(n-2)
ML will replace this with either a memoisation technique, or some dynamic programming technique.
Re:Have you heard of Ruby? (Score:2)
And I suppose this is in contrast to the Perl weenies who come into Python articles to bash Python, based on their many many hours spent studying the pros and cons of each? Yeah right. Most Perl folks spend about three minutes looking at Python, notice maybe one thing about the language itself - usually the indentation thing - but mostly just notice that it doesn't look like Perl, and then spend the rest of their lives making the illogical claim that Perl must be better because more people use it.
Python has its weaknesses, which I have gone out of my way to describe in my last post on the subject (a copy of which pretty easy for any non-moron to find on my website), but overall it's a fine language. As with Ruby, and Pike, and several other languages, on technical merit it deserves at least equal consideration to Perl.
Re:can someone explain to me.... (Score:1)
foo = 'This'
def frotz():
foo = 'The other'
def bar():
print foo
def foobar():
foo = 'Yet another'
print foo
def gbar():
global foo
print foo
def bar_kludge(foo = foo):
print foo
bar()
foobar()
gbar()
bar_kludge()
There is now way for a function defined in frotz to see the definition of foo in frotz. The losest you can get is the bar_kludge trick which results in a local variable of bar_kludge named foo that is initialized to the value of the foo in frotz.
Is it all clear as mud now?
continuation history (Score:2)
Continuations are really nice for *formally* defining how languages should behave under forking (with data dependencies among threads), and other wacky control features that may or may not be useful. I've only seen this stuff done rigorously for Lisp-like languages, in the lambda calculus. I doubt it's used at all for imperative languages.
Have you heard of Ruby? (Score:1)
It seems to be a pretty nice language. Nobody here seems to have heard of it. Why? I think it needs a bigger community outside of Japan.
Thanks
Bruce
Hmm...I wonder... (Score:2)
Might the main CPython branch adopt these innovations? Vyper's scoping and functional features, and Stackless' continuations? The article says that Stackless isn't a huge fork--could it get brought back into the trunk?
Just something to ponder.
---
Zardoz has spoken!
Re:Have you heard of Ruby? (Score:1)
Continuations... in something other than Scheme? (Score:1)
Does anyone have an example in something like X86 assember, Pascal, Delphi or even C?
--Mike--
Re:Hmm...I wonder... (Score:2)
Re:continuation history (Score:1)
Re:What about JPYTHON?? (Score:2)
uhm.... Someone please explain this one to me.
Re:Continuation Passing Style... (Score:1)
(define fact
(letrec
((facto
(lambda (n t)
(if (< n 2)
t
(facto (- n 1) (* n t))))))
(lambda (n) (facto n 1))))
Note that by coding in this manner, one is coding tail-recursively--Nothing has to be saved on the stack from one recursive call to the next (in Scheme functions evaluate their arguments before applying the operator so (- n 1) and (* n t) are evaluated before recursion).
I've tried this in Python and got interesting results: A nontail recursive factorial will stack overflow. A tail-recursive implementation still overflows, but after more calls.
Most coders couldn't care less, but then most coders prefer an iterative approach to a recursive one. Which is a bleeding shame, because often recursion is so much cleaner. You can always make it iterative later.
A lot of people who grew up with imperative languages like C, seem to bear a lot of malice towards more functional languages like Python (it's almost first order and pretty functional) or Scheme. I don't really see why. The common whine is that it's the difference between theory and practice. But hey, this is computer science: Theory is practice.
--
Lagos
Re:stick to the basics, please (Score:1)
As for complexity; as long as it's not required where's the harm? Advanced perl melts my brain (around halfway through the camel book) but the advanced features aren't necessarily required to make functional perl code. I'm beginning to get the idea of continuations and am probably going to look at applying the stackless patches to my own customized python tomorrow just to play with it. If I can do it and not break anything, even should I decide not to use new capabilites I won't go to the effort of reverting back to stock unless there's a functionality based reason.
Re:Hmm...I wonder... (Score:1)
It would be nice if the lexical scoping from Vyper went into Python, but it's so much closer to it's implementation language Ocaml than it is to Python, that I think it would alienate many potential Python adopters.
It's a shame that so many programmers, especially those from a more engineering background than a math background, are so hostile to functional programming. Like the man says, it's not the 1970s any more, the amount of clever thinking that's gone into functional programming means you can regularly beat the engineering results from an imperative language, in many fewer lines of code, and less hours of work.
However, Stackless Python is a different matter. The continuation passing is totally transparent to the programmer (unless they want to use it), that it wont have matter to those engineers, and will even please the mathematicians. Microthreads in particular are gorgeous, no engineer would turn their nose up at them, just because of the math background. This is a win for everybody, it's just obviously the way Python should go.
Re:Continuation Passing Style... (Score:1)
Re:Have you heard of Ruby? (Score:1)
Perl gets the job done. It really gets the job done. If that's not the mark of a good language, well, I'll leave you to your language designing.
Re:What about JPYTHON?? (Score:1)
Re:Oh Mr. Moderator please? (Score:1)
deployment issues? (Score:1)
If you start off with the idea that one "significant" tab is equivalent to 4 "significant" spaces, things can turn out differently than you may have thought when the emacs setting of the day happens to be: 1 tab is traded for 5 significant spaces.
The real issues to me, however, are:
(1) Oosterhout says that the inner loops are to be coded in C, while the outer, administrative loops can be done in -Script-. I could have agreed with this idea, as it sounds good, if it were not that integrating C and -Script- becomes a project in itself. I dare you to figure out tools like SWIG, or even to use the python.h files manually. You're in there for some major undertaking. God save the queen!
(2) Now that you're finished SWIGging and re-SWIGging, compiling, re-compiling your libs, scripts, glue code, you can create your deployment package: an atrocious bunch of dlls,
(3) Python depends on a virtual machine, say the pyxxyy.dll, which shares the problems of all shared objects. While Guido was going from v1.52 to v1.6b to v1.6 to v2.0b to v2.0, which is fine, because that improves the system, it had one major drawback: continuous redeployment of almost identical but slightly different virtual machines. You will find that your virtual machine gets updated more rapidly than the applications that depend on it. What's more, virtual machines create a horrendous need for backward compatibility of the APIs, with its trail of deprecated classes, methods, and entire packages. All the cruft will remain there forever, and you will be deploying an everincreasing pile of mostly unneeded dog shit to your users. In my opinion, *virtual machining* is bound to end in tears.
I'm looking for a high-level language, regardless of its syntax that:
(1) understands seemlessly C/C++ header files and the APIs that it exposes. No SWIGgin! (But also, no IDL or stuff like that, just direct invocation!)
(2) grabs its language run-time (virtual machine) (whichever version that you indicate), native methods (.obj files), and your application, uncrufts it (removes every class or method not used) and nicely links it into one, single clean executable (optionally compressed with, for example, UPX).
No shared objects, no \system32 pollution, no dlls, no folders full of
Re:Have you heard of Ruby? (Score:1)
Re:Have you heard of Ruby? (Score:1)
There, idiot moderator, mod this down.
Re:can someone explain to me.... (Score:1)
Re:can someone explain to me.... (Score:1)
foo = 'This'
def frotz():
foo = 'The other'
if 1 :
print foo
if 1 :
foo = 'Yet another'
print foo
if 1 :
global foo
print foo
if 1 :
print foo
frotz()
output:
The other
Yet another
This
This
ICK!!! the global variable clobbers the local from that point on....
Re:Continuations... in Javascript! (Score:1)
Article (Score:3)
Don't believe me? (Score:1)
Ruby Rocks. Forget Perl6. (Score:2)
Ruby really is a great language, and I suspect that by time Perl6 is done, it will resemble Ruby in many ways.
Moving to Ruby now will probably give you everything Perl6 is promising, without the three year wait.
Re:Ruby Rocks. Forget Perl6. (Score:2)
I might do some serious web programming with this.
Thanks
Bruce
Re:Distributed Python? (Score:2)
Likewise, any C-land objects that are pointed to by the state are going to be hard to move. It seems to be the sort of thing you really want to implement at the VM level using Distributed Shared Memory, not at the language level.
But, I expect that anyone smart enough to implement stackless wouldn't go around saying these sorts of things if he didn't know something I obviously don't.
stick to the basics, please (Score:1)
And, nice as Python is, there is some room for improvement in its role as a scripting and VHLL for UNIX. Module configuration even in 2.0 is somewhat messy (configure, compile, edit Setup, compile some more). There is still nothing quite like CPAN and the CPAN shell module for Perl. Documentation is still more difficult to get to than "perldoc". Despite distutils, Python extensions still sometimes don't "just" install. And building C extensions could also be greatly simplified with a bit more support from the Python installation. Just about the only language enhancement I would like to see for now is lexical closures, not because I think its functionality is desparately needed, but because it would simplify scoping rules if done right.
I think Python is at risk of going down the same path as other dynamic languages before it. Adding a lot of new features (continuations, type declarations, list comprehensions, etc.) complicates the language to the point where people may not feel comfortable just picking the language up anymore. And the effort that goes into those fun features is effort that doesn't go into making the language even easier to install and interface with.
Re:Distributed Python? (Score:1)
Well Condor [wisc.edu] does (and has been doing for quite a while) exactly this with C. Assuming you follow the link, now you can believe it. Basically you link with condor's library and it intercepts i/o calls and sends them back to a central controller. Keep in mind this is distributed processing not distributed i/o.
Re:Continuations... in something other than Scheme (Score:2)
--
Re:Hmm...I wonder... (Score:3)
But since the Stackless stuff brings real performance improvements, microthreads, and nifty new libraries, it is likely to go into the main trunk at maybe 2.1 or probably 2.2.
Read the article? (Score:1)
Re:Continuations... in Javascript! (Score:3)
// See explanation at end.
// This code works and will run in a web browser -
// just save as
// Will work in Mozilla or IE.
// sample calls
printFacVal( "fact", 12, fact(12) );
printFacVal( "factail", 12, factail(12, 1) );
printFacVal( "factfn", 12, factfn(12, function (x) { return x; } ) );
// write the function name, value of n and result to the browser window
function printFacVal( fname, n, x )
{
document.write( fname + "(" + n + ") = " + x + "<P>" );
}
// Plain ol' recursive implementation of factorial
function fact( n )
{
if ( n == 0 )
return 1;
else
return n * fact( n - 1 );
}
// Version which supports tail recursion: final value is
// known when recurse bottom is reached, so stack can be
// optimized away in a language which supports this.
// See http://www.cs.utexas.edu/users/novak/cs30770.html -
// or for fun, http://info.astrian.net/jargon/terms/t/tail_recur
function factail( n, total )
{
if ( n == 0 )
return total;
else
return factail( n - 1, n * total );
}
/*
factfn()
Version which builds a function to calculate factorial(n)
This only really makes sense in a functional language.
Although syntactically it can be mapped directly onto its
functional language equivalent, and although it does
actually work in Javascript, CS students around the
country are recoiling in amazement tinged with horror
as they read this.
*/
function factfn( n, fn )
{
if ( n == 0 )
return fn( 1 );
else
return factfn( n - 1, function ( p ) { return fn( n * p ) } );
}
/*
factfn() would be rather hard to implement in a language like Pascal or C,
except if you were using one of those languages to build a functional language
(in which case, that would be easy!
As factfn() descends through its recursive calls, the anonymous function which
is passed as the second parameter becomes a function built specifically to
calculate the factorial of the specified n, i.e. the final value of fn(1)
equals the factorial of n.
However, since current implementations of Javascript don't support tail
recursion, factfn() relies on a stack to achieve its recursion, and is
thus bounded by stack size in what it can compute (actually, in this case,
the factorial calculation is limited numerically: factorial(170) or so
will overflow a typical Javascript implementation, long before the stack
fills up.) A tail-recursion implementation doesn't need a stack to recurse,
thus is not limited by stack depth.
Another difference between this and a tail-recursive implementation is that
when fn(1) is finally evaluated, in the Javascript implementation, it will
call itself recursively, again using the stack. At each level, the value
of n is taken from the function's context at the appropriate level (which
may be implemented on the stack).
A fully tail-recursive cps implementation would do all this without the
need for a stack. The final evaluation of fn(1) would simply evaluate the
final result of n * (n-1) * (n-2)... and get the right answer.
*/
</SCRIPT>
Continuations (Score:2)
Re:Continuations... in something other than Scheme (Score:1)
Re:deployment issues? (Score:1)
(1) understands seemlessly C/C++ header files and the APIs that it exposes. No SWIGgin! (But also, no IDL or stuff like that, just direct invocation!)
Sounds like any language that supports FFI (Foreign Function Interface).
(2) grabs its language run-time (virtual machine) (whichever version that you indicate), native methods (.obj files), and your application, uncrufts it (removes every class or method not used) and nicely links it into one, single clean executable (optionally compressed with, for example, UPX).
Sounds like Smalltalk. Squeak is a free cross-platform Smalltalk that supports FFI:
http://www.squeak.org
Re:Have you heard of Ruby? (Score:1)
Re:What about JPYTHON?? (Score:2)
And people claim Perl is hard to read!
:-)
Re:Continuation Passing Style... (Score:1)
Perl, C, FORTRAN, Pascal and AWK are a purely procedural (not even OO) languages. Functional languages are to large reflecting telescopes what these languages are to binoculars and it does boil down to vision preceded by imagination.
Re:Continuation Passing Style... (Score:1)
People tend to dislike and resent what they don't understand.
Re:Have you heard of Darwin? (Score:2)
Exactly the same methods that work for human languages, human biology and capitalism. A central plan works well when you've got a closed, well-defined problem to solve: "reimplement UNIX" or "make a fast C compiler". The trouble with planned solutions to open-ended problems is that sooner or later, the planner will miss a trick which Monte Carlo methods would have hit on, which is why evolution wins in the long run.
Re:Continuations... in Javascript! (Score:2)
The last expression in my third function, factfn():
The explanation h ere [oberlin.edu] is more explicit, IMO:
The example on that page is the canonical example of factorial in cps style in Lisp-like languages:
(define fact-k
(lambda (n k)
(if (zero? n) (k 1)
(fact-k (1- n) (lambda (v) (k (* n v)))))))
This program maps syntactically to my Javascript example, exactly: their n is my n, their k is my fn, and their v is my p.
To further demonstrate the apparent "continuation-ness" of the Javascript implementation, if you change the line in factfn() which reads "return fn(1)" to simply "return fn", factfn() will now return an unevaluated function to its caller. That function encapsulates the factorial of the value of n specified by the caller. You can then evaluate it, after the factfn() function has returned. The calling code would then look like this:
aFacFn = factfn( 5, function (x) { return x; } );
document.write( aFacFn( 1 ) );
When aFacFn(1) executes, it returns 120. It happens to arrive at this result by recursion. Nevertheless, the values of n which it uses internally come from function contexts (what that Python page is referring to as "frames") which are not (or no longer) on the traditional call stack. Since functions are first-class objects in Javascript, it pretty much has to support the concept of a frame detached from the call stack, and it does.
Having defended my position, I will say that no-one should seriously try to learn about these things using Javascript, or Python for that matter. When learning, it's much easier to work with these concepts in the context in which they're most effective, i.e. a true functional language. I picked Javascript for these examples because of its 1st-class function support and the fact that just about anyone reading this can run the code in their browser.
Re:How about... (Score:1)
Best to wait for python3k for such endeavors when python will most likely get optional static types defintions, interfaces, static scoping, and other features that will make python compiler optimization friendly.
jim
Re:Continuations... in Javascript! (Score:2)
Re:Continuations... in Javascript! (Score:2)
Try Ruby (Score:1)
Ruby, on the other hand, has good characteristics of Smalltalk, like pure oo, is faster, the syntax is sweet, you load the modules as you need them, etc. . I suggest everyone to at least take a look at it. It's syntax is very easy (much easier than Python, IMHO), and once you get the grasp, you start to just do right guesses of how to do things.
Re:Have you heard of Ruby? (Score:1)
But I understand that Ruby is much simpler than Python. Ruby don't have many (any?) special types, and that's a big thing about simplicity, IMHO.
Re:deployment issues? (Score:2)
And how, exactly, would you make it easier? In particular, how would you make it easier without sacrificing the full power and flexibility of extensions?
I think the real problem is with terminology. It's not a matter of "inner loops" vs. "outer loops". It's about performance-critical parts vs. non-performance-critical parts. For most scripts and tools and anything else short of full-blown industrial strength applications, coding any part of your Python application as an extension module is just stupid. In those cases where it might make sense, it's really not that hard to apply standard software-engineering approaches to the design of one or more extension modules which neatly encapsulate the performance-critical parts of your app behind a fairly simple interface. I've done it several times, and been quite satisfied with the results...and it's not because I'm particularly easy to satisfy. ;-)
That's a pretty tall order. C/C++ interfaces aren't exactly self-describing, even as far as number of arguments in many cases, let alone type and meaning etc. There's actually a Python extension module - forgot the name - that lets you do pretty much the sort of direct invocation you're talking about, putting all of the burden on the programmer to make sure they're passing the right number of arguments etc. It turns out not to be all that useful, though, because it really only provides part of a real extension interface - the "interpreter calls X" part. A full extension interface also allows X to call the interpreter, or X to interpret or manipulate or even create complex structures - objects, lists, dictionaries, aggregates of same - comprehensible to the interpreted code, and so on. Without all of that, which is not available in the model you propose, what you have is a crippled extension interface lacking many benefits inherent in the real thing.
This sounds pretty much like what "freeze" does, or perhaps a minimally-enhanced version of it. Could you explain what exactly you want that goes beyond that?
BTW, keep in mind that creation of a single monolithic executable is not always the goal. Many ways of doing what you describe would preclude component models or interactive use. It's just one more example of how Python represents a certain set of tradeoffs. It's not perfect for every usage, but the omission of certain features you might want might well be a conscious decision based on the fact that their inclusion might have precluded some other feature that is more generally useful.
Re:stick to the basics, please (Score:3)
As for improving module building and other things, I hope to make significant steps in that area for 2.1.
Hmm (Score:1)
I understand he didn't want to rewrite the core, and was working off an existing codebase, but if one were to start from scratch, it seems like that might be the simplest way to do this.
---
Read the Ruby Book (!) (Score:3)
The online docs are also good.
Re:Have you heard of Ruby? (Score:3)
In short, I think I agree with another poster's comment that instead of waiting for Perl6, you should look at Ruby instead. Not as pleasant to read Ruby code as Python code, though, and its syntax isn't as clean, so it won't be replacing Python for me just yet.
Re:Distributed Python? (Score:2)
However, the implementor in the articl discusses "pickling" program state, which allows it to be stored to disk, for example. This implies that it is not using a secondary server to manage state, but somehow hoping to store all of it. My comment was basically that this seemed impossible, because some state is stored in kernel space and only accessed by a handle.
But I can see how my comment about DSM was misleading. Sorry about that.
Good features (Score:2)
Both Vyper and Stackless Python offer some extremely cool features that I would definitely like to see in CPython.
Python 2.0 saw the introduction of assignment-operators ( +=, -=, *=, etc.), and list comprehensions (a quick steal from Haskell). Both of these are cool, but there are still nagging usability problems:
The fact that lambdas are fundamentally broken because you cannot do anything really powerful with them. Adding lexical scoping to python would alleviate this problem, and let me do nifty 'map' and 'filter' stuff in python a LOT easier.
And continuations are damned powerful. Right now you can hack up a semblance of continuations using the fact that you can divorce instance-methods from their instances, and use them as normal methods, which means methods can have a static state, and use a 'if/elif/else' statement block to choose a continuation.. but hat is a horrible hack.
Python is an excellent language, but the cool thing about it is that there are so many obvious things that need to be fixed, it can only get better
-Laxitive
Re:Have you heard of Ruby? (Score:2)
Wrong. John Ousterhout, creator of Tcl, is a CS professor. Guido van Rossum, creator of Python, is well versed in language design. You may not like their decisions - I personally detest Tcl - but I would bet either of them is about 10x more qualified to design a language than anyone here.
Larry Wall, on the other hand, has no discernible background or ability in language design, and it shows in Perl.
Distributed Python? (Score:3)
-_Quinn
Continuation Passing Style... (Score:2)
of working it takes a bit to get back to Java/C!
The basic idea for those of you who are confused is to use recursion and get away with not using the stack for the calls. How you might ask... well first of all its easy when you are using a language like Scheme/Lisp which treats functions as first class data members! There is no difference b/w (well almost none) b/w data types and functions, each can be passed into a function and returned!
SO Normally when you make a recursive call you are just pushing down your current data into the stack and when you reach the base case you go back up the stack!
In case of Continuation Passing Style the idea is really very very neat! You basically make a recursive call and pass a function to that will be able to compute the answer with the data it needs! There is no stack. For example (Factorial of course)
(define fac
(lambda (n)
(if (
Note you had to keep the info of where you were so you can recurse back doing the multiplications!
This data went into the stack!!! Now if you want to do this without stacks you can use a method that you build each time you go through the loop and so you build the answer on your way!!!