[Stackless] __future__ policy

Martijn Faassen faassen at startifact.com
Wed Jan 8 13:47:52 CET 2014


On 01/08/2014 12:36 PM, Christian Tismer wrote:
> Yep. For me, it seems to be cleanest/simplest for now to extend __future__,
> and make a matching stackless 3.x that adds exactly those as no-ops.

I'll shut up about it after this post, but I'll try one more time.

I really think you're making a big mistake.

You're going for a superficial cleanliness that actually creates all 
kinds of ugliness: a political debate on python-dev about this, *or* 
semi-auto-conversion that makes polyglot code impossible.

With Stackless 2.8 you're setting up your own, new, independent way to 
get Python 3.x functionality into your interpreter that has nothing to 
do with Python 2.x. It makes sense to do that in an independent import.

> Python 3.4 can follow the patch, or we change things.
> I think that will not be so problematic, since the compat header is at the
> front of the module, and semi-auto-conversion would be possible.

semi-auto-conversion is *not* how polyglotted code works. If you want to 
support polyglotted libraries that work on Stackless 2.8 and Python 3.x 
this strategy will not work.

I can already see the argument on python-dev: why should we support from 
__future__ imports like nonlocal? They are not supported by Python 2.7, 
oh, there's this Stackless 2.8 thing, what, we're supposed to offer 
compatibility with *that*? But Stackless 2.8 is doing the opposite of 
what we want, see PEP 404! Or at the very least it would cause 
confusion, wrong expectations, blah blah. And we're already in beta, try 
it in Python 3.5. (making polyglot code impossible until then)

But you can try. Maybe I'll be surprised.

Regards,

Martijn





More information about the Stackless mailing list