[Python-ideas] add a single __future__ for py3?

[Steven D'Aprano]

On Fri, Nov 27, 2015 at 07:29:36PM +0000, Michael Scott Cuthbert wrote:

> (an old list topic that I accidentally sent to the Google Groups list)

I'm confused -- your subject line talks about a single __future__ for 
Python 3, but you don't talk about that in the body of the post. I'm not 
sure what the comment about Google Groups is supposed to mean. If you 
posted something there, most of us aren't going to see it, you'll need 
to re-post it here, not just tell us you posted it on Google Groups.


As for your secondary point:

> One smaller request is to remove 'barry_as_FLUFL' from 
> "__future__.all_feature_names".  It's a great practical joke, but it 
> bit me hard on a project where I check that, for Py2/Py3 consistency, 
> each module imports all relevant __future__ names, and ensures that 
> doctests on Py2 are run with them on.  I figured that I could iterate 
> through .all_feature_names and turn them all on except 
> unicode_literals and be safe, 

Hmmm, well, no, that's not really safe (as you've found out), 
particularly if you intend your code to be forward-compatible. 
Barry_as_FLUFL is a joke, but it demonstrates a real problem with your 
approach. Should some future version of Python add a new __future__ 
feature, and you run your code under that new version, you will 
unintentionally turn the feature on when your code is not expecting it, 
and likely break.

To put it another way... suppose Guido had a change of heart about != 
and decided that <> really was better, and so Barry_as_FLUFL was spelled 
"proper_ne" and was intended as a real feature, not a joke. Your code 
would still have broken, but removing "proper_ne" from all_feature_names 
would certainly not be an option.

The problem isn't that Barry_as_FLUFL is listed, but that you blindly 
applied all features without knowing what they are. Don't do that, it 
isn't safe.


-- 
Steve