>>>>> "MAL" == M <mal@lemburg.com> writes:
MAL> I guess this is done for the same reason that e.g. /usr/local
MAL> is last in PATH on Unix: system top level programs and libs
MAL> should always have top priority. Otherwise, a user could
MAL> easily override a system program/lib by placing a new version
MAL> into the local dir which then gets picked up by other system
MAL> programs.
Well, hopefully you'd control who can write into /usr/local so that
you could trust overrides being installed there. On a single user
system, I usually do in fact put /usr/local/bin early in my path
specifically because I do want to override older, buggier, system
programs.
The analogy is similar in the Python situation. When I'm the only
person using the system, and I'm in control of everything, being able
to override the standard library is a very useful thing to do. When
there's less trust in the environment I'm running in, or more sharing
of common resources, it can be problematic.
-Barry
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4