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

[Andrew Barnert]

On Friday, November 27, 2015 7:46 PM, Steven D'Aprano <steve at pearwood.info> wrote:

> > 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.

Assuming he's doing this in a test suite, rather than in real code, I think it is safe, and maybe even a good idea. His test suite passes in 3.6, but in 3.7, it fails because some of his code doesn't work correctly with "from futures import thing_nobody_expects". That implies that his code may fail in 3.8, so he'd better take a look at thing_nobody_expects. And it's good that he finds this out now, instead of 18 months from now when his first users upgrade to 3.8 and his code breaks.

That being said, whatever test system he uses had better let him mark a future as disabled or known-bad or whatever. Otherwise, he has to put off any commits at all until he fixes the thing_nobody_expects stuff. And realistically, he probably has a lot of higher-priority bugs to take care of in the intervening 18 months. And if he can do that temporarily for thing_nobody_expects, I don't see why he can't do that permanently for Barry_as_FLUFL. So, I don't think Python needs to change; his test tool does. (In fact, Barry_as_FLUFL serves as a good test for test tools' future testing.:))

Also, the fact that he's already got code to "turn them all on except unicode_literals" implies that he doesn't really have a problem in the first place; he just needs to change that code to turn them all on except unicode_literals and Barry_as_FLUFL.