[Stackless] FW: __future__ policy
Richard Tew
richard.m.tew at gmail.com
Fri Jan 10 19:39:44 CET 2014
+1
On 1/10/14, Kristján Valur Jónsson <kristjan at ccpgames.com> wrote:
> Here's my last reply to the private thread that somehow got the mailing list
> left out:
> (and the reason for from __future__ import with statement is that cdev
> thought that making "with" and "as" into keywords would be too big of a
> step, as Christian pointed out. I can agree. But similar measures where
> not taken when e.g. "yield" was introduced.
>
> -----Original Message-----
> From: Kristján Valur Jónsson
> Sent: 9. janúar 2014 20:51
> To: Anselm Kruis; Christian Tismer
> Subject: RE: [Stackless] __future__ policy
>
> (1)
> I don't think stackless 2.8 must be any more compatible with 2.7 than 2.7
> was compatible with 2.6.
> 2.7 introduced new syntax into the language. So has every new minor version
> of python. Normally people get some warning ahead of time, and can enable
> futures ahead of time, but if people don't do anything, their old code will
> occasionally break in minor ways.
>
> There are only a few of changes:
> 1) syntax changes, where new reserved words are introduced, or removed. An
> example is the "print statement". This is a complete change of syntax and
> thus old code is guaranteed to not work. New code also cannot be written
> without this because "print" was a statement. This requires a __future__.
> 2) Additions of new keyword. Example is "yield". This was never added with
> a __future__ since it just reserved another keyword. Minor breakage was
> possible if someone had a function called yield.
> 3) Library updates. New features are added into a library Old deprecated
> stuff is removed. This also does not require a __future__ change.
>
> Taking a list of the defined __futures__ for 2.x is illustrative:
> featureoptional inmandatory ineffect
> nested_scopes2.1.0b12.2PEP 227: Statically Nested Scopes
> generators2.2.0a12.3PEP 255: Simple Generators division2.2.0a23.0PEP 238:
> Changing the Division Operator absolute_import2.5.0a12.7PEP 328: Imports:
> Multi-Line and Absolute/Relative with_statement2.5.0a12.6PEP 343: The "with"
> Statement print_function2.6.0a23.0PEP 3105: Make print a function
> unicode_literals2.6.0a23.0PEP 3112: Bytes literals in Python 3000
>
>
> All of the above are invasive changes where old code suddenly gets new
> meaning. This is why they need to be explicitly enabled. Although I'm
> unsure why with_statement is there, since that syntax would have been
> illegal before it anyway...
>
> So, my point is,
> We can add features from 3.x like nonlocal and yield from without enabling
> them with __future__ statements. We can also add library features like
> weakref.WeakMethod and a multitude of other nice things that have been added
> to the library and are useful in 2.x too.
> We can refactor or fix things in the library that could possibly break some
> edge cases that rely on undocumented behaviour (like fixing httplib's close
> semantics, and urllib2's response objects, etc.
>
> Changing the way exceptions are specified and handled, however, would
> require a __future__. And to be honest, that would be a huge undertaking
> anyway, not the first thing that comes to mind.
>
> So, in my opinion: Let's not worry too much about it. Let's just consider
> 2.8 a new minor release which introduces a couple of new syntax elements,
> just like any previous version before it. I't rather get cracking than
> spend too much time and effort bikeshedding about this kind of stuff. Let's
> get something working, then we can think about whatever kid gloves we need
> to provide people with later.
>
> K
>
>
>
> _______________________________________________
> Stackless mailing list
> Stackless at stackless.com
> http://www.stackless.com/mailman/listinfo/stackless
>
More information about the Stackless
mailing list