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
