Jeroen Ruigrok van der Werven wrote:
> [Half tongue-in-cheek]
>
> -On [20080104 08:04], Drew Perttula ([EMAIL PROTECTED]) wrote:
>> When I saw the OP, I actually wondered why people whose codebases are
>> "filled" with the same try/except block over and over hadn't just
>> written their own import_with_alternative function in the first place.
>
> Because you would have to import it as well in order to use it? ;)
>
The keyphrase was "people whose codebases are 'filled' with ..." If they
are maintaining a codebase, then I am sure adding one utility function
to their library would be trivial. Or if you have enough of them in one
file.. dedicating 7 lines of code for:
def import_any(*names):
for name in names:
try:
return __import__(name)
except StandardError:
pass
raise ImportError('no importable names')
, seems like a bargain for readability. Or to include the "None" case
that people have brought up, we can spare 2 more lines:
def import_any(*names, **kwargs):
required = kwargs.get('required', True)
for name in names:
try:
return __import__(name)
except StandardError:
pass
if required:
raise ImportError('no importable names')
If nothing else, writing this email will remind me to avoid this
try/except pattern in future codebases, if I have more than 1 instance
of it (right about the break even point).
-Scott
--
Scott Dial
[EMAIL PROTECTED]
[EMAIL PROTECTED]
_______________________________________________
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
