[Python-Dev] Change PEP 399 import recommendation (original) (raw)

Nick Coghlan ncoghlan at gmail.com
Sat Oct 12 17:37:41 CEST 2013

On 13 Oct 2013 00:47, "R. David Murray" <rdmurray at bitdance.com> wrote:

On Sat, 12 Oct 2013 16:04:23 +0200, Stefan Behnel <stefanml at behnel.de> wrote: > Stefan Krah, 12.10.2013 15:41: > > Nick Coghlan wrote: > >> On 12 Oct 2013 05:49, "Eric Snow" wrote: > >>> On Fri, Oct 11, 2013 at 1:41 PM, Stefan Krah wrote: > >>>> Antoine Pitrou wrote: > >>>>> Just create a pydecimal module (like pyio). > >>>> > >>>> That's very fast indeed. There's one minor problem: For backwards > >> compatibility > >>>> and pickling [1] I'd need to add > >>>> > >>>> module = 'decimal' > >>>> > >>>> to every class of the Python version. Are there any reasons not to do that? > >>> > >>> Try just putting "name = 'decimal'" at the top of the source file. > >> > >> In this case the fixup needs to be conditional on the absence of "_decimal". > >> Aside from that, yes, lying about name is the easiest way to preserve pickle > >> compatibility while still moving code around. > > > > Thanks Eric and Nick. The setup pretty much works (see issue #19232) and the > > import speedup is quite large. I wonder if Cpython's startup time could be > > reduced if this strategy was applied to other modules as well (see #19229). > > > > There are some concerns whether the change would impact other Python > > implementations, so I changed the subject (hoping for feedback). > > FWIW, I think this definitely makes sense in cases where the C > implementation is essentially a complete replacement of the original > module, such as in this case. I even sometimes suggest compiling Python > modules with Cython if the import time matters. > > For "normal" accelerator modules that only replace a part of a Python > module with a native implementation, this is less likely to make a large > enough difference to make up for the additional complexity due to the code > split. The impact on other implementations is: what if they write an accelerator that only replaces part of the module, whereas CPython's replaces the whole thing? But I think we could just postpone dealing with that until it actually comes up, just as we would if some other implementation writes an accelerator for a module for which CPython doesn't have one.

I think the default recommendation in PEP 399 still makes sense - 2 modules are easy to manage than three and the idiom allows for easy partial replacement.

If the module is complex enough (and keep in mind that Brett used decimal.py as a data point in import benchmarking due to its sheer size meaning execution time was actually significant, even relative to IO time), or implicitly imported at startup, then the more complex 3 module setup may be worthwhile. If other implementations only provide partial acceleration, they can import the pure Python implementation as part of their accelerator implementation.

Cheers, Nick.

--David

Python-Dev mailing list Python-Dev at python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/ncoghlan%40gmail.com -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mail.python.org/pipermail/python-dev/attachments/20131013/ccdc372c/attachment-0001.html>

More information about the Python-Dev mailing list