[IPython-dev] IPython bug?

Fernando Perez fperez at colorado.edu
Sat May 24 16:20:37 EDT 2003


Gary Bishop wrote:
> 
> That won't do the job. Consider a line like:
> 
> In[1] cd foo\next
> 
> A perfectly legal thing for a Windows user to type, or for completion 
> to return. When you convert that into a string, you'll have a newline 
> character in the middle! Ack!
> 
> I see what you're saying about my fix though. If a magic command took a 
> string argument, and the user wanted to escape something in the string. 
> It would be bad. Combined with automatic quoting this seems to really 
> produce a dilemma. Can you think of a case where this happens?

Many.  If users in Unix need to escape spaces or other special characters in 
filenames, for instance.  In particular, I want to guarantee that the ipython 
syntax and the shell one look the same:

*** SHELL

[test]> d
/usr/local/home/fperez/test/test
total 8
drwxr-xr-x    2 fperez       4096 May 24 14:11 a space/
drwxr-xr-x    2 fperez       4096 May 24 13:58 b\ad/
[test]> ls a\ space
foo
[test]> ls b\\ad
foo

***IPython
In [15]: d
total 8
drwxr-xr-x    2 fperez       4096 May 24 14:11 a space/
drwxr-xr-x    2 fperez       4096 May 24 13:58 b\ad/

In [16]: ls a\ space
foo

In [17]: ls b\\ad
foo

I can get this to work with:

[IPython]> diff -Naur iplib_ori.py iplib.py
--- iplib_ori.py        2003-05-24 13:10:58.000000000 -0600
+++ iplib.py    2003-05-24 14:09:11.000000000 -0600
@@ -1078,11 +1078,8 @@
              parameter_s = ''
              scommand = line
          if hasattr(self, scommand):
-            if parameter_s.startswith('"'):
-                parameter_s = ' ' + parameter_s
-            if parameter_s.endswith('"'):
-                parameter_s += ' '
-            return shell+scommand+'(parameter_s="""%s""")' % (parameter_s,)
+            parameter_s = " %s " % parameter_s # Protect quotes at the end
+            return shell+scommand+'(parameter_s=r"""%s""")' % parameter_s
          else:
              return shell+line+'()'


It's basically the same patch as before, with an added raw string literal for 
the string as passed.

> Maybe we should avoid \ as much as possible. I can make file name 
> completion return /. We can encourage users to type / and warn them 
> they better type \\ if they want to use it. I'd like to, one day, make 
> a version of the commands that deal with paths that use / instead of \. 
> They pretty much all accept / but they produce \.
> 
> Oh, but consider a ! escape. Sometimes the windows shell insists on \. 
> It is pretty rare though.
> 
> The complicated rule would be outside quotation marks (of any kind) 
> characters stand for themselves. There are no escapes. Inside quotation 
> marks the usual escape conventions apply.
> 
> This would require users to quote strings they wanted to use escapes 
> in, which seems reasonable to me. And it would allow us to change \ to 
> \\ everywhere in unquoted strings (like file names).
> 
> Getting the quotes right probably requires character by character 
> processing of the line.
> 
> What do you think?

That down this path lies insanity :)

Seriously, I'm not going to write a nightmarish string escaping code like 
this.  If you want to do it, feel free to write it.  We can always hook it at 
runtime as a user extension via the prefilter() method, in a similar way to 
what the current 'tutorial' profile does.


The patch above works for me, and this is one of those cases where I will go 
for simplicity at the sacrifice of features for Windows, if it comes down to 
that.  I think we can come up with a reasonable solution via a combination of 
raw strings and other simple things.  But if the only way out is a 
full-fledged string escape code, it will have to be a separate prefilter() 
function which gets distributed in a  separate file and loaded only under 
Windows.  I'd be happy to include something like that, but NOT in the inner 
core of ipython.

Let's see how far we can get with simple, maintaninable solutions first. 
Remember Jamie Zawinski's wisdom:

Some people, when confronted with a problem, think “I know, I’ll use regular 
expressions.” Now they have two problems.
	
--Jamie Zawinski, in comp.lang.emacs 	


Cheers,

f.




More information about the IPython-dev mailing list