bpo-31862: Port binascii to PEP 489 multiphase initialization · Pull Request #4108 · python/cpython (original) (raw)

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 andprivacy statement. We’ll occasionally send you account related emails.

Already on GitHub?Sign in to your account

Conversation11 Commits6 Checks0 Files changed

Conversation

This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.Learn more about bidirectional Unicode characters

[ Show hidden characters]({{ revealButtonHref }})

ghost

This PR ports _bisect to the PEP 489 multiphase initialization.

The module doesn't use mutable global state, so it should be OK to use with subinterpreters.

This PR is deliberately simple to test the workflow; more and more complicated ones will follow.

https://bugs.python.org/issue31862

merwok

@@ -0,0 +1 @@
Port md5 module to PEP 489 multiphase initialization.

Choose a reason for hiding this comment

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

Do you mean _bisect module?

Choose a reason for hiding this comment

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

Yes, sorry for that.

@ghost

What is the best solution to porting of this many modules?
Should I add all of the modules to this PR, or is it better to merge ported modules in groups in multiple PR's?

@ghost

auvipy

@ncoghlan

Hi @Traceur759 - sorry for leaving this unreviewed for so long. Now that @ericsnowcurrently's draft internal API for Python-level subinterpreter support has been added, would you be able to come up with a test case for these modules that fails without the patch, and works with it?

It would also be nice to avoid the module state retrieval overhead in the cases where an exception doesn't need to be raised - I know you have a draft PEP for defining static shared exception types, for this PR specifically you could avoid the problem by deferring loading the state until an exception is about to be raised.

Marcel Plch added 3 commits

March 19, 2018 16:08

@brettcannon brettcannon changed the titlebpo-31862: Port a standard library module to PEP 489 multiphase initialization bpo-31862: Port binascii to PEP 489 multiphase initialization

Mar 29, 2019

@brettcannon

@the-knights-who-say-ni

Hello, and thanks for your contribution!

I'm a bot set up to make sure that the project can legally accept your contribution by verifying you have signed the PSF contributor agreement (CLA).

Unfortunately we couldn't find an account corresponding to your GitHub username on bugs.python.org (b.p.o) to verify you have signed the CLA (this might be simply due to a missing "GitHub Name" entry in your b.p.o account settings). This is necessary for legal reasons before we can look at your contribution. Please follow the steps outlined in the CPython devguide to rectify this issue.

You can check yourself to see if the CLA has been received.

Thanks again for your contribution, we look forward to reviewing it!

@brettcannon

Looks like @Dormouse759 doesn't have a bugs.python.org account associated with that GitHub username, so closing as the CLA isn't signed still. This PR can be re-opened if that changes.

@ghost

@brettcannon I have renamed my account and forgotten to change the GH name on bugs.python.org.
It should be associated now.

@brettcannon

@Dormouse759 thanks for the fix! I've reopened the PEP.

@encukou

@encukou

@encukou

@Dormouse759 I rebased on current master, and I have one more suggestion, which is better expressed as a commit rather than text :)
Do you agree with this extra change in binascii_exec?

@ghost