headers
Dave Grote | 3 Jan 23:11
Favicon

__main__ vs __main__


Hello All,
  Is there a nice way of getting ipython to use the original __main__ 
rather than creating its own? In my code, I have python calling C code, 
which then calls python code, using PyRun_SimpleString. The 
PyRun_SimpleString will call, for example, a function defined in python 
before the C code is called. This works fine in plain python. But not in 
ipython - it by default creates its own name space which 
PyRun_SimpleString can't directly get at. I came up with the following, 
which seems to work ok,

import __main__
__main__.__name__ = "__mynamespace__"
import IPython
IPython.Shell.start(user_ns=__main__.__dict__).mainloop()

Setting __name__ is needed to prevent the ipython __main__ from being 
replaced by a FakeModule, which doesn't seem to interact with 
PyRun_SimpleString. Is this a sensible solution? Has anyone else done 
this kind of thing?
  Any and all comments welcome! Thanks!
      Dave
Permalink | Reply | 6 comments |
headers
Vincent Schut | 4 Jan 09:58
Picon

ipython1: cleaning up engines

Hi ipython folks,

toying with ipython1's distributed computing, nice!
However, I wonder if there is a way to force an engine/all engines to
really clean up or restart, without having to switch to my ssh console,
kill the engines, and restart them. Because every time I make a change
to the source of the class of which instances are being distributed, the
engines just fail to reload my new version and keep reusing the old one,
probably because python usually only imports a module once. Issueing a
rc.clearPropertiesAll() does not work, the only thing that seems to work
is hard restarting all engines. Did I miss something? Is there a simple
way to force my engines to return to a really clean state?

Cheers,
Vincent.
Permalink | Reply | 1 comment |
headers
Fernando Perez | 4 Jan 11:16
Picon
Gravatar

Re: ipython1: cleaning up engines

On Jan 4, 2008 1:58 AM, Vincent Schut <schut <at> sarvision.nl> wrote:
> Hi ipython folks,
>
> toying with ipython1's distributed computing, nice!
> However, I wonder if there is a way to force an engine/all engines to
> really clean up or restart, without having to switch to my ssh console,
> kill the engines, and restart them. Because every time I make a change
> to the source of the class of which instances are being distributed, the
> engines just fail to reload my new version and keep reusing the old one,
> probably because python usually only imports a module once. Issueing a
> rc.clearPropertiesAll() does not work, the only thing that seems to work
> is hard restarting all engines. Did I miss something? Is there a simple
> way to force my engines to return to a really clean state?

We currently don't have a full 'engine restart' command, but it's
certainly in the plans, along with options for killing remote engines
and doing other types of process-level control of the engines from
within the controller, even when the engines may be unresponsive due
to being stuck in extension code, for example.

But for now, you could do the kind of thing that can also be issued at
an interactive single-session ipython, which is to use the reload()
command.  You can tell all of your engines to

rc.executeAll('reload(foo)')

and they will all reload the foo module.  Assuming that you've made
the updated source available to the engines, this will work for all
non-extension modules.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Fernando Perez | 4 Jan 11:23
Picon
Gravatar

Re: __main__ vs __main__

Hi Dave,

On Jan 3, 2008 3:11 PM, Dave Grote <dpgrote <at> lbl.gov> wrote:
>
> Hello All,
>   Is there a nice way of getting ipython to use the original __main__
> rather than creating its own? In my code, I have python calling C code,
> which then calls python code, using PyRun_SimpleString. The
> PyRun_SimpleString will call, for example, a function defined in python
> before the C code is called. This works fine in plain python. But not in
> ipython - it by default creates its own name space which
> PyRun_SimpleString can't directly get at. I came up with the following,
> which seems to work ok,
>
> import __main__
> __main__.__name__ = "__mynamespace__"
> import IPython
> IPython.Shell.start(user_ns=__main__.__dict__).mainloop()
>
> Setting __name__ is needed to prevent the ipython __main__ from being
> replaced by a FakeModule, which doesn't seem to interact with
> PyRun_SimpleString. Is this a sensible solution? Has anyone else done
> this kind of thing?
>   Any and all comments welcome! Thanks!
>       Dave

Your approach is probably as good as I can think of, and it's why
ipython offers the user the option of providing his own execution
namespace.  I know we've had plenty of problems in the past with using
the plain python __main__, which is why we resorted to the hack of
(Continue reading)

Permalink | Reply | 5 comments |
headers
Jörgen Stenarson | 4 Jan 18:53
Picon

Re: Several problems with cp720 (Arabic Windows-1256)

Diaa Sami skrev:
> Hi,
> I'm having problems with IPython with all versions after 0.7.3, and I just found that there are
> problems with the most recent pyreadline too.
> I'm on an English Windows XP system with Arabic language support(which means that
> sys.stdin.encoding='cp720'), Control Panel > Regional and Language options > Advanced tab > Arabic
> (Egypt) selected.
> You can find the problematic cases below
> 1- I upgraded to a recent IPython(0.8.1) but I left the old pyreadline-1.3, IPython starts properly
> but whenever I enter any text I get the following error:
> 
Diaa,

The problem is that current versions of python does not support cp720. 
After some googling it seems there are fixes in the trunk for python but 
that doesn't help us.

For me (using swedish windows) the default codepage of the cmd.exe is 
cp850. But there is a mismatch to the encoding used in the filesystem 
which makes it more convenient for me to always launch cmd.exe such that 
it switches to cp1252 using the command chcp 1252. Perhaps you could try 
to do the same but with chcp 1256 to get arabic.

You could also try adding:
import pyreadline.unicode_helper
pyreadline.unicode_helper.pyreadline_codepage="cp1256"

to force pyreadline to use another codepage than the default, however 
this may not work if there is a mismatch between 1256 and 720.
(Continue reading)

Permalink | Reply | 1 comment |
headers
Jörgen Stenarson | 4 Jan 18:55
Picon

Re: PyReadline: No tab completion if sys.stdout is redirected

Dirk Loss skrev:
> Hi Jörgen,
> 
> I think I found the problem: The string buffer passed to the 
> WriteConsoleW function must not be bigger than 64k (see [1] for reference).
> 
> So if our output text is longer, we have to split it into several parts 
> and print each one separately. A patch is attached. It's rather 
> quick&dirty but I hope you'll get the idea.
> 
> Regards
> Dirk
> 
> [1] http://msdn2.microsoft.com/en-us/library/ms687401.aspx
> 
> 
Dirk,

I have comitted a patch similar to yours. Could you update and try it out?

/Jörgen
Permalink | Reply | 2 comments |
headers
Jörgen Stenarson | 4 Jan 19:13
Picon

Re: Finally, ipython works in emacs

wang frank skrev:
> I have fixed the problem. After adding the code at line 380, I also need 
> to add WriteFile at 149. It is great to make this work.
>  
> How to setup the EMACS environment in ipython? Why these codes have been 
> removed from pyreadline?
>  
> Thanks
>  
> Frank
I'm happy to hear you got it to work. I think the code disappeared in 
when we did some code reorganization a while back. And since I don't use 
emacs I never realized it.

The purpose of the EMACS environent variable test is that you should be 
able to set that variable from emacs before starting ipython thus 
ensuring that this code only runs if ipython is launched from emacs. I 
don't know how to do this in emacs so if you have some other idea on how 
  to achieve the same goal please let me know.

If possible please send a patch file for your changes generated by svn 
diff. (Don't forget to svn up first)

/Jörgen

> 
> 
>     ------------------------------------------------------------------------
>     From: fw3 <at> hotmail.co.jp
>     To: jorgen.stenarson <at> bostream.nu
(Continue reading)

Permalink | Reply | 0 comments |
headers
Dirk Loss | 4 Jan 21:04
Picon
Favicon

Re: PyReadline: No tab completion if sys.stdout is redirected

Jörgen Stenarson wrote:
> I have comitted a patch similar to yours. Could you update and try it out?

Your patch is definitely better than mine and it works nicely.
Thank you very much.

Regards
Dirk
Permalink | Reply | 1 comment |
headers
Noah Gift | 4 Jan 23:29
Picon
Gravatar

advice for Leopard

I have been super, massively busy, so I haven't been able to follow up  
on this, but could some kind sole, update the ipython webpage for  
instructions on configuring IPython properly for Leopard?  I have seen  
a few complaints on the PyObjc list too.  Actually, it is good to  
mention that PyObjc could be a great user base for IPython, as the  
method and class names are absolutely ridiculously long :)

Noah
Permalink | Reply | 0 comments |
headers
wang frank | 5 Jan 00:36
Picon

tab completion in emacs

I am running the ipython 0.8.2 in emacs 23. The tab completion of the cd command in emacs behaves different from the ipython shell outside emacs.
 
In the emacs, if you type under the c:\:
 
   cd Program(tab)
 
it will complete the command as:
  cd Program\ Files\
 
If you add a \ at the end
  cd Program\ Files\
 
Then type the tab key, instead of listing the files under the program files directory, ipython lists all ipython command and the files under the root directory.
 
Does anyone know how to fix this issue?
 
Thanks
 
Frank
 
 

「ペットの悩み、みんなにきいたら解決した。」安心のペットライフにMSN相談箱 http://questionbox.msn.co.jp/c531.html 
_______________________________________________
IPython-user mailing list
IPython-user <at> scipy.org
http://lists.ipython.scipy.org/mailman/listinfo/ipython-user
Permalink | Reply | 0 comments |

Gmane