add a single __future__ for py3?
(an old list topic that I accidentally sent to the Google Groups list) 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, but suddenly I was getting Syntax errors on all my != tests, and there was not anywhere to turn to for an explanation. Barry might be pleased. In any case it seems better to treat it like "braces" which isn’t listed in "all_feature_names" Best, Myke Cuthbert (long-time-reader-first-time-writer intro: switched from Perl to Python in 2006, wrote music21 (music analysis toolkit) in Python, got tenure at MIT for it. Hugely thankful to the amazing community)
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:
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
On Friday, November 27, 2015 7:46 PM, Steven D'Aprano <steve@pearwood.info> wrote:
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.
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:
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
On Friday, November 27, 2015 7:46 PM, Steven D'Aprano <steve@pearwood.info> wrote:
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.
participants (3)
-
Andrew Barnert -
Michael Scott Cuthbert -
Steven D'Aprano