[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