Make import an expression
Hi all, Just a curious idea I had. The subject says it all. "import" is currently a statement, which means it cannot be used inside anything else. Currently, the only way to import a module inside an expression is to use the __import__ function, which is both cumbersome and takes up more space (which is disadvantageous in things like code golf). I propose making "import" an expression, thus allowing the syntactic sugar of "import module" -> "__import__('module')" to be graduated to the expression level. Because of operator precedence, I suspect that in most cases one would need to surround the expression with parentheses. An additional effect that is not seen with using __import__ is that the module's name is bound to the current scope the way it is with a normal import statement. Examples of where this could be used: Importing on the fly to generate one value: secret = (import random).randint(1, 100) Quick use of itertools in generator expressions: (i * i for i in (import itertools).accumulate(generate_numbers())) Re-using a function from a module after importing it in an expression: b = a * (import math).tan(math.radians(45)) #math.radians is valid because (import math) binds "math" to the current scope What are your thoughts? Sharing, Ken Hilton;
Hi Ken Thank you for your clear subject line. As you probably already know, in Python, assignments are not expressions, and so we can't write if (a=get()): # do something with a One reason for this is, perhaps, that "Explicit is better than implicit" (as in The Zen of Python, via "import this"). Your last example of the intended semantics is b = a * (import math).tan(math.radians(45)) which demonstrate that you intend the statement a = (import math) to have the side effect of assigning a value to the identifier 'math'. I'm concerned that your intended semantics are similar to "assignment as an expression", and so wouldn't fit in well with the rest of Python. More concretely, when reading a module I expect to see all the imports at the top, much like a recipe starts with a list of ingredients. It may be that the documentation regarding import and __import__ can be improved, and that there's a practical problem behind your experience that __import__ is cumbersome and takes space. with best regards Jonathan On Sat, Jul 14, 2018 at 9:24 AM, Ken Hilton <kenlhilton@gmail.com> wrote:
First thought is that ‘code golf’ is unlikely to be a big reason to add something like this, especially since there is already a way to do what you want, just spelled somewhat longer. Your syntax is likely going to add complexity to the expression parser, and if as you indicate most of the time your going to need the parentheses, you might as well spell (import xx) as import(xx) which makes a lot less of a change to the parser. This gives us two distinctions from what we currently have, the operation is spelt as import instead of __import__, and we have dropped the need for putting quotes around the module name. I don’t see a major issue with the first point, (except for the Zen of having only 1 obvious way to do something) though it might make sense to look at the discussion when __import__ was added to see why it was spelt that way. For the second, you are basically just removing the need to put the module name in quotes, but this then loses the ability to put a variable name there to allow making the module to use be changed at run-time.
Hi Ken Thank you for your clear subject line. As you probably already know, in Python, assignments are not expressions, and so we can't write if (a=get()): # do something with a One reason for this is, perhaps, that "Explicit is better than implicit" (as in The Zen of Python, via "import this"). Your last example of the intended semantics is b = a * (import math).tan(math.radians(45)) which demonstrate that you intend the statement a = (import math) to have the side effect of assigning a value to the identifier 'math'. I'm concerned that your intended semantics are similar to "assignment as an expression", and so wouldn't fit in well with the rest of Python. More concretely, when reading a module I expect to see all the imports at the top, much like a recipe starts with a list of ingredients. It may be that the documentation regarding import and __import__ can be improved, and that there's a practical problem behind your experience that __import__ is cumbersome and takes space. with best regards Jonathan On Sat, Jul 14, 2018 at 9:24 AM, Ken Hilton <kenlhilton@gmail.com> wrote:
First thought is that ‘code golf’ is unlikely to be a big reason to add something like this, especially since there is already a way to do what you want, just spelled somewhat longer. Your syntax is likely going to add complexity to the expression parser, and if as you indicate most of the time your going to need the parentheses, you might as well spell (import xx) as import(xx) which makes a lot less of a change to the parser. This gives us two distinctions from what we currently have, the operation is spelt as import instead of __import__, and we have dropped the need for putting quotes around the module name. I don’t see a major issue with the first point, (except for the Zen of having only 1 obvious way to do something) though it might make sense to look at the discussion when __import__ was added to see why it was spelt that way. For the second, you are basically just removing the need to put the module name in quotes, but this then loses the ability to put a variable name there to allow making the module to use be changed at run-time.
participants (5)
-
Chris Angelico -
Jonathan Fine -
Ken Hilton -
MRAB -
Richard Damon