[IPython-user] More Windows questions part 2 - \/ characters revisited

Jerry McRae qrs0xyc02 at sneakemail.com
Wed Jun 22 10:32:06 CDT 2005


Hi Ville,

For Windoze people only...

You <V> wrote on Wednesday (6/22/2005 at 3:39 AM) thus about [IPython-user] More Windows questions part 2 - \/ characters revisited:

V> There's no need for conversion, / is a valid path separator in win32.

V> Well, the thing is I don't even WANT to introduce \ as path separator
V> in win32, even if it corrected some problems people may be having.
V> Win32 is evil, \ as pathsep is evil and I prefer the thing to work in
V> an unixy way because it's much more natural in python, / being just a
V> plain old character among others. Some programs expect \ - it could be
V> argued that such programs are broken, not ipython - but as said
V> previously it can be circumvented by doing the \\tmp/a/b/c.txt, so
V> it's not a big deal.

I think we are talking apples and apricots here.  ;)

SOMETIMES Windoze will convert / to \, as in the cd command, but very
seldom.  And if you try to use / in the cd command (in cmd.exe) ,
autocomplete does NOT work.

I think we have three domains here that are effected by this
discussion.  1) the OS and commands sent to it.  2) the Python
language, and 3) the IPython command interpreter.

#2. Regarding the Python language elements, I strongly AGREE with you that
the \ character should NEVER be hard coded.  Use /, or the "more proper"
os.path.join/split.  In Python, I agree, "/" is a valid path
separator.

#3. And while I agree \ as an escape character is necessary, IPython is
a command interpreter.  I think IPython should be reading raw strings
as its commands.  I know I will have to live with using \ when
executing DOS (cmd.exe) commands, but I see no reason to escape
anything except strings.  "\" is not a valid token or operator and has
no meaning to the language syntax. There is no issue in the regular
Python interpreter because one HAS to pass a string to the os.system()
function, and one can either pass a normal string or a raw string.
Escape sequences are ONLY useful in strings.  Any other use besides \\
creates a syntax error in the interpreter anyway.
You cannot type this in IPython: for i in mylist:\r print i\r

Leading me to the third domain (#1). One cannot use the format you
mentioned with DOS commands. !type \\tmp/a/b/c.txt will NOT work.
Neither will !type work with \\tmp\a\b\c.txt, \tmp\a\b\c.txt (which
should) , or /tmp/a/b/c.txt. \\tmp\\a\\b\\c.txt is the ONLY format
that will work because of interpreting the "\" character too soon.
The DOS cd command SOMETIMES allows different formats, but that's just
another "feature" of Windows inconsistency.

None of this matters in the Python command line, or if you don't often
execute windows commands, but that is SO POWERFUL when combined with
IPython's other features that I rarely ever use the CMD prompt
anymore.  (Oh, unless you use a real operating system, then you
probably wish IPython could replace all the features of your shell)


Proposal #1: input to IPython should be RAW strings, leaving the
             escape character '\' to be interpreted within the strings
             that are parsed and the strings passed as is if calling
             os.command().
         Drawbacks: None
         Benefits: Easier to pass \ character to cmd.exe
         Effort: small change to when the command line gets
             eval()'ed.  ! and alias commands should not be eval'ed.

Proposal #2: change the character used for autocomplete when a
             directory name is found from '/' to os.sep.
         Drawbacks: None.  Will have absolutely no effect for Linux users.
         Benefits: easier path autocompletion for Windoze users.
         Effort: should be one line change.
             
My intentions are that these proposals sane, reasonable, simple, and
have no effect on Linux users and are worthy of consideration.

-- 
Jerry
___________________________
Bitterness is like swallowing poison...
and hoping the other person would die.





More information about the IPython-user mailing list