Bug in function py-separator-char

Even stranger, on my Windows machine, running the function py-separator-char inside edebug gives me the following output:

"\\Traceback (most recent call last): File \"<string>\", line 1, in <module>SystemExitIf you suspect this is an IPython bug, please report it at: https://github.com/ipython/ipython/issuesor send an email to the mailing list at <email address hidden> can print a more detailed traceback right now with \"%tb\", or use \"%debug\"to interactively debug it.Extra-detailed tracebacks for bug-reporting purposes can be enabled via: %config Application.verbose_crash=True>>> "

Am 21.03.2012 20:49, schrieb Richard Stanton:
> Even stranger, on my Windows machine, running the function py-separator-
> char inside edebug gives me the following output:
>
> "\\Traceback (most recent call last): File \"<string>\", line 1, in
> <module>SystemExitIf you suspect this is an IPython bug, please report
> it at: https://github.com/ipython/ipython/issuesor send an email to
> the mailing list at <email address hidden> can print a more detailed
> traceback right now with \"%tb\", or use \"%debug\"to interactively
> debug it.Extra-detailed tracebacks for bug-reporting purposes can be
> enabled via: %config Application.verbose_crash=True>>> "
>

Strange.

What does M-x describe-function py-separator-char RET tell?

May jump to the code then and send its definition?

>
>Strange.
>
>What does M-x describe-function py-separator-char RET tell?

py-separator-char is an interactive Lisp function in `python-mode.el'.

(py-separator-char)

Return the file-path separator char from current machine.
Returns char found.

>May jump to the code then and send its definition?

(defun py-separator-char ()
  "Return the file-path separator char from current machine.
Returns char found. "
  (interactive)
  (let ((erg (replace-regexp-in-string "\n" "" (shell-command-to-string
(concat py-shell-name " -c \"import os; print(os.sep)\"")))))
    (when (interactive-p) (message "Separator-char: %s" erg))
    erg))

At least on the Mac I know why I get these results. At the command line, her's what happens when I execute the python command inside py-separator-char:

mortgage:MacOS stanton$ ipython -c "import os; print(os.sep)"
Enthought Python Distribution -- www.enthought.com

/
mortgage:MacOS stanton$

Am 21.03.2012 21:46, schrieb Richard Stanton:
>>
>> Strange.
>>
>> What does M-x describe-function py-separator-char RET tell?
>
> py-separator-char is an interactive Lisp function in `python-mode.el'.
>
> (py-separator-char)
>
> Return the file-path separator char from current machine.
> Returns char found.
>
>
>> May jump to the code then and send its definition?
>
>
> (defun py-separator-char ()
> "Return the file-path separator char from current machine.
> Returns char found. "
> (interactive)
> (let ((erg (replace-regexp-in-string "\n" "" (shell-command-to-string
> (concat py-shell-name " -c \"import os; print(os.sep)\"")))))
> (when (interactive-p) (message "Separator-char: %s" erg))
> erg))
>

Okay so far. However, it's a macro now, not a function.
Please pull and re-compile.

>
>Okay so far. However, it's a macro now, not a function.
>Please pull and re-compile.

Same result as before. See my last post - the problem is that the command
being executed, even if executed at the command line, actually returns
more text than just the separator.

More info: this bug only crops up if ipython is set as the default.

Currently, I have

  (setq py-shell-name "/Library/Frameworks/EPD64.framework/Versions/7.2/bin/ipython")

in my init.el

If I change this to

  (setq py-shell-name "/Library/Frameworks/EPD64.framework/Versions/7.2/bin/python")

(the same, but with python rather than ipython), py-separator-char now returns the correct value. I guess ipython insists on returning some extra text along with the output of whatever command you feed it.

Hi Richard,

very interesting.

It happens, if something is wrong with installation, if the IPython pointed to sends an error.

Should not happen with your installed system-wide IPython.

If py-shell-name is just "MY-PATH-TO-INSTALLED/ipython" its fine here, as just "ipython"

Considering the report as a request to deal with that kind of errors.

> It happens, if something is wrong with installation, if the IPython pointed to
> sends an error.
>
> Should not happen with your installed system-wide IPython.

Just to clarify, while it's true that this is not the default python installed with OS X, EPD is a standard distribution of python, it's installed fine on my machine, and it's not actually reporting any errors here - just some banner text along with the separator.

Best,

Richard

Am 22.03.2012 08:36, schrieb Richard Stanton:
>> It happens, if something is wrong with installation, if the IPython pointed to
>> sends an error.
>>
>> Should not happen with your installed system-wide IPython.
>
> Just to clarify, while it's true that this is not the default python
> installed with OS X, EPD is a standard distribution of python, it's
> installed fine on my machine, and it's not actually reporting any errors
> here - just some banner text along with the separator.
>
> Best,
>
> Richard
>

okay, may we call it an "extraordinary banner" though? :)

if not, sending the option -nobanner would be all we need.

Here appears "UserWarning: ..."

please re-open, if not done

The "EPD hack" works under OS X, but not under Windows because there EPD is installed under directory c:\python27 - not easy to tell from the directory name...

This seems to be getting compIicated! I have two suggestions here:

1) Insist on using python for this function, even if ipython is specified as the default python shell, since when I run the same commands using "python -c..." instead of "ipython -c.." at the command line, I get the output you were looking for.

2) Maybe it would be easier to do this a different way: Have py-separator-char set as a customizable variable, where the default value is set based on the OS Emacs is running under. For example, in my init.el I have the following:

(defun system-type-is-windows ()
  (interactive)
  "Return true if system is Windows-based"
  (string-equal system-type "windows-nt"))

(defun system-type-is-darwin ()
  (interactive)
  "Return true if system is darwin-based (Mac OS X)"
  (string-equal system-type "darwin"))

Now I can selectively take actions if I'm running under Windows, for example, as follows:

(when (system-type-is-windows)
  (setq py-separator-char "\\")
)

This just seems easier than trying to deal with parsing the output from every possible configuration of python...

Am 22.03.2012 18:01, schrieb Richard Stanton:
> The "EPD hack" works under OS X, but not under Windows because there EPD
> is installed under directory c:\python27 - not easy to tell from the
> directory name...
>
> This seems to be getting compIicated! I have two suggestions here:
>
> 1) Insist on using python for this function, even if ipython is
> specified as the default python shell, since when I run the same
> commands using "python -c..." instead of "ipython -c.." at the command
> line, I get the output you were looking for.
>
> 2) Maybe it would be easier to do this a different way: Have py-
> separator-char set as a customizable variable, where the default value
> is set based on the OS Emacs is running under. For example, in my
> init.el I have the following:
>
>
> (defun system-type-is-windows ()
> (interactive)
> "Return true if system is Windows-based"
> (string-equal system-type "windows-nt"))
>
> (defun system-type-is-darwin ()
> (interactive)
> "Return true if system is darwin-based (Mac OS X)"
> (string-equal system-type "darwin"))
>
> Now I can selectively take actions if I'm running under Windows, for
> example, as follows:
>
> (when (system-type-is-windows)
> (setq py-separator-char "\\")
> )
>
> This just seems easier than trying to deal with parsing the output from
> every possible configuration of python...
>

OTOH if such a thing fails like returning a file-separator, how reliable might be the rest?
Rather inclined to make Python work in the circumstances given.

You have a point. Two thoughts:

1) Even though I use ipython for the interactive shell because of its nice interactive features, I'd be quite happy if python-mode just ran python without all the ipython overhead in non-interactive settings like this. Another customizable variable...?

2) Even when py-separator-char is working correctly, you're going to run into trouble under Windows. Under Windows, os.sep returns "\\". However, while the backslash is the default Windows path separator, in many cases you're allowed to use "/" as well, just like under Unix, and the standard Windows port of Emacs tends to use "/" as the *default* (often, even when you type a backslash, Emacs converts it to a forward slash). Thus you cannot rely on seeing "\\" in fully qualified file names.

In fact, if you just set py-separator-char to "/", I suspect it would work fine 99% of the time under both Unix and Windows. Using "\\", even though this is what os.sep returns, will cause many more problems due to the way Emacs handles path names.

In r907, I see there's some code in py-temp-directory checking for system type,

 (and (eq (system-type 'darwin))
             (funcall ok "/var/folders"))
        ((and (or (eq (system-type 'ms-dos))(eq (system-type 'ms-dos))(eq (system-type 'windows-nt)))
              (Funcall ok (concat "c:" (py-separator-char) "Users" ))))
        (funcall ok ".")

[...]

Is this OK? Instead of

(eq (system-type 'darwin))

shouldn't it be

(eq system-type 'darwin), etc.?

Am 23.03.2012 23:45, schrieb Richard Stanton:
> In r907, I see there's some code in py-temp-directory checking for
> system type,
>
> (and (eq (system-type 'darwin))
> (funcall ok "/var/folders"))
> ((and (or (eq (system-type 'ms-dos))(eq (system-type 'ms-dos))(eq (system-type 'windows-nt)))
> (Funcall ok (concat "c:" (py-separator-char) "Users" ))))
> (funcall ok ".")
>
> [...]
>
> Is this OK? Instead of
>
> (eq (system-type 'darwin))
>
> shouldn't it be
>
> (eq system-type 'darwin), etc.?
>
fixed, thanks