A mistake which almost went me mad

[Rustom Mody]

On Wednesday, March 9, 2016 at 10:04:35 PM UTC+5:30, Rick Johnson wrote:
> On Thursday, March 3, 2016 at 4:22:07 AM UTC-6, ast wrote:
> > Hello
> > 
> > This has to be told
> > 
> > I created a file pickle.py in order to test some files
> > read/write with objects and put it in a directory
> > which is on my python path. 
> > 
> > Then the nightmare began
> > 
> > - Idle no longer works, window no longer opens 
> > when double clicked, no errors messsages
> > 
> > - python -m pip list doesnt work, crash with an 
> > error message related to pickle
> > 
> > I uninstalled python34 and reinstalled it, same problem
> > I uninstalled python34 and instaled 3.5, same problem
> > 
> > ...
> > 
> > I finally understood that pickle.py is the name of the file
> > containing the official pickle module.
> > 
> > This module is probably used by various python programs,
> > IDLE, pip ...
> > 
> > Instead of reading official pickle, python read my file ...
> 
> This is a design flaw of the python language. If all standard library modules would have been protected from the global namespace by a single symbol -- say "stdlib" or "py" or whatever -- we would only need to avoid *ONE* symbol, instead of hundreds of them!!! Third party modules should have their own namespace as well. 
> 
>  from stdlib import re
>  from stdlib.re import search
>  from extlib import PIL
>  from extlib.PIL import Image, ImageTk
> 
> Since those responsible for this flaw are unable, or unwilling, to fix it, the only solution for *YOU* is to (1) memorize every module name that exists in the python standard library, and also those that exist in your "site-packages" directory, or (2) hide all your personal modules behind a single symbol by utilizing a package.
>  
>  +mylib
>    __init__.py
>    pickle.py
> 
> import mylib.pickle as mypickle
> mypickle.do_something()

As usual Rick I find myself agreeing with your direction [also it seems
Random832's direction] though not with the ranty tone.

Ive been collecting factoids about how programming pedagogy and professional
programming practice cannot be conflated under one roof

[See http://blog.languager.org/2015/06/functional-programming-moving-target.html ]

One argument against that is -- in some guise or other -- to use namespaces.
eg If you dont need a language-feature dont use it
  If you dont need a library dont use it

These arguments neglect that the namespacing -- semantics, intricacies, headaches, etc -- ITSELF may be significantly noob-unfriendly.

For cars one needs: 
- the hood securely fastened when teaching driving
- easily openable when teaching automobile engineering