Non-python programmer here. The author refers to "Python's idiotic import system" - can someone explain why it's idiotic? How does it differ from Ruby or Perl (both of which I am familiar with)?
Generally I think Brett Cannon has at least one talk online about how the Python import system works which is quite interesting.
What you can't do with the Python import system is having an `org.foo.bar` and `org.foo.baz` as namespaces if they are from different PyPI packages unless you do some hoops (pre Python 3.3).
My own opinion, being more knowledgeable about Python's import than I wish I was, I feel like Node.js's require() system is what I wish Python's system was – some of the same simplicity of Python, e.g., with externally-defined names (not a name embedded into the source itself), but with a much more comprehensible and less magical loader.
Working in both python and nodejs day to day, I'm thinking the same thing. npm, coupled with nodejs's import mechanism, makes things so much simpler and it's because it goes a long way to eliminates globals. Developing node modules is a pleasure. Python is a headache.
If you ignore for a minute the complaints about the way Python modules are linked to the filesystem, I'd say there are actually some big advantages over Ruby in Python's module system.
Mainly just that you actually have proper namespacing features which are orthogonal to the notion of classes or mixins.
In Ruby namespacing (in as much as it exists) is implemented via a clumsy dual-purposing of the Module/Class system; the mechanism used to import methods into a class from a mixin, is the same one used to import constants from a module's namespace. A lot of the flexibility you have when importing things between python namespaces, just isn't possible in Ruby, at least not without a lot of boilerplate or dubious metaprogramming.
I don't mean to start a flamewar here though. I could list Python warts just as easily. Just saying, Pythonistas, be grateful for what you have :)
In my limited knowledge and understanding, python's import system is actually better than ruby's (since by default you avoid dumping stuff in the global namespaces) and java's (since you can rename on import).
I believe modern perl has some nice things such as versions, "unimport" statements and explicit client control of import hooks?
Indeed, Perl6 has module and class vesioning [1] at the 'language' level. It's pretty interesting on paper, just like everything else about Perl6 (imho).
I wouldn't call populating the global namespace with a modules' contents an inferior default. Some like it that way and I'm glad that Python is flexible enough to allow both implicit and explicit imports.
I'd say the biggest difference between Python and Ruby's is that Python's has a syntax, whereas Ruby's is a function call, this makes Ruby's more flexible since you can always replace it, add new arguments, or in other ways manipulate it. I'm not sure if that's what Armin is referring to though.
> I'd say the biggest difference between Python and Ruby's is that Python's has a syntax, whereas Ruby's is a function call
This is not true on two fronts.
First, the import statement is a convenient, hookable wrapper around the __import__ function. It's quite customizable already. See PEP302 which references and allows implementation of PEP273 (importing modules from Zip archives). Other points of reference include [0], [1] and [2]
Also, the biggest difference is that when you 'require', you require a filename (i.e the arbitrary content of a file in the filesystem), but when you 'import', you import objects from a namespace into a scope. The namespace is resolved as an item living in the filesystem. In Ruby I could require 'foo/bar' and it could create the constants Foo::Bar and Qux::Quux. I have no way to require Qux::Quux. Rails for example tries to autoload constants based on their names, but for all I know, the second I reference Foo::Bar, it could actually define Qux::Quux. Ruby encourages this style of programming, spreading extendable classes and modules around in multiple files, while Python decides that things should be contained and well-behaving, and not trivially pollute unrelated module namespaces.
My analysis is that by definition you just can't have both, and that either one has a set of benefits and drawbacks.
