PyWart: "Python's import statement and the history of external dependencies"

[alex23]

On 16/11/2014 3:01 PM, Rick Johnson wrote:
> Python's attempt to solve the "external dependencies problem"
> has yet to produce the results that many people, including
> myself, would like.

I'd say this was an argumentum ad populum, only you didn't cite anything 
that shows the "many" you claim you speak for.

> Actually, Python is not alone in this deficiency, no, Python
> is just *ANOTHER* language in a *STRING* of languages over
> the years who has *YET AGAIN* implemented the same old
> crusty design patterns, packaged them in a shiny metallic
> wrapping paper with a big red bow on top, and hoped that no
> one would notice the stench...

Are you sure that's not just you?

>      1. Name clashes!
>      2. Smaller name pool!

Just off the top of my head, we have several solutions for this:

1) Rebinding imports

     import foo as foo2

2) Namespace packages

     import mypackage.foo

3) Filepath imports (deprecated in 3.4 but under discussion for 
reprecation or replacement)

     import importlib.machinery

     loader = importlib.machinery.SourceFileLoader("module.name",
         "/path /to/file.py")
     foo = loader.load_module()
     foo.MyClass()

4) Virtual environments

In before "but WHY so MANY different WAYS OMG PYTHON you M.F.P.O.S.": 
because they offer flexibility.

>      3. Machinery is too implicit!

See: importlib

>      4. Circular imports are inevitable!

They're also clear indication of bad design. That's not something Python 
should explicitly set out to support.

>      5. Much too difficult to use and/or explain!

Well sure, if your reaction to things you don't understand is to rant 
against them instead of asking questions, then I can see how that would 
be true.

Also: citation needed.

>      6. Too many "gotchas"!

Is this the sequel to "Too Many Cooks"? Awesome.

> In closing, there is only one thing you need to know about
> Python's import statement:  it is deceptively easy to
> underestimate it's ability to *EFF UP* your expectations!

There's your problem right there: a language conforms to its 
specification, not your random expectation.

I'm eager to see how you resolve your concerns in RickPython3000.