A mistake which almost went me mad
Rustom Mody
rustompmody at gmail.com
Thu Mar 10 01:13:14 EST 2016
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
More information about the Python-list
mailing list