Prev: iglob performance no better than glob
Next: Meet Arab, Russian, American Singles From All Over The World
From: W. eWatson on 31 Jan 2010 14:43
Steve Holden wrote:

> You need to read up on string literals is all. "\\" is simply the
> literal representation of a string containing a single backslash. This
> comes about because string literals are allowed to contain special
> "escape sequences" which are introduced by a backslash; since this gives
> the backslash a special meaning in string literals we also have to use
> an escape sequence ("\\") to represent a backslash.
>
> In practice you will find that
>
> a) Many Windows APIs (but not the command line) are just as happy with a
> forward slash as a backslash to separate file path components; and
>
> b) The best practice is to build filenames using the routines provided
> in the os.path module, which guarantees to give results correct for the
> current platform.
>
> regards
> Steve
Basic sys functions brought out the \ separator for paths.

What am I missing here? Looks OK to me.


>>> abc=r'xyz\\'
>>> abc
'xyz\\\\'
>>> print abc
xyz\\
>>> abc.replace(r'\',r'z')

SyntaxError: invalid syntax
>>> abc
'xyz\\\\'
From: Steve Holden on 31 Jan 2010 14:54
W. eWatson wrote:
> Steve Holden wrote:
>
>> You need to read up on string literals is all. "\\" is simply the
>> literal representation of a string containing a single backslash. This
>> comes about because string literals are allowed to contain special
>> "escape sequences" which are introduced by a backslash; since this gives
>> the backslash a special meaning in string literals we also have to use
>> an escape sequence ("\\") to represent a backslash.
>>
>> In practice you will find that
>>
>> a) Many Windows APIs (but not the command line) are just as happy with a
>> forward slash as a backslash to separate file path components; and
>>
>> b) The best practice is to build filenames using the routines provided
>> in the os.path module, which guarantees to give results correct for the
>> current platform.
>>
>> regards
>> Steve
> Basic sys functions brought out the \ separator for paths.
>
> What am I missing here? Looks OK to me.
>
>
>>>> abc=r'xyz\\'
>>>> abc
> 'xyz\\\\'
>>>> print abc
> xyz\\
>>>> abc.replace(r'\',r'z')
>
> SyntaxError: invalid syntax
>>>> abc
> 'xyz\\\\'

The SyntaxError is thrown because although backslashes lose their
special "escape sequence" meaning, for some reason I have never really
understood they retain the requirement that they be followed by another
character.

abc.replace("\\", 'z')

would have worked fine.

regards
Steve
--
Steve Holden +1 571 484 6266 +1 800 494 3119
PyCon is coming! Atlanta, Feb 2010 http://us.pycon.org/
Holden Web LLC http://www.holdenweb.com/
UPCOMING EVENTS: http://holdenweb.eventbrite.com/

From: Tim Chase on 31 Jan 2010 14:59
W. eWatson wrote:
> What am I missing here? Looks OK to me.
> >>> abc.replace(r'\',r'z')
>
> SyntaxError: invalid syntax

A raw string can't end in a single backslash (something that
occasionally annoys me, but I've learned to deal with it).

>>> s=r'\'
File "<stdin>", line 1
s=r'\'
^
SyntaxError: EOL while scanning single-quoted string


My guess is that the parser sees the first call as

abc.replace(
r"r\'r" <-- how your single-quoted is interpreted
z' <-- the leftovers that cause the syntax error
)


-tkc



From: MRAB on 31 Jan 2010 15:02
W. eWatson wrote:
> Steve Holden wrote:
>
>> You need to read up on string literals is all. "\\" is simply the
>> literal representation of a string containing a single backslash. This
>> comes about because string literals are allowed to contain special
>> "escape sequences" which are introduced by a backslash; since this gives
>> the backslash a special meaning in string literals we also have to use
>> an escape sequence ("\\") to represent a backslash.
>>
>> In practice you will find that
>>
>> a) Many Windows APIs (but not the command line) are just as happy with a
>> forward slash as a backslash to separate file path components; and
>>
>> b) The best practice is to build filenames using the routines provided
>> in the os.path module, which guarantees to give results correct for the
>> current platform.
>>
>> regards
>> Steve
> Basic sys functions brought out the \ separator for paths.
>
> What am I missing here? Looks OK to me.
>
>
> >>> abc=r'xyz\\'
> >>> abc
> 'xyz\\\\'
> >>> print abc
> xyz\\
> >>> abc.replace(r'\',r'z')
>
> SyntaxError: invalid syntax
> >>> abc
> 'xyz\\\\'

It's not possible to end a raw string with a single backslash, and if
you end it with a double backslash then you'll get a double backslash.
Very annoying.
From: Alf P. Steinbach on 31 Jan 2010 15:36
* Tim Chase:
> Alf P. Steinbach wrote:
>> that you cannot write e.g. "c:\windows\system32", but must
>> write something like "c:\\windows\\system32" (try to print
>> that string), or, since Windows handles forward slashes as
>> well, you can write "c:/windows/system32" :-).
>
> Forward slashes work for some relative paths for some commands but not
> for others like absolute non-drive-specified paths:
>
> Microsoft Windows XP [Version 5.1.2600]
> C:\>md abc
> C:\>md abc\123
> C:\>md abc\234
> C:\>cd abc
> C:\abc>tree /f /a
> Folder PATH listing
> Volume serial number is 940C-3F80
> C:.
> +---123
> | \---234
> \---234
>
> C:\abc>cd 123
> C:\abc\123>cd ../234
> C:\abc\234>type ../123/234/hello.txt
> The syntax of the command is incorrect.
> C:\abc\234>cd ../123
> C:\abc\123>cd /abc/123
> The system cannot find the path specified.
> C:\abc>x:
> X:\>type c:/abc/123/234/hello.txt
> The syntax of the command is incorrect.
>
> #####
> The previous absolute-path fails in cmd.exe for a variety of apps
> because the "/" is treated as a parameter/switch to the various
> programs.

Yes, that's a valid concern when invoking external programs.


> Fortunately, the Python path-handling sub-system is smart
> enough to do the right thing, even when Win32's internal handling is too
> dumb to behave:
>
> C:\abc\123>echo hello > 234/hello.txt
> C:\abc\123>cd ..
> C:\abc>tree /f /a
> Folder PATH listing
> Volume serial number is 940C-3F80
> C:.
> +---123
> | \---234
> | hello.txt
> |
> \---234
>
> C:\abc>python
> Python 2.4.3 (#69, Mar 29 2006, 17:35:34) [MSC v.1310 32 bit (Intel)] on
> win32
> Type "help", "copyright", "credits" or "license" for more information.
> >>> file('/abc/123/234/hello.txt').read()
> 'hello \n'

Oops, this is a dangerous misconception, because it can lead to Wrong Solutions
to the perceived problems.

It's not the "Win32's internal handling" that you're up against above, but the
generally unpredictable quirks of syntax and semantics of commands in the
Windows command interpreter:

<example>
C:\test> echo bah >foo.txt

C:\test> type ../test/foo.txt
The syntax of the command is incorrect.

C:\test> type "../test/foo.txt"
bah

C:\test> _
</example>

Generally the details of that command interpreter are undocumented.


> So as long as you stick within Python's insulation, forward slashes are
> a nice solution.

No, it's not Python's insulation that makes things work (although perhaps it
redundantly tries to help), it's simply the Windows API, which generally accepts
forward or backward slashes.

It's the same in other programming languages.

In particular, it's not a good idea to carry the idea of using backslashes over
to #include directives in C or C++, thinking that there's no Python insulation
there (at least one compiler accepts and Windows compilers used to accept it at
one time, but it's invalid, and non-portable, whereas forward slashes work).


> But if you have to interact with external programs,
> use the \\ notation or raw strings:
>
> pth = r"c:\windows\system32"
>
> [mutters under breath about Win32 headaches]

He he. Yes.

But anyways, the thing to remember is that when paths are passed to /programs/
in Windows, they generally need to be /quoted/.

That's particularly important for paths containing spaces.

For internal file handling in a program, including using libraries, forward
slashes work fine -- unless a library is particularly ill-behaved and requires
backslashes -- and provide some (but not complete) measure of portability.

For example,


<example>
>>> f = open( "c:/foo.txt", "w" )
>>> f.write( "works\n" )
6
>>> f.close()
>>> f = open( "c:/foo.txt", "r" )
>>> f.readlines()
['works\n']
>>> f.close()
>>> _
</example>


In retrospect, I should have been more clear about that distinction between
invoking programs and invoking routines such as Python 'open', yes.

And as Steve Holden remarked else-thread, best practice for Python is to build
paths using the os.path functionality.

E.g.,


<example>
>>> import os.path
>>> os.path.normpath( "c:/foo.txt" )
'c:\\foo.txt'
>>> _
</example>


Cheers & hth.,

- Alf
First  |  Prev  |  Next  |  Last
Pages: 1 2 3
Prev: iglob performance no better than glob
Next: Meet Arab, Russian, American Singles From All Over The World