[IPython-dev] Using IPython notebooks to teach Python

Doug Blank doug.blank at gmail.com
Fri Aug 22 08:23:53 EDT 2014

You may also want to follow the development of the Jupyter Hub for IPython3:


Although I suspect that IPython3/Jupyter won't be released for months, I
was able to login (via my Linux id and password) with the code as of
yesterday. In addition, I was able to use our new IPython3 kernels without
any obvious issues. It looks like it will be very easy to substitute the os
authentication for another.

I'm making plans to use this multi-user hub in the classroom as soon as
possible this semester. (I'm teaching Programming Languages, and so easily
switching between languages should make an interesting basis for the


On Fri, Aug 22, 2014 at 8:12 AM, Moritz Beber <moritz.beber at gmail.com>

>> I have just discovered this project:
>> https://github.com/cni/ipython-hydra
>> Which seems even closer to yours than ipydra.
>> Are you able to say what differs between your project and this one?
>> Is it just a matter of one having a web interface and the other not, or
>> can you see other differences?
> The main difference is explained in one of their paragraphs:
> "addldapuser will add a new user to the system, if they don't already
> exist. It must be run as root. The password is disabled because we use
> Stanford's kerberos authentication, so if users log in via ssh they can
> authenticate with their SUNet ID and password. The new user is also added
> to the ipython group. If the user exists in Stanford LDAP, then their UID
> will be assigned by the LDAP result. Otherwise, a local UID is used."
> They integrated it with an LDAP server and that is something I shied away
> from. The integration with that LDAP server is hard coded into their bash
> scripts so it would have taken me some time to decouple it. On top of that
> I needed to run the server both on Mac and Linux, so it was easier for me
> to use Python for that cross-platform compatibility.
> Another difference is that they spawn notebooks and then check the port
> assigned whereas my script assigns the port deterministically (but does not
> actually check whether that port was already in use before - so that's
> desperately needed). So assigning ports beforehand (with the proper checks)
> might be nicer when you need to open firewall ports only in a certain range.
> I wouldn't mind improving the whole script to update it to the new IPython
> 2.0 and make it Python 3.0 compatible, and use a simple sqlite database. I
> have time for that after September 8. If that's not too late for you, we
> could then also talk about specific problems and feature requests.
> Cheers
> _______________________________________________
> IPython-dev mailing list
> IPython-dev at scipy.org
> http://mail.scipy.org/mailman/listinfo/ipython-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ipython-dev/attachments/20140822/4694c5d4/attachment.html>

More information about the IPython-dev mailing list