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

[sohcahtoa82 at gmail.com]

On Friday, November 21, 2014 3:21:31 PM UTC-8, Rick Johnson wrote:
> On Friday, November 21, 2014 4:25:49 PM UTC-6, Rick Johnson wrote:
> > ############################################################
> > #                          STEP 3                          #
> > ############################################################
> > # Make the following changes to the import machinery:      #
> > # Before Python reads a module file, Python will clear the #
> > # values in "sys.path_extra", OR, query the                #
> > # "__search_paths__" variable, if any paths exists in this #
> > # list, THEN THESE PATHS MUST BE SEARCHED, AND THEY MUST   #
> > # BE SEARCHED BEFORE ANY PATHS IN "sys.path", AND NO       #
> > # PEEKING IN "sys.modules" IS ALLOWED!                     #
> > ############################################################
> 
> 
> Actually, to be more specific, not only should the
> __search_path__ variable be unique to each file, Python
> should query the value of "__search_path__" variable each
> time it encounters an import statement.
> 
> So, if we wanted to import multiple modules who share the
> same name, but who exist in different namespaces, we would
> could do so by changing the values of __search_path__ before
> calling the import:
> 
>     #
>     # import the first coconut module Python can find using
>     # the default search path, if not raise an error
>     #
>     import coconut
> 
>     #
>     # import the first coconut module python can find using
>     # *ONLY* the explicit paths provided, or raise an error.
>     #
>     __search_path__ = [
>         'path/to/a/specific/coconut/tree',
>         'might/be/here/also'
>         ]
>     import coconut
> 
> At first i was thinking that *IF* any "explicit paths" were
> defined via __search_path__, then Python should look in all
> those paths first, then if nothing is found look in
> sys.modules, then if nothing is found, exhaust sys.modules,
> 
> BUT NOW I AM THINKING THAT IS A BAD IDEA!
> 
> When __search_path__ *IS* defined, Python should look *ONLY*
> in the provided paths, and if not module is found, raise an
> "ExplictImportError".
> 
> Because if we're going to be explicit then we need to also be
> consistent. If the programmer is requesting that Python
> search in a predefined directories, then obviously he
> doing so to avoid name clashes, so if Python went on and
> returned a module OUTSIDE of those predefined paths, Python
> would be circumventing (IMPLICITLY AGAIN!) the wishes of the
> programmer.
> 
> ============================================================
>  Succinct Summary Of My New Proposal:
> ============================================================
> 
> 1. Use the historical "implicit import" mechanism for most day
> to day imports, and let Python do all the heavy lifting.
> 
> 2. Use the new "explicit import" mechanism for advanced name
> resolutions, but realize that since you are now taking
> control of import, so you must do more work, and you must be
> "exhaustively explicit" about *where* Python searches.

I have a better idea.

Don't give modules the same name as built-in or very popular modules.

You seem like the type of person that would stick their hair into an electric egg beater and then blame the manufacturer because it ripped out their hair.  You'd probably say that the egg beater should recognize that there's hair in the beaters and turn off.