On 01/26/2012 07:26 PM, Andreas Roehler wrote:
> thank, Yagnesh,
>
> pasting below from
> https://code.launchpad.net/~yagnesh/python-mode/py-shell et al
>
>> So you mean to say py-shell-name has no business in calling shell and
> its only for come as 'default' if all others fail?
>
> Basically.
> Having multiple choices, you can't avoid some hierarchical order making
> a selection.
>
> if hard-coded `py-shell-name' always should prevail, you must it change
> when executing code designed for a different Python by shebang.
>
> The assumtion so far: shebang knows best which Python to use. Therefor
> preceding by default.
>
> Will consider possible change of py-execute-region permitting to enforce
> a shell independent from shebang, accepting an optional argument "execute-with-this-shell-instead-of-shebang",
> would replace "&optional async"
Its seems fine reasonable. May be providing a customizing hook just
before calling the execution would shut up raising voices (like me)
On 01/26/2012 07:26 PM, Andreas Roehler wrote: /code.launchpad .net/~yagnesh/ python- mode/py- shell et al with-this- shell-instead- of-shebang" ,
> thank, Yagnesh,
>
> pasting below from
> https:/
>
>> So you mean to say py-shell-name has no business in calling shell and
> its only for come as 'default' if all others fail?
>
> Basically.
> Having multiple choices, you can't avoid some hierarchical order making
> a selection.
>
> if hard-coded `py-shell-name' always should prevail, you must it change
> when executing code designed for a different Python by shebang.
>
> The assumtion so far: shebang knows best which Python to use. Therefor
> preceding by default.
>
> Will consider possible change of py-execute-region permitting to enforce
> a shell independent from shebang, accepting an optional argument "execute-
> would replace "&optional async"
Its seems fine reasonable. May be providing a customizing hook just
before calling the execution would shut up raising voices (like me)
Thanks
PS: I got to say this, you are super fast