Mailman 3 June 2017 - Speed

Re: [Speed] About issue 30815
by Victor Stinner 30 Jun '17

30 Jun '17

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

1 0

About issue 30815
by INADA Naoki 30 Jun '17

30 Jun '17

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>

1 0

Re: [Speed] To start work on "fat-python".
by Victor Stinner 28 Jun '17

28 Jun '17

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

1 0

To start work on "fat-python".
by Bhavishya 28 Jun '17

28 Jun '17

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

1 0

Re: [Speed] Speed Digest, Vol 36, Issue 1
by Brett Cannon 26 Jun '17

26 Jun '17

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

1 0

Re: [Speed] Speed Digest, Vol 36, Issue 1
by Bhavishya 26 Jun '17

26 Jun '17

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

1 0

Re: [Speed] Speed Digest, Vol 36, Issue 1
by Brett Cannon 25 Jun '17

25 Jun '17

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

1 0

Re: [Speed] Speed Digest, Vol 36, Issue 1
by Bhavishya 25 Jun '17

25 Jun '17

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

1 0

Re: [Speed] Speed Digest, Vol 36, Issue 1
by Bhavishya 25 Jun '17

25 Jun '17

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

1 0

Re: [Speed] Lazy-loading to decrease python_startup time
by Antoine Pitrou 24 Jun '17

24 Jun '17

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.

2 1