(original) (raw)

On 13 Oct 2013 00:47, "R. David Murray" <rdmurray@bitdance.com> wrote:
\>
\> On Sat, 12 Oct 2013 16:04:23 +0200, Stefan Behnel <stefan\_ml@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@python.org
\> https://mail.python.org/mailman/listinfo/python-dev
\> Unsubscribe: https://mail.python.org/mailman/options/python-dev/ncoghlan%40gmail.com