Re: [Python-ideas] "maybe import"?
On Thu Dec 26 2013 at 8:57:42 PM, Gregory P. Smith <greg@krypto.org> wrote:
Such idioms are common. Though I don't think we should encourage their use.
Is this a case of "we shouldn't encourage optional dependencies" or "we shouldn't encourage this kind of idiom as a means of implementing optional dependencies" - and if the latter, what alternative would you point people at instead?
We shouldn't encourage optional dependencies. They often make code harder to reason about or harder to read. On Thursday, December 26, 2013, Amber Yust wrote:
On Thu Dec 26 2013 at 8:57:42 PM, Gregory P. Smith <greg@krypto.org<javascript:_e({}, 'cvml', 'greg@krypto.org');>> wrote:
Such idioms are common. Though I don't think we should encourage their use.
Is this a case of "we shouldn't encourage optional dependencies" or "we shouldn't encourage this kind of idiom as a means of implementing optional dependencies" - and if the latter, what alternative would you point people at instead?
-- --Guido van Rossum (on iPad)
agreed. and the try/except pattern also allows for try: import thing except ImportError: import slower_thing_with_same_api as thing 2013/12/27 Guido van Rossum <guido@python.org>
We shouldn't encourage optional dependencies. They often make code harder to reason about or harder to read.
On Thursday, December 26, 2013, Amber Yust wrote:
On Thu Dec 26 2013 at 8:57:42 PM, Gregory P. Smith <greg@krypto.org> wrote:
Such idioms are common. Though I don't think we should encourage their use.
Is this a case of "we shouldn't encourage optional dependencies" or "we shouldn't encourage this kind of idiom as a means of implementing optional dependencies" - and if the latter, what alternative would you point people at instead?
-- --Guido van Rossum (on iPad)
_______________________________________________ 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 Dec 27 2013 at 12:33:11 AM, Guido van Rossum <guido@python.org> wrote:
We shouldn't encourage optional dependencies. They often make code harder to reason about or harder to read.
Is there a better alternative for utilizing functionality that may vary in availability from platform to platform?
On Dec 27, 2013, at 1:34, Amber Yust <amber.yust@gmail.com> wrote:
On Fri Dec 27 2013 at 12:33:11 AM, Guido van Rossum <guido@python.org> wrote:
We shouldn't encourage optional dependencies. They often make code harder to reason about or harder to read.
Is there a better alternative for utilizing functionality that may vary in availability from platform to platform?
The only way to use this would be to then continually check "if foo:" all throughout your module, to use it if present and do something else if not. I suspect that is a bigger readability/comprehensibility problem than the extra lines of code up top. And in many cases, once you reorganize your code to solve that problem, this one goes away as well.
_______________________________________________ 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 27 December 2013 19:34, Amber Yust <amber.yust@gmail.com> wrote:
On Fri Dec 27 2013 at 12:33:11 AM, Guido van Rossum <guido@python.org> wrote:
We shouldn't encourage optional dependencies. They often make code harder to reason about or harder to read.
Is there a better alternative for utilizing functionality that may vary in availability from platform to platform?
The most common approach I've seen is a compatibility module, so most code in the application just does something like: from myapp.foo_compat import foo and only foo_compat has the try/except logic. Depending on the number of optional dependencies and the cost of importing them even when they're not needed, this can be done on a per-dependency basis, or as a single compatibility module that handles all the optional dependencies. Cheers, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia
participants (5)
-
Amber Yust -
Andrew Barnert -
Guido van Rossum -
Nick Coghlan -
Philipp A.