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
Speed up _decimal import #63431
Comments
As discussed on python-dev, importing _decimal at the bottom of |
I proposed something similar for issue bpo-19229. |
Remember that one reason for importing the C version at the bottom of the python version is so that alternate implementations (PyPy, IronPython, Jython) could provide partial versions of the C (or equivalent) versions. By importing after the Python version, the alternate implementation could continue to use parts of the Python code. I think the impact on alternate implementations needs to be considered before we start rearchitecting these imports. |
Right, let's start collecting objections. :) Mark, Raymond: Would you support the change (name hack and all)? Maciej: Is this approach a problem for PyPy? |
If the Python implementation is renamed to _pydecimal, I don't expect it to be used in CPython. I never used _pyio in a real application, only for some tests to debug. I don't think that we need the __name__ = 'decimal' "hack". If you really want to keep it, please add at least a comment explaining it. |
I guess if some of the pickling stuff get's rewritten, we can drop The other thing is that traditionally the types were "decimal.Decimal" Of course adding __module__ everywhere is another option. |
Why not renaming the _decimal module to decimal? |
_decimal already lies about its name (for pickling). |
I can't apply the patch that was created with diff --git, so here is |
You can apply it using "hg import --no-commit", I think. |
No objections here. |
Antoine Pitrou <report@bugs.python.org> wrote:
mercurial 2.1 throws an exception even though the patch was created with Rietveld also seems to choke on the first patch (no review link). |
I think we should save these sort of tricks only for modules imported during startup. Ideally, a user should expect that the code for the decimal module is in decimal.py. Ideally, tools like IDLE's "Open Module" should be able to find the source code using only the module name. I'm -0 on this one. I don't think hacking up the source tree is worth it. The import is only done once -- the important part is what decimal does when it is imported. |
About IDLE I can't say anything, but I'm not entirely sure if the http://stackoverflow.com/questions/13194384/instantiate-decimal-class I get the impression that the posters at first did not even realize As for the load time: Personally I don't have any application So if there are applications that start a new Python script OTOH I don't like moving code around either, so we can wait until |
Keep in mind that people who have startup speed problems aren't |
I would like to go ahead with this. As Antoine mentioned, most As it turns out, the slowdown is even significant in a simple tcpserver Another benefit is that it will be possible to import the Python version |
New changeset 8bf51cf94405 by Stefan Krah in branch 'default': |
We could speed up the import further by not importing collections |
"We could speed up the import further by not importing collections I suggest to close this issue. I guess that importing decimal is already fast enough, and enhance structseq is a completly different issue. (Is there an open issue, just to get the link?) |
I'm fine with closing this. The structseq issue is bpo-1820. |
New changeset 75b5617b8dfc by Stefan Krah in branch 'default': |
Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.
Show more details
GitHub fields:
bugs.python.org fields:
The text was updated successfully, but these errors were encountered: