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
_______________________________________________
Stackless mailing list
[email protected]
http://www.stackless.com/mailman/listinfo/stackless
