2017-06-30 14:31 GMT+02:00 INADA Naoki <songofacandy(a)gmail.com>:
> This issue may be relatively easy and small.
> I think it's good for your first step of successful optimization.
I'm not sure about "easy and small", but since I wrote a similar patch
5 years ago (and that I wrote _PyUnicodeWriter), I would be interested
to see benchmark results in 2017 :-) As I wrote in the issue, two
different implementations for StringIO was be required according to
the author of the C implementation of StringIO, Antoine Pitrou.
Victor
Hi, Bhavishya.
I filed new issue: https://bugs.python.org/issue30815
This issue may be relatively easy and small.
I think it's good for your first step of successful optimization.
If you want to solve it, please assign yourself at issue tracker.
Regards,
INADA Naoki <songofacandy(a)gmail.com>
Hi,
FYI last year I proposed FAT Python as a GSoC project, but I failed to
pick a candidate. You may be interested by my project page:
http://fatoptimizer.readthedocs.io/en/latest/gsoc.html
And the TODO list:
http://fatoptimizer.readthedocs.io/en/latest/todo.html
The good news is that I rebased my FAT Python project recently on Git.
Previously, my fork was based on Mercurial, but CPython moved to Git
in the meanwhile.
To really test FAT Python, not only fatoptimizer, see instructions at:
https://faster-cpython.readthedocs.io/fat_python.html#getting-started
Sadly, it seems like there are bugs since I rebased my patches. Even
if I disabled function inlinling, I still get this strange error:
---
haypo@selma$ ./python -X fat -m test -v test_sys
...
test test_sys crashed -- Traceback (most recent call last):
...
File "/home/haypo/prog/python/fatpython/Lib/test/libregrtest/save_env.py",
line 286, in get_sys_argv
AttributeError: 'list' object has no attribute 'description'
---
It's a bad in the optimizer, I don't get it when the FAT mode is disabled:
---
haypo@selma$ ./python -m test test_sys
...
Tests result: SUCCESS
---
Moreover, it seems like once .pyc files are created in FAT mode,
non-FAT mode (default mode) still uses the optimized .pyc files, which
is a bad :-/
haypo@selma$ ./python -X fat -m test -v test_sys
^C
haypo@selma$ find -name "*.pyc"
...
./Lib/test/__pycache__/__main__.cpython-37.pyc
...
The filename should contain "fat" somewhere. I made a mistake in my
PEP 511 backport:
http://bugs.python.org/issue26145
Good luck with all these things :-) FAT Python is a big project. The
problem is that I failed to prove that it really makes Python faster.
I stopped the project just after Dave Malcolm implemented function
inlining (which is still experimental = buggy), whereas this
optimization is likely to make CPython faster in a significant way.
It's just that I lost motivation, I put too much energy in this
project :-) So I switch to something else (which was FASTCALL).
Victor
2017-06-28 7:07 GMT+02:00 Bhavishya <bhavishyagopesh(a)gmail.com>:
> Hello,
> As you might have seen(on ML) "Lazy-loading" didn't worked and increased the
> startup time instead.
>
> In the meantime I had started with "fat-python"(adding pure methods etc) so
> is that the right thing to do or you suggest something else...
>
> Thank You
> Regards,
> Bhavishya
Hello,
As you might have seen(on ML) "Lazy-loading" didn't worked and increased
the startup time instead.
In the meantime I had started with "fat-python"(adding pure methods etc)
so is that the right thing to do or you suggest something else...
Thank You
Regards,
Bhavishya
On Mon, 26 Jun 2017 at 01:07 Bhavishya <bhavishyagopesh(a)gmail.com> wrote:
> Hi,
> I'm having some trouble making the lazy_import "implicit", I tried
> following approaches:
>
> 1)overriding "__import__ " using 'builtins.__import__ =
> lazy_import.lazy_import_module' but this can't take more than 2 args
> whereas "__import__" takes upto 5 args, so now I have to make changes to
> "_bootstrap.py"(which I shouldn't probably make) and __init__.py to
> accomadate everything new.
>
Don't override __import__ basically ever.
>
> 2)Using "meta_path" and "path_hooks" to register custom "Loader" and
> "finder" but somehow it's breaking during 'make' ...probably due to
> 'finder'(unable to import stuff like '.org*')...Working on this.
>
I don't know what you mean by this, e.g. what is ".org*"?
>
> 3)The Whitelist option(that Antoine suggested) ,somewhat hardcode, i.e. to
> identify modules and in place of "import" add the lazy_import_module
> function.
>
I actually don't think that's what Antoine meant. I think he was suggesting
setting up a finder and loader as normal that would do lazy loading but
controlling it with a whitelist/blacklist to then potentially fail
accordingly so the normal finders/loaders would do the right thing.
>
> Any suggestion?
>
As I said in my other email, just don't bother with this right now. To
quickly see if things will be faster you should just edit the modules that
are imported at startup directly to use a lazy_import() function and
measure the performance.
-Brett
>
> Regards,
> Bhavishya
>
> On Sun, Jun 25, 2017 at 12:52 PM, Bhavishya <bhavishyagopesh(a)gmail.com>
> wrote:
>
>> Also, the "fatoptimizer" project's compile fails due to missing
>> "ma_version_tag" (and works on changing it to "ma_version").
>>
>> Regards,
>> Bhavishya
>>
>> On Sun, Jun 25, 2017 at 12:32 PM, Bhavishya <bhavishyagopesh(a)gmail.com>
>> wrote:
>>
>>> Hello,
>>> I have added the "lazy_import"
>>> <https://github.com/bhavishyagopesh/gsoc_2017/blob/master/python_startup_tim…>
>>> function but still working on adding it implicitly(To ensure that at
>>> startup it is actually used.)
>>>
>>> Thanks Antoine for the suggestion
>>>
>>> Regards,
>>> Bhavishya
>>>
>>> On Sat, Jun 24, 2017 at 9:30 PM, <speed-request(a)python.org> wrote:
>>>
>>>> Send Speed mailing list submissions to
>>>> speed(a)python.org
>>>>
>>>> To subscribe or unsubscribe via the World Wide Web, visit
>>>> https://mail.python.org/mailman/listinfo/speed
>>>> or, via email, send a message with subject or body 'help' to
>>>> speed-request(a)python.org
>>>>
>>>> You can reach the person managing the list at
>>>> speed-owner(a)python.org
>>>>
>>>> When replying, please edit your Subject line so it is more specific
>>>> than "Re: Contents of Speed digest..."
>>>>
>>>>
>>>> Today's Topics:
>>>>
>>>> 1. Re: Lazy-loading to decrease python_startup time (Brett Cannon)
>>>> 2. Re: Lazy-loading to decrease python_startup time (Antoine Pitrou)
>>>>
>>>>
>>>> ----------------------------------------------------------------------
>>>>
>>>> Message: 1
>>>> Date: Fri, 23 Jun 2017 23:03:57 +0000
>>>> From: Brett Cannon <brett(a)python.org>
>>>> To: Bhavishya <bhavishyagopesh(a)gmail.com>, speed(a)python.org, Ramya
>>>> Meruva <meruvaramya116(a)gmail.com>, Victor Stinner
>>>> <victor.stinner(a)gmail.com>
>>>> Subject: Re: [Speed] Lazy-loading to decrease python_startup time
>>>> Message-ID:
>>>> <CAP1=2W41_xTDt7gkuUWnmYA=+
>>>> Bz9Ox-XT-pAjtXkDGg4TDrY5Q(a)mail.gmail.com>
>>>> Content-Type: text/plain; charset="utf-8"
>>>>
>>>> On Fri, 23 Jun 2017 at 12:17 Bhavishya <bhavishyagopesh(a)gmail.com>
>>>> wrote:
>>>>
>>>> > As suggested, I'd like to discuss if lazy-loading is an option for
>>>> > improving python-startup time.And if could be done inside the scope
>>>> of a
>>>> > GSoc project.
>>>> >
>>>>
>>>> It's a possibility and it could be done in the scope of a GSoC project
>>>> easily. Basically what would be needed is an
>>>> importlib.util.lazy_import()
>>>> function which does mostly what is outlined in
>>>>
>>>> https://docs.python.org/3/library/importlib.html#approximating-importlib-im…
>>>> but
>>>> where the proper lazy loader is set on the spec object as an extra step.
>>>> Then every module that is used during startup would use
>>>> importlib.util.lazy_import() for importing instead of the normal import
>>>> statement. What this would do is help guarantee that all modules that
>>>> are
>>>> identified as part of startup never import a module needlessly as the
>>>> lazy
>>>> loader would simply postpone the load until necessary. This would also
>>>> allow for pulling out local imports that are currently done in modules
>>>> that
>>>> are a part of startup and make them global so they are more visible.
>>>>
>>>> But I have no idea if this will actually speed things up. :) At worst it
>>>> would slow things down ever so slightly due to the extra overhead of
>>>> lazy
>>>> loading for things that are known to be needed already during startup.
>>>> At
>>>> best, though, is we accidentally discover modules that are being
>>>> imported
>>>> needlessly at startup as well as not having to hide imports in functions
>>>> for performance. This fact that it may not be worth it is why I haven't
>>>> bothered to try it out yet.
>>>>
Hi,
I'm having some trouble making the lazy_import "implicit", I tried
following approaches:
1)overriding "__import__ " using 'builtins.__import__ =
lazy_import.lazy_import_module' but this can't take more than 2 args
whereas "__import__" takes upto 5 args, so now I have to make changes to
"_bootstrap.py"(which I shouldn't probably make) and __init__.py to
accomadate everything new.
2)Using "meta_path" and "path_hooks" to register custom "Loader" and
"finder" but somehow it's breaking during 'make' ...probably due to
'finder'(unable to import stuff like '.org*')...Working on this.
3)The Whitelist option(that Antoine suggested) ,somewhat hardcode, i.e. to
identify modules and in place of "import" add the lazy_import_module
function.
Any suggestion?
Regards,
Bhavishya
On Sun, Jun 25, 2017 at 12:52 PM, Bhavishya <bhavishyagopesh(a)gmail.com>
wrote:
> Also, the "fatoptimizer" project's compile fails due to missing
> "ma_version_tag" (and works on changing it to "ma_version").
>
> Regards,
> Bhavishya
>
> On Sun, Jun 25, 2017 at 12:32 PM, Bhavishya <bhavishyagopesh(a)gmail.com>
> wrote:
>
>> Hello,
>> I have added the "lazy_import"
>> <https://github.com/bhavishyagopesh/gsoc_2017/blob/master/python_startup_tim…>
>> function but still working on adding it implicitly(To ensure that at
>> startup it is actually used.)
>>
>> Thanks Antoine for the suggestion
>>
>> Regards,
>> Bhavishya
>>
>> On Sat, Jun 24, 2017 at 9:30 PM, <speed-request(a)python.org> wrote:
>>
>>> Send Speed mailing list submissions to
>>> speed(a)python.org
>>>
>>> To subscribe or unsubscribe via the World Wide Web, visit
>>> https://mail.python.org/mailman/listinfo/speed
>>> or, via email, send a message with subject or body 'help' to
>>> speed-request(a)python.org
>>>
>>> You can reach the person managing the list at
>>> speed-owner(a)python.org
>>>
>>> When replying, please edit your Subject line so it is more specific
>>> than "Re: Contents of Speed digest..."
>>>
>>>
>>> Today's Topics:
>>>
>>> 1. Re: Lazy-loading to decrease python_startup time (Brett Cannon)
>>> 2. Re: Lazy-loading to decrease python_startup time (Antoine Pitrou)
>>>
>>>
>>> ----------------------------------------------------------------------
>>>
>>> Message: 1
>>> Date: Fri, 23 Jun 2017 23:03:57 +0000
>>> From: Brett Cannon <brett(a)python.org>
>>> To: Bhavishya <bhavishyagopesh(a)gmail.com>, speed(a)python.org, Ramya
>>> Meruva <meruvaramya116(a)gmail.com>, Victor Stinner
>>> <victor.stinner(a)gmail.com>
>>> Subject: Re: [Speed] Lazy-loading to decrease python_startup time
>>> Message-ID:
>>> <CAP1=2W41_xTDt7gkuUWnmYA=+Bz9Ox-XT-pAjtXkDGg4TDrY5Q(a)mail.gm
>>> ail.com>
>>> Content-Type: text/plain; charset="utf-8"
>>>
>>> On Fri, 23 Jun 2017 at 12:17 Bhavishya <bhavishyagopesh(a)gmail.com>
>>> wrote:
>>>
>>> > As suggested, I'd like to discuss if lazy-loading is an option for
>>> > improving python-startup time.And if could be done inside the scope of
>>> a
>>> > GSoc project.
>>> >
>>>
>>> It's a possibility and it could be done in the scope of a GSoC project
>>> easily. Basically what would be needed is an importlib.util.lazy_import()
>>> function which does mostly what is outlined in
>>> https://docs.python.org/3/library/importlib.html#approximati
>>> ng-importlib-import-module
>>> but
>>> where the proper lazy loader is set on the spec object as an extra step.
>>> Then every module that is used during startup would use
>>> importlib.util.lazy_import() for importing instead of the normal import
>>> statement. What this would do is help guarantee that all modules that are
>>> identified as part of startup never import a module needlessly as the
>>> lazy
>>> loader would simply postpone the load until necessary. This would also
>>> allow for pulling out local imports that are currently done in modules
>>> that
>>> are a part of startup and make them global so they are more visible.
>>>
>>> But I have no idea if this will actually speed things up. :) At worst it
>>> would slow things down ever so slightly due to the extra overhead of lazy
>>> loading for things that are known to be needed already during startup. At
>>> best, though, is we accidentally discover modules that are being imported
>>> needlessly at startup as well as not having to hide imports in functions
>>> for performance. This fact that it may not be worth it is why I haven't
>>> bothered to try it out yet.
>>>
An easier way to guarantee its use is to have the lazy import print
something under 'Python -v' and then make sure every logged import has a
corresponding lazy message to go with it.
On Sun, Jun 25, 2017, 08:33 Bhavishya, <bhavishyagopesh(a)gmail.com> wrote:
> Hello,
> I have added the "lazy_import"
> <https://github.com/bhavishyagopesh/gsoc_2017/blob/master/python_startup_tim…>
> function but still working on adding it implicitly(To ensure that at
> startup it is actually used.)
>
> Thanks Antoine for the suggestion
>
> Regards,
> Bhavishya
>
> On Sat, Jun 24, 2017 at 9:30 PM, <speed-request(a)python.org> wrote:
>
>> Send Speed mailing list submissions to
>> speed(a)python.org
>>
>> To subscribe or unsubscribe via the World Wide Web, visit
>> https://mail.python.org/mailman/listinfo/speed
>> or, via email, send a message with subject or body 'help' to
>> speed-request(a)python.org
>>
>> You can reach the person managing the list at
>> speed-owner(a)python.org
>>
>> When replying, please edit your Subject line so it is more specific
>> than "Re: Contents of Speed digest..."
>>
>>
>> Today's Topics:
>>
>> 1. Re: Lazy-loading to decrease python_startup time (Brett Cannon)
>> 2. Re: Lazy-loading to decrease python_startup time (Antoine Pitrou)
>>
>>
>> ----------------------------------------------------------------------
>>
>> Message: 1
>> Date: Fri, 23 Jun 2017 23:03:57 +0000
>> From: Brett Cannon <brett(a)python.org>
>> To: Bhavishya <bhavishyagopesh(a)gmail.com>, speed(a)python.org, Ramya
>> Meruva <meruvaramya116(a)gmail.com>, Victor Stinner
>> <victor.stinner(a)gmail.com>
>> Subject: Re: [Speed] Lazy-loading to decrease python_startup time
>> Message-ID:
>> <CAP1=2W41_xTDt7gkuUWnmYA=+
>> Bz9Ox-XT-pAjtXkDGg4TDrY5Q(a)mail.gmail.com>
>> Content-Type: text/plain; charset="utf-8"
>>
>> On Fri, 23 Jun 2017 at 12:17 Bhavishya <bhavishyagopesh(a)gmail.com> wrote:
>>
>> > As suggested, I'd like to discuss if lazy-loading is an option for
>> > improving python-startup time.And if could be done inside the scope of a
>> > GSoc project.
>> >
>>
>> It's a possibility and it could be done in the scope of a GSoC project
>> easily. Basically what would be needed is an importlib.util.lazy_import()
>> function which does mostly what is outlined in
>>
>> https://docs.python.org/3/library/importlib.html#approximating-importlib-im…
>> but
>> where the proper lazy loader is set on the spec object as an extra step.
>> Then every module that is used during startup would use
>> importlib.util.lazy_import() for importing instead of the normal import
>> statement. What this would do is help guarantee that all modules that are
>> identified as part of startup never import a module needlessly as the lazy
>> loader would simply postpone the load until necessary. This would also
>> allow for pulling out local imports that are currently done in modules
>> that
>> are a part of startup and make them global so they are more visible.
>>
>> But I have no idea if this will actually speed things up. :) At worst it
>> would slow things down ever so slightly due to the extra overhead of lazy
>> loading for things that are known to be needed already during startup. At
>> best, though, is we accidentally discover modules that are being imported
>> needlessly at startup as well as not having to hide imports in functions
>> for performance. This fact that it may not be worth it is why I haven't
>> bothered to try it out yet.
>>
Also, the "fatoptimizer" project's compile fails due to missing
"ma_version_tag" (and works on changing it to "ma_version").
Regards,
Bhavishya
On Sun, Jun 25, 2017 at 12:32 PM, Bhavishya <bhavishyagopesh(a)gmail.com>
wrote:
> Hello,
> I have added the "lazy_import"
> <https://github.com/bhavishyagopesh/gsoc_2017/blob/master/python_startup_tim…>
> function but still working on adding it implicitly(To ensure that at
> startup it is actually used.)
>
> Thanks Antoine for the suggestion
>
> Regards,
> Bhavishya
>
> On Sat, Jun 24, 2017 at 9:30 PM, <speed-request(a)python.org> wrote:
>
>> Send Speed mailing list submissions to
>> speed(a)python.org
>>
>> To subscribe or unsubscribe via the World Wide Web, visit
>> https://mail.python.org/mailman/listinfo/speed
>> or, via email, send a message with subject or body 'help' to
>> speed-request(a)python.org
>>
>> You can reach the person managing the list at
>> speed-owner(a)python.org
>>
>> When replying, please edit your Subject line so it is more specific
>> than "Re: Contents of Speed digest..."
>>
>>
>> Today's Topics:
>>
>> 1. Re: Lazy-loading to decrease python_startup time (Brett Cannon)
>> 2. Re: Lazy-loading to decrease python_startup time (Antoine Pitrou)
>>
>>
>> ----------------------------------------------------------------------
>>
>> Message: 1
>> Date: Fri, 23 Jun 2017 23:03:57 +0000
>> From: Brett Cannon <brett(a)python.org>
>> To: Bhavishya <bhavishyagopesh(a)gmail.com>, speed(a)python.org, Ramya
>> Meruva <meruvaramya116(a)gmail.com>, Victor Stinner
>> <victor.stinner(a)gmail.com>
>> Subject: Re: [Speed] Lazy-loading to decrease python_startup time
>> Message-ID:
>> <CAP1=2W41_xTDt7gkuUWnmYA=+Bz9Ox-XT-pAjtXkDGg4TDrY5Q(a)mail.gm
>> ail.com>
>> Content-Type: text/plain; charset="utf-8"
>>
>> On Fri, 23 Jun 2017 at 12:17 Bhavishya <bhavishyagopesh(a)gmail.com> wrote:
>>
>> > As suggested, I'd like to discuss if lazy-loading is an option for
>> > improving python-startup time.And if could be done inside the scope of a
>> > GSoc project.
>> >
>>
>> It's a possibility and it could be done in the scope of a GSoC project
>> easily. Basically what would be needed is an importlib.util.lazy_import()
>> function which does mostly what is outlined in
>> https://docs.python.org/3/library/importlib.html#approximati
>> ng-importlib-import-module
>> but
>> where the proper lazy loader is set on the spec object as an extra step.
>> Then every module that is used during startup would use
>> importlib.util.lazy_import() for importing instead of the normal import
>> statement. What this would do is help guarantee that all modules that are
>> identified as part of startup never import a module needlessly as the lazy
>> loader would simply postpone the load until necessary. This would also
>> allow for pulling out local imports that are currently done in modules
>> that
>> are a part of startup and make them global so they are more visible.
>>
>> But I have no idea if this will actually speed things up. :) At worst it
>> would slow things down ever so slightly due to the extra overhead of lazy
>> loading for things that are known to be needed already during startup. At
>> best, though, is we accidentally discover modules that are being imported
>> needlessly at startup as well as not having to hide imports in functions
>> for performance. This fact that it may not be worth it is why I haven't
>> bothered to try it out yet.
>>
Hello,
I have added the "lazy_import"
<https://github.com/bhavishyagopesh/gsoc_2017/blob/master/python_startup_tim…>
function but still working on adding it implicitly(To ensure that at
startup it is actually used.)
Thanks Antoine for the suggestion
Regards,
Bhavishya
On Sat, Jun 24, 2017 at 9:30 PM, <speed-request(a)python.org> wrote:
> Send Speed mailing list submissions to
> speed(a)python.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
> https://mail.python.org/mailman/listinfo/speed
> or, via email, send a message with subject or body 'help' to
> speed-request(a)python.org
>
> You can reach the person managing the list at
> speed-owner(a)python.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of Speed digest..."
>
>
> Today's Topics:
>
> 1. Re: Lazy-loading to decrease python_startup time (Brett Cannon)
> 2. Re: Lazy-loading to decrease python_startup time (Antoine Pitrou)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Fri, 23 Jun 2017 23:03:57 +0000
> From: Brett Cannon <brett(a)python.org>
> To: Bhavishya <bhavishyagopesh(a)gmail.com>, speed(a)python.org, Ramya
> Meruva <meruvaramya116(a)gmail.com>, Victor Stinner
> <victor.stinner(a)gmail.com>
> Subject: Re: [Speed] Lazy-loading to decrease python_startup time
> Message-ID:
> <CAP1=2W41_xTDt7gkuUWnmYA=+Bz9Ox-XT-pAjtXkDGg4TDrY5Q@mail.
> gmail.com>
> Content-Type: text/plain; charset="utf-8"
>
> On Fri, 23 Jun 2017 at 12:17 Bhavishya <bhavishyagopesh(a)gmail.com> wrote:
>
> > As suggested, I'd like to discuss if lazy-loading is an option for
> > improving python-startup time.And if could be done inside the scope of a
> > GSoc project.
> >
>
> It's a possibility and it could be done in the scope of a GSoC project
> easily. Basically what would be needed is an importlib.util.lazy_import()
> function which does mostly what is outlined in
> https://docs.python.org/3/library/importlib.html#approximating-importlib-
> import-module
> but
> where the proper lazy loader is set on the spec object as an extra step.
> Then every module that is used during startup would use
> importlib.util.lazy_import() for importing instead of the normal import
> statement. What this would do is help guarantee that all modules that are
> identified as part of startup never import a module needlessly as the lazy
> loader would simply postpone the load until necessary. This would also
> allow for pulling out local imports that are currently done in modules that
> are a part of startup and make them global so they are more visible.
>
> But I have no idea if this will actually speed things up. :) At worst it
> would slow things down ever so slightly due to the extra overhead of lazy
> loading for things that are known to be needed already during startup. At
> best, though, is we accidentally discover modules that are being imported
> needlessly at startup as well as not having to hide imports in functions
> for performance. This fact that it may not be worth it is why I haven't
> bothered to try it out yet.
>
On Sat, 24 Jun 2017 16:28:29 +0000
Brett Cannon <brett(a)python.org> wrote:
> >
> > My experience is that:
> > - you want lazy imports to be implicit, i.e. they should work using the
> > "import" statement and not any special syntax or function invocation
> > - you want a blacklist and/or whitelist mechanism to restrict lazy
> > imports to a particular set of modules and packages, because some
> > modules may not play well with lazy importing (e.g. anything that
> > registers plugins, specializations -- think singledispatch --, etc.)
> >
> > For example, I may want to register the "tornado", "asyncio" and "numpy"
> > namespaces / packages for lazy importing, but not the "numba" namespace
> > as it uses registration mechanisms quite heavily.
> >
> > (and the stdlib could be part of the default lazy import whitelist)
> >
>
> That's all true for an end user's application, but for the stdlib where
> there is no knock-on effects from dependencies not being loaded lazily I
> don't think it's quite as critical. Plus lazy loading does make debugging
> harder by making loads that trigger an exception happen at the line of
> first use instead of at the import line, so I don't know if it's desirable
> to automatically make the whole stdlib be lazily loaded from the outset
> (which is what would be required since doing it in e.g. sitecustomize.py
> wouldn't happen until after startup anyway).
Yes, you are right. I was assuming that if we take the time to include
a lazy import system, we'd make it available for third-party
applications, though ;-)
Regards
Antoine.
