5 ms·

I always wondered why the import syntax is so different for the two things: import mpmath as mp from mpmath import mp IMO that's the root cause of that ki

by micw 3y ago

I always wondered why the import syntax is so different for the two things: import mpmath as mp from mpmath import mp IMO that's the root cause of that kind of user errors. Why not just import mpmath.mp as mp or something that has basically the same syntax for importing an object as for importing the module?

paulluuk 3y ago
> Why not just `import mpmath.mp as mp` or something that has basically the same syntax for importing an object as for importing the module? Because if we applied that as a "rule", then an import like this: from keras.applications.vgg16 import VGG16, preprocess_input Would become import keras.applications.vgg16.VGG16 as VGG16 import keras.applications.vgg16.preprocess_input as preprocess_input Which seems unnecessarily long. Instead, I personally don't understand why everyone shortens numpy to np. I suspect it's because it's mostly used by people with a math background, who also believe that greek letters make for better variable names than actual spelled out variable names.
- TrianguloY 3y ago
  It would become import keras.applications.vgg16.VGG16 import keras.applications.vgg16.preprocess_input Which is still long but more explicit (and python likes that). Imports cannot have dots so by default it should use the same name as the object itself, which is the word after the last dot. If still necessary to differentiate, the perfect alternative would be to flip it. import VGG16, preprocess_input from keras.applications.vgg16 In fact I've always find it strange that an import needs different syntax depending on how you use it. If all imports started with "import" it would be much more consistent and easy to read.
  - dist-epoch 3y ago
    Python imports don't work like in Java. import keras.applications.vgg16.VGG16 import keras.applications.vgg16.preprocess_input preprocess_input(...) # ERROR keras.applications.vgg16.preprocess_input(...) # CORRECT
  - Timon3 3y ago
    import VGG16, preprocess_input from keras.applications.vgg16 This approach has a couple of downsides: - no editor autocomplete while typing (JS modules have the same downside) - more difficult to read multiple imports from modules in the same hierarchy (since the "from" parts aren't aligned) - import sorting becomes less clear (do you sort by imported things or by the module you import from?) JS uses your suggested format, and I dislike it much more than the Python equivalent due to the reasons stated above.
- deleted 3y ago
  [deleted]
- codexb 3y ago
  I agree, both those libraries just have bad api conventions leading to user errors. They've just become so pervasive now that bad habits have become the standard convention in those spaces.
- dkersten 3y ago
  In Clojure we have (using :require in the namespace declaration): (:require [foo.bar]) (:require [foo.bar :as quux]) (:require [foo.bar :refer [x y z]]) …etc There’s no reason you couldn’t have similar syntax in Python.
wiredfool 3y ago
I dislike the renaming of imports unless it's something that needs to be done for specific reasons, like two different conflicting names or doing something sneaky. At that point though, it's still generally possible to work around it with more qualified names. It's something of a lost cause in the numpy/pandas ecosystem though, since every single example has them renamed this way and it induces just the cognitive load that I'm trying to avoid.
- fluidcruft 3y ago
  Franky, it's because python is only barely tolerable vs actual array-centered languages like Fortran or Matlab or Julia. It's bad enough having to sprinkle "np." and extra parentheses of various flavors and dangling commas everywhere along with whitespace eating up columns. The comparison should be with Matlab or Julia. Most people writing numpy-based code are trying to replace Matlab and Fortran. Maybe you could be pedantically happy if "numpy" itself were renamed "np"? Then we can just "import np" and spare you from a DSL nightmare and ourselves from a few keystrokes while you can move on to complaining about obtuse, ungoogleable and inscrutable package names instead.
  - wiredfool 3y ago
    No, that's not it, that's just a thing that happens. I'm thinking more of a community that can't decide between from foo import toolkit from foo import toolkit as tk from foo.toolkit import thing1, thing2 from not.foo_toolkit import internalThing1, internalThing2 and the pain it is to deal with reading code there.
OJFord 3y ago
I thought you were going to suggest: import mp from mpmath I do dislike that the order changes, even though it is consistent in terms of the 'path', because it means everyone groups by keyword, which then puts paths out of order/same ones separate anyway.
- mxz3000 3y ago
  also means no autocomplete with the from bit first
fluidcruft 3y ago
import mpmath.mp as mp Doesn't work in this case because mp isn't a submodule of mpmath. You will get "ModuleNotFoundError: No module named 'mpmath.mp'" The "from" is what dives into a module and takes something out. It's not just defining a syntactic macro. You would have to do something closer to this: import mpmath mp = mpmath.mp del mpmath to replace what "from" does.
- PurpleRamen 3y ago
  That's an implementation-detail. Nothing prevents the import from diving automatically into the file. But doing so would open the door for name-shadowing, as with a package you could have a separate mp.py for import, or a definition of mp in __init__.py. And this would be another confusion for people, and a performance-problem maybe.
pfranz 3y ago
I get where you're coming from, but those lines aren't equivalent (which may be why its confusing). "as" changes the name and can be used for both: import mpmath as mpmath_module from mpmath import mp as mp_context "import" and "from" always address modules (directories and files) from/import extracts objects from modules and "as" swaps out the name. It's confusing because "from/import" reaches inside a package and Python uses the same delimiter for Namespaces/Modules, Classes, and Properties. urllib.request.HTTPBasicAuthHandler.auth_header is Namespace.Module.Class.Property You have to use each one differently...but you just have to know. You get some small context clues based on capitalization or knowing the first thing at the top of the file is a Namespace or Module.

by micw 3y ago

paulluuk 3y ago

> Why not just `import mpmath.mp as mp` or something that has basically the same syntax for importing an object as for importing the module? Because if we applied that as a "rule", then an import like this: from keras.applications.vgg16 import VGG16, preprocess_input Would become import keras.applications.vgg16.VGG16 as VGG16 import keras.applications.vgg16.preprocess_input as preprocess_input Which seems unnecessarily long. Instead, I personally don't understand why everyone shortens numpy to np. I suspect it's because it's mostly used by people with a math background, who also believe that greek letters make for better variable names than actual spelled out variable names.

TrianguloY 3y ago
It would become import keras.applications.vgg16.VGG16 import keras.applications.vgg16.preprocess_input Which is still long but more explicit (and python likes that). Imports cannot have dots so by default it should use the same name as the object itself, which is the word after the last dot. If still necessary to differentiate, the perfect alternative would be to flip it. import VGG16, preprocess_input from keras.applications.vgg16 In fact I've always find it strange that an import needs different syntax depending on how you use it. If all imports started with "import" it would be much more consistent and easy to read.
- dist-epoch 3y ago
  Python imports don't work like in Java. import keras.applications.vgg16.VGG16 import keras.applications.vgg16.preprocess_input preprocess_input(...) # ERROR keras.applications.vgg16.preprocess_input(...) # CORRECT
- Timon3 3y ago
  import VGG16, preprocess_input from keras.applications.vgg16 This approach has a couple of downsides: - no editor autocomplete while typing (JS modules have the same downside) - more difficult to read multiple imports from modules in the same hierarchy (since the "from" parts aren't aligned) - import sorting becomes less clear (do you sort by imported things or by the module you import from?) JS uses your suggested format, and I dislike it much more than the Python equivalent due to the reasons stated above.
deleted 3y ago
[deleted]
codexb 3y ago
I agree, both those libraries just have bad api conventions leading to user errors. They've just become so pervasive now that bad habits have become the standard convention in those spaces.
dkersten 3y ago
In Clojure we have (using :require in the namespace declaration): (:require [foo.bar]) (:require [foo.bar :as quux]) (:require [foo.bar :refer [x y z]]) …etc There’s no reason you couldn’t have similar syntax in Python.

wiredfool 3y ago

I dislike the renaming of imports unless it's something that needs to be done for specific reasons, like two different conflicting names or doing something sneaky. At that point though, it's still generally possible to work around it with more qualified names. It's something of a lost cause in the numpy/pandas ecosystem though, since every single example has them renamed this way and it induces just the cognitive load that I'm trying to avoid.

fluidcruft 3y ago
Franky, it's because python is only barely tolerable vs actual array-centered languages like Fortran or Matlab or Julia. It's bad enough having to sprinkle "np." and extra parentheses of various flavors and dangling commas everywhere along with whitespace eating up columns. The comparison should be with Matlab or Julia. Most people writing numpy-based code are trying to replace Matlab and Fortran. Maybe you could be pedantically happy if "numpy" itself were renamed "np"? Then we can just "import np" and spare you from a DSL nightmare and ourselves from a few keystrokes while you can move on to complaining about obtuse, ungoogleable and inscrutable package names instead.
- wiredfool 3y ago
  No, that's not it, that's just a thing that happens. I'm thinking more of a community that can't decide between from foo import toolkit from foo import toolkit as tk from foo.toolkit import thing1, thing2 from not.foo_toolkit import internalThing1, internalThing2 and the pain it is to deal with reading code there.

OJFord 3y ago

I thought you were going to suggest: import mp from mpmath I do dislike that the order changes, even though it is consistent in terms of the 'path', because it means everyone groups by keyword, which then puts paths out of order/same ones separate anyway.

mxz3000 3y ago
also means no autocomplete with the from bit first

fluidcruft 3y ago

import mpmath.mp as mp Doesn't work in this case because mp isn't a submodule of mpmath. You will get "ModuleNotFoundError: No module named 'mpmath.mp'" The "from" is what dives into a module and takes something out. It's not just defining a syntactic macro. You would have to do something closer to this: import mpmath mp = mpmath.mp del mpmath to replace what "from" does.

PurpleRamen 3y ago
That's an implementation-detail. Nothing prevents the import from diving automatically into the file. But doing so would open the door for name-shadowing, as with a package you could have a separate mp.py for import, or a definition of mp in __init__.py. And this would be another confusion for people, and a performance-problem maybe.

pfranz 3y ago

I get where you're coming from, but those lines aren't equivalent (which may be why its confusing). "as" changes the name and can be used for both: import mpmath as mpmath_module from mpmath import mp as mp_context "import" and "from" always address modules (directories and files) from/import extracts objects from modules and "as" swaps out the name. It's confusing because "from/import" reaches inside a package and Python uses the same delimiter for Namespaces/Modules, Classes, and Properties. urllib.request.HTTPBasicAuthHandler.auth_header is Namespace.Module.Class.Property You have to use each one differently...but you just have to know. You get some small context clues based on capitalization or knowing the first thing at the top of the file is a Namespace or Module.