[Python-Dev] Change PEP 399 import recommendation

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 <stefan_ml 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