[IPython-dev] Jupyter and Other Kernels
Matthias Bussonnier
bussonniermatthias at gmail.com
Sat Feb 21 13:57:08 EST 2015
Le 21 févr. 2015 à 10:40, John Omernik <john at omernik.com> a écrit :
> Thanks for the info on the magics. I'll think that one through. Both
> of these issues are interesting in that Kernel devs can be totally
> independent of Jupyter in style (yes they have to follow the API) but
> stylistically, they don't and thus there is not going to be easy
> movement from one kernel to another for users...
Like many things, it would be nice to have a common place to
have configuration, and we would be happy to have people from other
languages comme into Jupyter steering comity and decide that
it would be a topic to tackle.
But it is not something we can enforce, or even want to try to tackle,
as we are mostly python programmer, and we are not completely aware
of the need of other languages.
Let say we create a common place for configuration,
then people using many kernels will feel at home.
Though, people coming from other IDE, or programming environment
would be lost.
What if I suddenly tell you that if you use in browser ipython terminal
your .bashrc is not read anymore and that you have to use
/usr/local/jupyter/profile_xxx/terminal/.bashrc ?
Would you be happy ? Would we be happy to get 30+ bug report per month
of people not reading the docs ?
I'll take the example of .xdg spec, which is a nice spec.
but if you take 30 people and put them into a room for a month so that they
produce a spec. You will end up with something that has probably some good points,
but most likely can't be applied in real-world.
So I wouldn't juge before having tried to see what we can do to juge what
would be the best way.
There is one things for sure, it is always easier to add a feature, that to remove one.
--
M
> Not a terrible thing
> and maybe that's fine for most users, but hmm... lots to think about
> here.
> Thanks!
>
> On Sat, Feb 21, 2015 at 12:26 PM, Matthias Bussonnier
> <bussonniermatthias at gmail.com> wrote:
>>
>> Le 21 févr. 2015 à 09:04, John Omernik <john at omernik.com> a écrit :
>>
>>> Since the Kernels that are developed for Jupyter look to be different
>>> projects, I am guessing that my question is ok to ask here, but
>>> understand if the response is "not an iPython or Jupyter" question.
>>
>> The question looks fine here.
>>
>>>
>>> I am playing with the iRKernel. https://github.com/takluyver/IRkernel
>>> and have a few questions on how kernels in general interact with
>>> Jupyter (not just IRKernel)
>>>
>>>
>>> 1. Magics: Based on what I am seeing in the iRKernel, Magics appear to
>>> be a "per Kernel" thing rather than a Jupyter thing. Is this correct?
>>> In the iRKernel %lsmagic gets me
>>
>> Yes, they are per-kernel.
>> If you write a python-base one, looks at Doug Blank Metakernel
>> that add some facilities to write magics.
>>
>>>
>>> Error in parse(text = x, srcfile = src): <text>:1:1: unexpected input
>>> 1: %lsmagic
>>
>> As magic are per-kernel, the kernel is responsible to parse them.
>> %lsmagic could be a perfect valid syntax in (perl | php | OCaml | ....)
>> because it is **not** valid syntax in Python, wa can make them magic in
>> IPython.
>>
>>>
>>> So anythoughts on how to implement magics in other kernels if this is
>>> not case? Am I missing something basic here?
>>
>> Depends on your language.
>> Julia decided they did not need magics.
>> For example shell access in julia is with `;`
>> but it's a property of the language.
>>
>> Julia have strings macro, so that can do:
>> matlab"""
>> (some matlab code)
>> """
>>
>> Ruby have the same.
>>
>> Advice:
>> Pick a syntax that is not valid R. and pre-parse to make it valid R.
>> which is what IPtyhon does.
>>
>>>
>>> 2. So I have a some stuff running in iPython through my
>>> profile_default startup directory. How do duplicate this so when an R
>>> Kernel starts up, I can have certain imports run all the time etc. Is
>>> that a kernel specific thing as well?
>>
>> That depends on your kernel.
>> The kernel do whatever it likes.
>> If it want to copy us and run the .r files in .ipython/startup, I suppose that would be fine.
>>
>> If we wan another common way of doing things, we can do a working group.
>> But obviously, .py fies are not the right way to configure a R process.
>>
>> --
>> M
>>
>>
>>> Thanks1
>>> _______________________________________________
>>> IPython-dev mailing list
>>> IPython-dev at scipy.org
>>> http://mail.scipy.org/mailman/listinfo/ipython-dev
>>
>> _______________________________________________
>> IPython-dev mailing list
>> IPython-dev at scipy.org
>> http://mail.scipy.org/mailman/listinfo/ipython-dev
> _______________________________________________
> IPython-dev mailing list
> IPython-dev at scipy.org
> http://mail.scipy.org/mailman/listinfo/ipython-dev
More information about the IPython-dev
mailing list