error in os.chdir
On Sun, Jul 1, 2018 at 10:20 AM, eryk sun <eryksun at gmail.com> wrote:
> On Sat, Jun 30, 2018 at 11:42 PM, Chris Angelico <rosuav at gmail.com> wrote:
>> "Legacy" implies that it's the old standard that is now deprecated,
> I did not mean to imply that DOS paths are deprecated. That's not what
> legacy means to me.
Unless you are Humpty Dumpty, you can't just say "that's not what it
means to me". Sorry. People WILL see "legacy" as an implication that
"only the old stuff goes that way". You are responding to a thread in
which someone used a perfectly ordinary file path, and you said that
only legacy paths can be done with slashes. At best, you are
technically correct and functionally deceptive.
>> Registry paths aren't file paths,
> You said to use forward slash for "all paths".
*facepalm* Okay. I said "all paths", but I did not refer to XPath
(although that also uses the slash character), nor registry paths, nor
the footpath that runs parallel to the road outside my house. You're
absolutely right, there are no forward slashes in the path that leads
to my door. My bad. I'm sorry that the word "all" has to be
interpreted within the context of the thread that it was used in.
>> command line arguments are interpreted by the target program (and in many
>> MANY cases, forward slashes are absolutely fine),
> You can't generalize this. In many cases it's not ok. Most
> command-line utilities that use ulib make a simply assumption when
> parsing the command line that forward slash is used for options
> (switches). It's best to normalize paths in a command line via
Ahh but I *can* generalize it. In many cases, forward slashes ARE
fine, and I can prove it by listing off large numbers of programs that
are perfectly happy to receive file paths with slashes in them.
Surprise surprise, most of those programs are going to be taking those
paths and handing them straight to the OS. In other words: THE OS
SUPPORTS SLASHES. Does this surprise anyone?
So what if, internally, that's done by converting them to backslashes?
No Python program needs to care. In fact, there are other conversions,
too - the underlying file system is most likely using UTF-16 paths,
but your Python program needn't use UTF-16. No, it simply uses a plain
old string literal - a Unicode string. The OP need not be concerned
about any of these fiddlinesses, unless in some way they actually
Congratulations on being technically correct (maybe) and utterly unhelpful.