[Tim]
> So a retroactive -1 on this last-second patch -- and a waaaaay
> retroactive -1 on Python's behavior on Windows too.
[Barry A. Warsaw]
> So, let's tease out what the Right solution would be, and then
> see how close or if we can get there for 2.1. I've no clue what
> behavior Mac and Windows users would /like/ to see -- what would
> be most natural for them?
Nobody knows -- I don't think "they've" ever been asked. All *developers*
want Unix semantics (keep going until finding an exact match -- that's what
Steven's patch did). That's not good enough for Windows because of
case-destroying network file systems and case-destroying old tools, but that
+ PYTHONCASEOK (stop on the first match of any kind) is good enough for
Windows in my experience.
> OTOH, I like the Un*x behavior
Of course you do -- you're a developer when you're not a bass player <wink>.
No developer wants "file" to have 16 distinct potential meanings.
> and I think I'd want to see platforms like Cygwin and MacOSX-on-
> non-HFS+ get as close to that as possible.
Well, MacOSX-on-non-HFS+ *is* Unix, right? So that should take care of
itself (ya, right). I don't understand what Cygwin does; here from a Cygwin
bash shell session:
tim@fluffy ~
$ touch abc
tim@fluffy ~
$ touch ABC
tim@fluffy ~
$ ls
abc
tim@fluffy ~
$ wc AbC
0 0 0 AbC
tim@fluffy ~
$ ls A*
ls: A*: No such file or directory
tim@fluffy ~
So best I can tell, they're like Steven: working with a case-insensitive
filesystem but trying to make Python insist that it's not, and what basic
tools there do about case is seemingly random (wc doesn't care, shell
expansion does, touch doesn't, rm doesn't (not shown) -- maybe it's just
shell expansion that's trying to pretend this is Unix? oh ya, shell
expansion and Python import -- *that's* a natural pair <wink>).
> Is it better to have uniform behavior across all platforms (modulo
> places like some Windows network fs's where that may not be possible)?
I think so, but I've already said that. "import" is a language statement,
not a platform file operation at heart. Of *course* people expect
open("FiLe") to open files "file" or "FILE" (or even "FiLe" <wink>) on
Windows, but inside Python stmts they expect case to matter.
> Should Python's import semantics be identical across all platforms?
> OTOH, this is where the rubber meets the road so to speak, so some
> incompatibilities may be impossible to avoid.
I would prefer it, but if Guido thinks Python's import semantics should
derive from the platform's filesystem semantics, fine, and then any "Python
import should pretend it's Unix" patch should get tossed without further
debate. But Guido doesn't think that either, else Windows Python wouldn't
complain about "import FILE" finding file.py first (there is no other tool
on Windows that cares at all -- everything else would just open file.py).
So I view the current rules as inexplicable: they're neither
platform-independent nor consistent with the platform's natural behavior
(unless that platform has case-sensitive filesystem semantics).
Bottom line: for the purpose of import-from-file (and except for
case-destroying filesystems, where PYTHONCASEOK is the only hope), we *can*
make case-insensitive case-preserving filesystems "act like" they were
case-sensitive with modest effort. We can't do the reverse. That would
lead to explainable rules and maximal portability. I'll worry about moving
all my Python files into a single directory when it comes up (hasn't yet).
> And what about Jython?
Oh yeah? What about Vyper <wink>?
otoh-if-i-actually-cared-about-case-i-would-never-have-adopted-
this-silly-sig-style-ly y'rs - tim
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