Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Merged
merged 4 commits into from Apr 12, 2018

Conversation

ethanfurman
Copy link
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
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.

Lib/enum.py Outdated
@@ -309,6 +310,11 @@ def __call__(cls, value, names=None, *, module=None, qualname=None, type=None, s
return cls._create_(value, names, module=module, qualname=qualname, type=type, start=start)

def __contains__(cls, member):
if not isinstance(member, Enum):
warnings.warn(
Copy link
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
Member Author

Choose a reason for hiding this comment

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

Done.

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

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

@ethanfurman
Copy link
Member Author

I have made the requested changes; please review again.

@bedevere-bot
Copy link

Thanks for making the requested changes!

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

@ethanfurman
Copy link
Member Author

ethanfurman commented Apr 12, 2018 via email

@ned-deily
Copy link
Member

Go for it!

@miss-islington
Copy link
Contributor

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

@miss-islington
Copy link
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
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
Member Author

ethanfurman commented Apr 12, 2018 via email

@serhiy-storchaka
Copy link
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
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
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
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
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
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.

None yet

6 participants