+1 On 1/10/14, Kristján Valur Jónsson <[email protected]> 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 > [email protected] > http://www.stackless.com/mailman/listinfo/stackless >
_______________________________________________ Stackless mailing list [email protected] http://www.stackless.com/mailman/listinfo/stackless
