Movatterモバイル変換
[0]ホーム
[Python-Dev] requirements for moving __import__ over to importlib?
Brett Cannonbrett at python.org
Tue Feb 7 21:07:24 CET 2012
I'm going to start this off with the caveat thathg.python.org/sandbox/bcannon#bootstrap_importlib is not completely atfeature parity, but getting there shouldn't be hard. There is a FAILINGfile that has a list of the tests that are not passing because importlibbootstrapping and a comment as to why (I think) they are failing. But noswitch would ever happen until the test suite passes.Anyway, to start this conversation I'm going to open with why I thinkremoving most of the C code in Python/import.c and replacing it withimportlib/_bootstrap.py is a positive thing.One is maintainability. Antoine mentioned how if change occurs everyone isgoing to have to be able to fix code in importlib, and that's the point! Idon't know about the rest of you but I find Python code easier to work withthan C code (and if you don't you might be subscribed to the wrong mailinglist =). I would assume the ability to make changes or to fix bugs will bea lot easier with importlib than import.c. So maintainability should beeasier when it comes to imports.Two is APIs. PEP 302 introduced this idea of an API for objects that canperform imports so that people can control it, enhance it, introspect it,etc. But as it stands right now, import.c implements none of PEP 302 forany built-in import mechanism. This mostly stems from positive thing #1 Ijust mentioned. but since I was able to do this code from scratch I wasable to design for (and extend) PEP 302 compliance in order to make surethe entire import system was exposed cleanly. This means it is much easiernow to write a custom importer for quirky syntax, a different storagemechanism, etc.Third is multi-VM support. IronPython, Jython, and PyPy have all said theywould love importlib to become the default import implementation so thatall VMs have the same implementation. Some people have even said they willuse importlib regardless of what CPython does simply to ease their codingburden, but obviously that still leads to the possibility of subtlesemantic differences that would go away if all VMs used the sameimplementation. So switching would lead to one less possible semanticdifference between the various VMs.So, that is the positives. What are the negatives? Performance, of course.Now I'm going to be upfront and say I really did not want to have thisperformance conversation now as I have done *NO* profiling or analysis ofthe algorithms used in importlib in order to tune performance (e.g. thefunction that handles case-sensitivity, which is on the critical path forimporting source code, has a platform check which could go away if Iinstead had platform-specific versions of the function that were assignedto a global variable at startup). I also know that people have a bad habitof latching on to micro-benchmark numbers, especially for something likeimport which involves startup or can easily be measured. I mean I wroteimportlib.test.benchmark to help measure performance changes in anyalgorithmic changes I might make, but it isn't a real-world benchmark likewhat Unladen Swallow gave us (e.g. the two start-up benchmarks that usereal-world apps -- hg and bzr -- aren't available on Python 3 so onlynormal_startup and nosite_startup can be used ATM).IOW I really do not look forward to someone saying "importlib is so muchslower at importing a module containing ``pass``" when (a) that neverhappens, and (b) most programs do not spend their time importing butinstead doing interesting work.For instance, right now importlib does ``python -c "import decimal"``(which, BTW, is the largest module in the stdlib) 25% slower on my machinewith a pydebug build (a non-debug build would probably be in my favor as Ihave more Python objects being used in importlib and thus more sanitychecks). But if you do something (very) slightly more interesting like``python -m calendar`` where is a slight amount of work then importlib iscurrently only 16% slower. So it all depends on how we measure (as usual).So, if there is going to be some baseline performance target I need to hitto make people happy I would prefer to know what that (real-world)benchmark is and what the performance target is going to be on a non-debugbuild. And if people are not worried about the performance then I'm happywith that as well. =)-------------- next part --------------An HTML attachment was scrubbed...URL: <http://mail.python.org/pipermail/python-dev/attachments/20120207/1b50b1cb/attachment.html>
More information about the Python-Devmailing list
[8]ページ先頭