Python 2.0 and Stackless

Robin Becker robin at jessikat.fsnet.co.uk
Sat Aug 5 03:12:03 EDT 2000


In article <8mg3au$rtb$1 at nnrp1.deja.com>, Jeremy Hylton
<jeremy at alum.mit.edu> writes
>In article <9b13RLA800i5EwLY at jessikat.fsnet.co.uk>,
>  Robin Becker <robin at jessikat.fsnet.co.uk> wrote:
>> In article <bld7joah8z.fsf at bitdiddle.concentric.net>, Jeremy Hylton
>> <jeremy at beopen.com> writes
>>
>> I find this response rather conservative. JPython is not Python,
>> stacklessness + continuations and the like are semantic not
>> implementation issues. Python & java are direct competitors; GvR
>should
>> take the technical high ground wherever and whenever possible.
>>
>
>It is a conservative response.  JPython is an implementation of Python,
>and compatibility between Python and JPython is important.  It's not
>required for every language feature, of course; you can't load a Java
>class file in C Python.
>
>I'm not sure what you mean by distinguishing between the semantics of
>continuations and the implementation of Stackless Python.  They are
>both issues!  In the second half of my earlier message, I observed that
>we would never add continuations without a PEP detailing their exact
>semantics.  I do not believe such a specification currently exists for
>stackless Python.
>

My intended meaning was that Python has a reference implementation in C;
other implementations exists eg CPython, JPython.

The abstract definition of Python must exist somewhere (probably in
Guido's head). I regard stackless as an implementation, but it provides
the ability to do certain things very conveniently eg the continuations
uthreads etc.

The inability of another implementation language (java) to follow this
shouldn't be regarded as a good enough reason to hinder a useful change
in the language. Presumably the C# / .NET nonsense will eventually
result in some feedback; will that be a reason to modify the language?

I am certain we should distinguish between the abstract semantics and
the implementations. After all JPython can presumably do things that
ordinary Python cannot and nobody complains.

>The PEP would also need to document the C interface and how it affects
>people writing extensions and doing embedded work.  Python is a glue
>language and the effects on the glue interface are also important.
>
>As I said, there is nothing impossible about doing this.  Heck, I think
>MzScheme has done a pretty good job at this.  But it is hard.
>
>Jeremy
>
>
>Sent via Deja.com http://www.deja.com/
>Before you buy.

-- 
Robin Becker



More information about the Python-list mailing list