As discussed on python-dev, importing _decimal at the bottom of
decimal.py is about 9x slower than importing _decimal directly.

I proposed something similar for issue #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
__name__.

The other thing is that traditionally the types were "decimal.Decimal"
etc., so I'm not sure if it is good idea to have "_decimal.Decimal" and
"_pydecimal.Decimal".

Of course adding __module__ everywhere is another option.

> The other thing is that traditionally the types were "decimal.Decimal"
> etc., so I'm not sure if it is good idea to have "_decimal.Decimal" and
> "_pydecimal.Decimal".

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
another one that is less readable but applies.

> I can't apply the patch that was created with diff --git, so here is
> another one that is less readable but applies.

You can apply it using "hg import --no-commit", I think.

> Mark, Raymond: Would you support the change (__name__ hack and all)?

No objections here.

Antoine Pitrou <report@bugs.python.org> wrote:
> You can apply it using "hg import --no-commit", I think.

mercurial 2.1 throws an exception even though the patch was created with
that version.  Now I upgraded to 2.7.2 and it works.

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
PEP-399 import method is easier to understand for users, see e.g.:

http://stackoverflow.com/questions/13194384/instantiate-decimal-class

I get the impression that the posters at first did not even realize
that there *is* an accelerator in Python 3.3, so they had a hard time
debugging the issue.


As for the load time: Personally I don't have any application
that relies on a very short load time, but I wan't to note again
that importing decimal at Python startup actually doubles the
startup time.

So if there are applications that start a new Python script
for each request (e.g. via djb's tcpserver), it could really
matter.


OTOH I don't like moving code around either, so we can wait until
there's a demonstrated need for the speedup.

> OTOH I don't like moving code around either, so we can wait until
> there's a demonstrated need for the speedup.

Keep in mind that people who have startup speed problems aren't
likely to open an issue on the tracker about it, let alone
diagnose it enough to put the blame on decimal.

I would like to go ahead with this.  As Antoine mentioned, most
people don't diagnose import problems, especially when they compare
Python 2 against Python 3.

As it turns out, the slowdown is even significant in a simple tcpserver
application that starts a Python script.

Another benefit is that it will be possible to import the Python version
easily, e.g. to check error messages (currently _decimal justs displays
the signal in tracebacks).  I've often wanted that myself instead of
going through the import_fresh_module() ordeal.

New changeset 8bf51cf94405 by Stefan Krah in branch 'default':
Issue #19232: Speed up decimal import.  Additionally, since _decimal is
http://hg.python.org/cpython/rev/8bf51cf94405

We could speed up the import further by not importing collections
in _decimal.  That could be done once structseq fully implements
the namedtuple protocol (for DecimalTuple).

"We could speed up the import further by not importing collections
in _decimal.  That could be done once structseq fully implements
the namedtuple protocol (for DecimalTuple)."

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 #1820.

New changeset 75b5617b8dfc by Stefan Krah in branch 'default':
Issue #19232: Fix sys.modules lookup (--without-threads)
https://hg.python.org/cpython/rev/75b5617b8dfc