Q: Python 2.0 preliminary features?

[Christian Tismer]

Now I feel I have to reply :)

Sorry about the topic shift.

Greg Ewing wrote:
> 
> Guido van Rossum wrote:
> >
> > The magic may easily be
> > triggered at the wrong moment -- e.g. the debugger may be looking at
> > your stack frame, and depending on whether it copies the object it
> > pulls out of your stack frame into a local variable before looking at
> > it or not, it will see either a function or the magic object.

<big snip>

> > Note that this is also one of the reasons why I'm feeling uneasy with
> > the stackless Python patch set ... it uses a magic object
> 
> I wouldn't reject the whole idea of a stackless interpreter
> on the basis of that implementation, though. I suspect the
> author used a special object because it got the job done with
> minimal changes to the existing code. There are other ways to
> signal to the interpreter what is to be done next.

Thanks a lot, Greg. This is exactly true: In order to come up
with a working solution which avoids to rewrite everything,
this implementation uses a special object.

There is not much more "magic" than in the standard implementation
BTW, since Python already has a special object: NULL, which means
"evaluator, there is no valid result, please wind back and handle
the error".
I'm just adding a third state which says
"evaluator, there is a frame to be evaluated right now, please
wind back and let it happen".

Note that like NULL, this object never pops out to the interpreter
level, it is just an element of an internal protocol. If Python was
using exceptions instead of NULL to trigger special handling, it
could as well be implemented that way, and there are other ways.

> > (another reason is that it can't be
> > done in JPython so it can't be made a part of the language standard)
> 
> Has supporting JPython become an official guiding principle
> behind mainstream Python development? That may turn out to be
> somewhat restrictive in the long term.

This is the first time that I hear this argument from Guido.
Is getting rid of Stackless Python enough of a challenge to
define JPython compatibility as a Python standard requirement?
Well, at least *some* effect, while different from my targets. :-)

And who has tried to port SP to JPython already? Is there any
reason why JPython should not be able to become stackless?

Tell me it's impossible, and I will try to implement it,
since Stackless Python was told to be impossible as well.

Accepting-Guido's-claim-if-I'm-allowed-to-revert-it
- if-possible-in-JPython-then-it-will-be-standard- -ly 'yrs - chris

-- 
Christian Tismer             :^)   <mailto:tismer at appliedbiometrics.com>
Applied Biometrics GmbH      :     Have a break! Take a ride on Python's
Kaiserin-Augusta-Allee 101   :    *Starship* http://starship.python.net
10553 Berlin                 :     PGP key -> http://wwwkeys.pgp.net
PGP Fingerprint       E182 71C7 1A9D 66E9 9D15  D3CC D4D7 93E2 1FAE F6DF
     we're tired of banana software - shipped green, ripens at home