Skip to content

[3.7] bpo-33217: deprecate non-Enum lookups in Enums#6392

Merged
ethanfurman merged 4 commits intopython:3.7from
ethanfurman:bpo-33217
Apr 12, 2018
Merged

[3.7] bpo-33217: deprecate non-Enum lookups in Enums#6392
ethanfurman merged 4 commits intopython:3.7from
ethanfurman:bpo-33217

Conversation

@ethanfurman
Copy link
Copy Markdown
Member

@ethanfurman ethanfurman commented Apr 5, 2018

Lookups such as 1 in Color and 2 in SomeFlag() will raise TypeError
in 3.8+.

https://bugs.python.org/issue33217

Lookups such as `1 in Color` and `2 in SomeFlag()` will raise TypeError
in 3.8+.
@ethanfurman ethanfurman changed the title bpo-33217: deprecate non-Enum lookups in Enums [3.7] bpo-33217: deprecate non-Enum lookups in Enums Apr 5, 2018
@ethanfurman ethanfurman self-assigned this Apr 5, 2018
Copy link
Copy Markdown
Member

@serhiy-storchaka serhiy-storchaka left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Add the deprecated directive(s ) in the module documentation and a note in the What's New document.

Comment thread Lib/enum.py

def __contains__(cls, member):
if not isinstance(member, Enum):
warnings.warn(
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Add import warnings just here.

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Done.

Comment thread Lib/enum.py Outdated
if not isinstance(member, Enum):
warnings.warn(
"using non-Enums in containment checks will raise "
"TypeError in 3.8+",
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

"in Python 3.8"

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Done

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

"in 3.8" is a jargon. Non-core developers could not understand it. It is better to be more explicit in public warnings: "in Python 3.8".

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Whoops, missed the "Python" part -- done now.

Copy link
Copy Markdown
Member

@ned-deily ned-deily left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks good except that you should add an item about this to the Deprecated section of the 3.7 whatsnew document. Doc/whatsnew/3.7.rst => https://docs.python.org/3.7/whatsnew/3.7.html#deprecated

@bedevere-bot
Copy link
Copy Markdown

When you're done making the requested changes, leave the comment: I have made the requested changes; please review again.

@ethanfurman
Copy link
Copy Markdown
Member Author

I have made the requested changes; please review again.

@bedevere-bot
Copy link
Copy Markdown

Thanks for making the requested changes!

@serhiy-storchaka, @ned-deily: please review the changes made to this pull request.

@ethanfurman
Copy link
Copy Markdown
Member Author

ethanfurman commented Apr 12, 2018 via email

@ned-deily
Copy link
Copy Markdown
Member

Go for it!

@miss-islington
Copy link
Copy Markdown
Contributor

Thanks @ethanfurman for the PR 🌮🎉.. I'm working now to backport this PR to: 3.6.
🐍🍒⛏🤖

@miss-islington
Copy link
Copy Markdown
Contributor

Sorry, @ethanfurman, I could not cleanly backport this to 3.6 due to a conflict.
Please backport using cherry_picker on command line.
cherry_picker 3715176557cf87925c8f89b98939c7daf9bf48e2 3.6

@ned-deily
Copy link
Copy Markdown
Member

ned-deily commented Apr 12, 2018

@ethanfurman Why would we backport this to 3.6? It would introduce a change in behavior late in its lifetime.

@ethanfurman
Copy link
Copy Markdown
Member Author

ethanfurman commented Apr 12, 2018 via email

@serhiy-storchaka
Copy link
Copy Markdown
Member

Usually we don't backport deprecations, because this can break a code. The exception is 2.7 with -3 option.

@ned-deily
Copy link
Copy Markdown
Member

@ethanfurman Sure, 3.6 does but I think it would be worse to suddenly introduce a DeprecationWarning in a maintenance release. That's why I wanted to get it into 3.7.0. I'm not sure that we have a written policy on this but I think we should avoid doing it in this case. Thanks!

@serhiy-storchaka
Copy link
Copy Markdown
Member

You need to port some changes to master: a news entry, docs changes, some tests. It would be easier to port the whole PR, and later convert a warning into an exception in a separate PR.

@ethanfurman
Copy link
Copy Markdown
Member Author

@ned-deily, no problem.

@serhiy-storchaka, are there directions somewhere on how to do that? I was just going to create a whole new PR with the changes in it (new docs, exceptions, etc.).

@ned-deily
Copy link
Copy Markdown
Member

@ethanfurman To clarify, I wouldn't object to a purely documentation change for 3.6.x that says that doing those kinds of containment tests will raise a DeprecationWarning in 3.7 and an error in 3.8 but it's probably not necessary.

You might be able to use Git's cherry-pick command as a starting point, probably with the -n option. Our workflow with git is sort of the reverse of what we were doing with hg, e.g. we now commit first to master than backport as necessary to maintenance branches. The needs backport labels and the backporting bot are optimized for that.

@serhiy-storchaka
Copy link
Copy Markdown
Member

Maybe using cherry_picker in the opposite direction?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

6 participants