lazy use for optional import
I have seen some interest into lazy functionality implementation. I wondered if it can be linked with optional import. PEP 8 http://www.python.org/dev/peps/pep-0008/ authoritatively states: Imports are always put at the top of the file, just after any module comments and docstrings, and before module globals and constants. So, if we want to stick to PEP8 with non mandatory import, we have to catch the import errors, or jail the class or function using extra functionnality. Why not using the potential lazy keyword to have a nice way to deal with it? For example: lazy import pylab as pl # do nothing for now
# do stuff
def plot(*args): pl.figure() # Will raise an ImportError at this point pl.plot(...)
That way, our library will raise an ImportError only on plot func usage with an explicit traceback : if matplotlib is not installed, we will have the line where it is used for the first time and we will have the name of the faulty library.
On Wed, Mar 1, 2017 at 2:31 AM, Nicolas Cellier
For example:
lazy import pylab as pl # do nothing for now
# do stuff
def plot(*args): pl.figure() # Will raise an ImportError at this point pl.plot(...)
This can already be achieved without introducing a new keyword by using LazyLoader: https://docs.python.org/3/library/importlib.html#importlib.util.LazyLoader --Berker
Going through machinations to satisfy PEP 8 makes no sense -- it's s style *guide* -- that's it. -CHB On Tue, Feb 28, 2017 at 3:31 PM, Nicolas Cellier < contact@nicolas-cellier.net> wrote:
I have seen some interest into lazy functionality implementation.
I wondered if it can be linked with optional import.
PEP 8 http://www.python.org/dev/peps/pep-0008/ authoritatively states:
Imports are always put at the top of the file, just after any module comments and docstrings, and before module globals and constants.
So, if we want to stick to PEP8 with non mandatory import, we have to catch the import errors, or jail the class or function using extra functionnality.
Why not using the potential lazy keyword to have a nice way to deal with it?
For example:
lazy import pylab as pl # do nothing for now
# do stuff
def plot(*args): pl.figure() # Will raise an ImportError at this point pl.plot(...)
That way, our library will raise an ImportError only on plot func usage with an explicit traceback : if matplotlib is not installed, we will have the line where it is used for the first time and we will have the name of the faulty library.
_______________________________________________ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
-- Christopher Barker, Ph.D. Oceanographer Emergency Response Division NOAA/NOS/OR&R (206) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317 main reception Chris.Barker@noaa.gov
I really think the whole "lazy" idea is misguided. If it's possible for the
interpreter to determine automatically when it needs to force evaluation of
a lazy expression or statement, then why not make *all* expressions and
statements lazy by default? I think it's pretty clear when to force
evaluation: 1) when the result is used in a control flow
statement/expression 2) when the result is output (file, network, or other
I/O) and 3) evaluate all pending lazy code before releasing the GIL. At
that point, why not make lazy evaluation an implicit feature of the
language, like the garbage collector.
On Wed, Mar 1, 2017 at 8:58 PM, Chris Barker
Going through machinations to satisfy PEP 8 makes no sense -- it's s style *guide* -- that's it.
-CHB
On Tue, Feb 28, 2017 at 3:31 PM, Nicolas Cellier < contact@nicolas-cellier.net> wrote:
I have seen some interest into lazy functionality implementation.
I wondered if it can be linked with optional import.
PEP 8 http://www.python.org/dev/peps/pep-0008/ authoritatively states:
Imports are always put at the top of the file, just after any module comments and docstrings, and before module globals and constants.
So, if we want to stick to PEP8 with non mandatory import, we have to catch the import errors, or jail the class or function using extra functionnality.
Why not using the potential lazy keyword to have a nice way to deal with it?
For example:
lazy import pylab as pl # do nothing for now
# do stuff
def plot(*args): pl.figure() # Will raise an ImportError at this point pl.plot(...)
That way, our library will raise an ImportError only on plot func usage with an explicit traceback : if matplotlib is not installed, we will have the line where it is used for the first time and we will have the name of the faulty library.
_______________________________________________ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
--
Christopher Barker, Ph.D. Oceanographer
Emergency Response Division NOAA/NOS/OR&R (206) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317 main reception
Chris.Barker@noaa.gov
_______________________________________________ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
On Fri, Mar 3, 2017 at 10:10 AM, Abe Dillon
I really think the whole "lazy" idea is misguided. If it's possible for the interpreter to determine automatically when it needs to force evaluation of a lazy expression or statement, then why not make *all* expressions and statements lazy by default? I think it's pretty clear when to force evaluation: 1) when the result is used in a control flow statement/expression 2) when the result is output (file, network, or other I/O) and 3) evaluate all pending lazy code before releasing the GIL. At that point, why not make lazy evaluation an implicit feature of the language, like the garbage collector.
4) When the evaluation will have side effects. Making everything lazy is fine when you can guarantee that there's no visible effect (modulo performance) of evaluating things in a different order, or not evaluating some of them at all. In Python, that can't be guaranteed, so universal laziness is way too dangerous. Think of all the problems people have with getting their heads around multithreading, and consider that this is basically going to take your code and turn it into a bunch of threads, and join on those threads only when there's a reason to. Debugging becomes highly non-deterministic, because adding a quick little 'print' call to see what's going on might force evaluation a little sooner, which means X happens before Y, but without that print, Y happens before X... aeons of fun. No, if laziness is added to Python, it *must* be under programmer control. ChrisA
участники (5)
-
Abe Dillon -
Berker Peksağ -
Chris Angelico -
Chris Barker -
Nicolas Cellier