[IPython-dev] use of InteractiveShell and R magic

Brian Granger ellisonbg@gmail....
Thu Jun 14 19:34:29 CDT 2012


On Thu, Jun 14, 2012 at 5:07 PM, MinRK <benjaminrk@gmail.com> wrote:
>
>
> On Thu, Jun 14, 2012 at 4:30 PM, Brian Granger <ellisonbg@gmail.com> wrote:
>>
>> But don't we have similar assumptions about InteractiveShell being a
>> singleton throughout the code base.  The patterns used by the magic
>> system are by no means unique.  I am not sure I would call this a bug.
>
>
> The relevant assumption is that the Magics object itself is a singleton.
>  The magics table is *per class*, but on initialization of the first
> instance, the class mapping clobbered with the methods of the first
> instance.  Simply copying the magics dict before altering it so that it is
> an instance attribute rather than a class attribute edited by the instance
> fixes the issue. I think this is inappropriate for a class that doesn't have
> any singleton-like instance() api like the InteractiveShell does.

Ahh, OK I agree that this is not ideal.  Just saw your PR to fix this.

Cheers,

Brian

> For instance:
>
> from IPython.core.magic import magics_class, Magics, line_magic
> @magics_class
> class MyMagic(Magics):
>
>     @line_magic
>     def foo(self, line):
>         print 'hi'
>
> magic = MyMagic(None)
> magic2 = MyMagic(None)
>
> assert magic2.magics['line']['foo'].im_self is not magic # fails
>
>>
>>
>> Brian
>>
>> On Thu, Jun 14, 2012 at 4:26 PM, MinRK <benjaminrk@gmail.com> wrote:
>> >
>> >
>> > On Thu, Jun 14, 2012 at 3:57 PM, Jonathan Taylor
>> > <jonathan.taylor@stanford.edu> wrote:
>> >>
>> >> Thanks, that seems to work in a separate python process rather than the
>> >> ipython process:
>> >>
>> >> ~/workbook (metadata*) $ python -c "import
>> >> IPython.frontend.terminal.interactiveshell as IS; shell =
>> >> IS.TerminalInteractiveShell(); shell.run_cell('%load_ext rmagic');
>> >> shell.run_cell('%R X=rnorm(20); print(X)')"
>> >>  [1]  0.2125483  0.1030451 -1.4036373 -0.5617847 -0.7571675 -0.3985085
>> >>  [7] -0.4386932  0.7164915 -0.4794236 -0.1373804  0.2831013 -0.7248862
>> >> [13]  0.5260675 -0.3789804  0.1535592  1.5569203  1.0225972  0.8149846
>> >> [19] -0.9629060 -0.4161373
>> >>
>> >> ~/workbook (metadata*) $ python -c "import
>> >> IPython.frontend.terminal.interactiveshell as IS; shell =
>> >> IS.InteractiveShell(); shell.run_cell('%load_ext rmagic');
>> >> shell.run_cell('%R X=rnorm(20); print(X)')"
>> >>  [1]  0.44037484  1.31372601 -0.37253955  2.21955270 -0.07886852
>> >> -0.09022193
>> >>  [7]  0.38464850 -0.41004855  1.62648041 -0.13687832  0.91537699
>> >> -2.70125217
>> >> [13]  1.49125226  0.11580012 -0.64993087  2.49367657  0.01447792
>> >>  0.57408249
>> >> [19] -0.80559871 -0.76346964
>> >>
>> >> So, for interactively running this in ipython I should expect to see
>> >> this
>> >> load_ext failure?
>> >>
>> >
>> > You are running into some singleton assumptions in the new magics system
>> > -
>> > each Magics class methods are only registered once, and thus bound to
>> > the
>> > first Shell that load the magic.
>> >
>> > So what you are seeing is that shell.magic("load_ext rmagic") is
>> > actually
>> > triggering the load_ext magic on the *original* IPython instance.  I
>> > think
>> > this should be considered a bug.
>> >
>> >>
>> >> Thanks,
>> >>
>> >> Jonathan
>> >>
>> >> On Thu, Jun 14, 2012 at 3:48 PM, Thomas Kluyver <takowl@gmail.com>
>> >> wrote:
>> >>>
>> >>> On 14 June 2012 23:44, Jonathan Taylor <jonathan.taylor@stanford.edu>
>> >>> wrote:
>> >>> > Actually, I want to create an InteractiveShell inside another python
>> >>> > process. Maybe I should use embed?
>> >>>
>> >>> Embed's not terribly relevant here - that creates an InteractiveShell,
>> >>> but attempts to use the namespace from which it's called.
>> >>>
>> >>> Try it in a separate Python process. Don't forget to %load_ext rmagic
>> >>> first.
>> >>>
>> >>> Thomas
>> >>> _______________________________________________
>> >>> IPython-dev mailing list
>> >>> IPython-dev@scipy.org
>> >>> http://mail.scipy.org/mailman/listinfo/ipython-dev
>> >>
>> >>
>> >>
>> >>
>> >> --
>> >> Jonathan Taylor
>> >> Dept. of Statistics
>> >> Sequoia Hall, 137
>> >> 390 Serra Mall
>> >> Stanford, CA 94305
>> >> Tel:   650.723.9230
>> >> Fax:   650.725.8977
>> >> Web: http://www-stat.stanford.edu/~jtaylo
>> >>
>> >> _______________________________________________
>> >> IPython-dev mailing list
>> >> IPython-dev@scipy.org
>> >> http://mail.scipy.org/mailman/listinfo/ipython-dev
>> >>
>> >
>> >
>> > _______________________________________________
>> > IPython-dev mailing list
>> > IPython-dev@scipy.org
>> > http://mail.scipy.org/mailman/listinfo/ipython-dev
>> >
>>
>>
>>
>> --
>> Brian E. Granger
>> Cal Poly State University, San Luis Obispo
>> bgranger@calpoly.edu and ellisonbg@gmail.com
>> _______________________________________________
>> IPython-dev mailing list
>> IPython-dev@scipy.org
>> http://mail.scipy.org/mailman/listinfo/ipython-dev
>
>
>
> _______________________________________________
> IPython-dev mailing list
> IPython-dev@scipy.org
> http://mail.scipy.org/mailman/listinfo/ipython-dev
>



-- 
Brian E. Granger
Cal Poly State University, San Luis Obispo
bgranger@calpoly.edu and ellisonbg@gmail.com


More information about the IPython-dev mailing list