On Sun, Nov 23, 2014 at 5:30 PM, Steven D'Aprano
<steve+comp.lang.pyt...@pearwood.info> wrote:
> Chris Angelico wrote:
>
>> Okay, here's my guesses.
>>
>> os2emxpath: In the stdlib, but more often accessed as "os.path" while
>> running under OS/2
>
> Correct.
I'm in a special position here, as I actually have an OS/2 system, and
have used Python on it. So I know about the particular obscure system
that you happened to pick there. Now, if you'd said "amigapath", I
wouldn't have known.
> [chomp a few correct and a few wrong, here and there]
>
> Not bad, but as you can see, the naming convensions are all over the place.
> It's easy to accidentally shadow the std lib.
Agreed. There's no way to guarantee that you aren't shadowing someone
else's module, except by namespacing your own - either putting your
name at the beginning of every file name ("fredfoobar_calendar") or by
making a package ("fredfoobar.calendar").
It would be nice, though, to be able to *detect* shadowing. Is there a
way (maybe through importlib) to ask Python to enumerate every file
that could be found when attempting to "import calendar"? Something
like this:
>>> import importlib
>>> importlib.find_all_modules("calendar")
['calendar.py', '/usr/local/lib/python3.5/calendar.py']
That would be a useful feature, if it doesn't already exist. If it
does, it could do with a bit more visibility - poking around on Google
and interactively with help(importlib) etc didn't reveal it to me.
>> That's what Rick said first, and then said that if you're going to be
>> explicit, you should do the job properly and not have _any_ implicit
>> paths.
>
> Rick should ask himself why virtually every single language, from compiled
> languages like Ada, C, Pascal and Java, to interpreted languages like bash,
> all use search paths instead of explicit paths.
>
> Hint: the answer is not that every single language designer in the world is
> a moron.
Maybe they are. Maybe Rick's just so amazingly brilliant that he,
alone among all language designers, has figured this out. Maybe it's
time for his fork of Python to sweep the world with its incredible
solutions to massively prevalent problems!
While it *is* possible for every language in the world to get
something wrong, there's usually a few around the place that get it
right. Until Python 3.3, most popular languages got Unicode support
either wrong (using UTF-16 being the most common wrongness) or
inefficient (using UTF-32), or just didn't have any at all (bytes
everywhere). Could someone look at the state of world programming
languages and say "Everyone uses UTF-16, and not every language
designer in the world is a moron, therefore UTF-16 must be the right
thing to do"? No, because Haskell, Scheme, Pike, and bash all had it
right, already. Sure, they're not the most-used languages in the
world, but they certainly are used (bash plenty, though to be honest,
not many people use bash scripts for Unicode heavy-lifting), and they
prove that UTF-16 isn't the only way to go.
So, where are the languages that use explicit paths? Show us why
they're so great, using actual production code.
ChrisA
--
https://mail.python.org/mailman/listinfo/python-list
