These are chat archives for ipython/ipython

20th
Oct 2014
Sylvain Corlay
@SylvainCorlay
Oct 20 2014 02:10
hey, anyone knows how to generate the css since the fabfiles got removed?
Sylvain Corlay
@SylvainCorlay
Oct 20 2014 03:26
nevermind
Kyle Kelley
@rgbkrk
Oct 20 2014 13:16
Is there a way to determine where the IPython sources are being used from, dynamically?
This would be for getting the static assets.
ipython locate gives me the dotfiles
Jason Grout
@jasongrout
Oct 20 2014 13:21
@akloster: it would be nice if we could test for capabilities like widgets. I think that is orthogonal to testing to see if we are running in a notebook.
Andreas Klostermann
@akloster
Oct 20 2014 13:23
I tried this:
        try:
            assert(hasattr(IPython.get_ipython(), 'comm_manager'))
        except (AssertionError, NameError, KeyError) as e:
            raise NotImplementedError(_no_notebook_error_message)
you need to import IPython and define a _no_notebook_error_message
and yes it would be nice to figure out if there is a notebook running or if there is widget capability. Currently I think it is best to depend on the comm_manager attribute
Andreas Klostermann
@akloster
Oct 20 2014 13:29
regarding static files it would also be useful to serve http requests from the notebooks url handler. For example for code maps, or certain libraries that depend on using ajax requests
but then the notebook is about 80% of the way into becoming a web application framework
Jason Grout
@jasongrout
Oct 20 2014 13:31
You can access files from the notebook directory, via the files/ url
Andreas Klostermann
@akloster
Oct 20 2014 13:36
That's not the same thing. For one, this doesn't allow me to serve requests dynamically, and for another I need to have actual files located in the notebook's directory. That's not very convenient for notebook-aware libraries which would rather serve static files from some place else
Jason Grout
@jasongrout
Oct 20 2014 13:36
right. It sounds like your case needs an extended notebook app .py file
Andreas Klostermann
@akloster
Oct 20 2014 13:37
currently I don't have a case... but I am working on a simple asset manager...
I was frustrated with trying to integrate coffeescript into notebook aware libraries
because the code maps want to be in a certain place with a certain name. But I found a way around that.
My personal opinion tends to recommending against notebook extensions and towards packages/libraries wherever possible. This makes documenting requirements for individual notebooks easier.
Andreas Klostermann
@akloster
Oct 20 2014 13:43
For a presentation I am giving this weekend I'll be using live_reveal, and I tend to write all sorts of css/html/javascript into the notebook. Not ideal, but then again IPython notebook wasn't meant as a presentation tool. Still damn cool.
Remi Rampin
@remram44
Oct 20 2014 17:55
Hi! It looks like IPython "master" unconditionally creates a new root logger, and now my application logs everything twice.
See IPython/utils/log.py
this looks like very dangerous and annoying behavior
Matthias Bussonnier
@Carreau
Oct 20 2014 17:57
Why dangerous ? I can understand the annoying. You can open an issue on github.
Remi Rampin
@remram44
Oct 20 2014 17:59
Right: #6746
Matthias Bussonnier
@Carreau
Oct 20 2014 18:01
Thanks, we'll investigate to get a better approach.
in the meantime, if you have an idea, PR welcome.
Sylvain Corlay
@SylvainCorlay
Oct 20 2014 18:15
Hi
Jason Grout
@jasongrout
Oct 20 2014 18:15
@ellisonbg, @minrk, et. al. - what guarantees do we have in the case two browser windows open the same notebook, in regards to saving the notebook?
If there are no guarantees, what about, at least for now, before a set of changes is saved, it checks to see the status on disk, and if the notebook has been changed since we last knew about it, return an error and ask the user to refresh before saving.
(i.e., if the notebook file is different from what we thought it should be, then ask the user to refresh, rather than blindly overwriting the notebook file)
Sylvain Corlay
@SylvainCorlay
Oct 20 2014 18:20
Quick idea, that I would like to run by the core devs regarding traitlets:
-> How about a metadata attribute in traitlets, "readonly=True", making the attribute only modifiable from the front-end in the case of a widget. If you try to set it, you would get an AttributeError if you try to set it externally.
-> there could be a context manager that you could use to force the assignment.
I guess @minrk would be the right person to ping on this.
Jason Grout
@jasongrout
Oct 20 2014 18:21
can you give an example?
Min RK
@minrk
Oct 20 2014 18:22
@jasongrout no guarantees at all. It behaves the same way as opening the same file with two text editors.
Jason Grout
@jasongrout
Oct 20 2014 18:23
usually a good text editor will let you know when a file has changed from underneath you, and give you an option to save or reload
that's what I'm suggesting, basically
Sylvain Corlay
@SylvainCorlay
Oct 20 2014 18:23
@jasongrout , to handle computed values to be exposed from the javascript side.
Min RK
@minrk
Oct 20 2014 18:24
I think that's reasonable.
@SylvainCorlay you can handle that with _trait_changed(name, old, new)
Sylvain Corlay
@SylvainCorlay
Oct 20 2014 18:25
absolutely, although it could be nice to have a general mechanism in HasTraits.
Min RK
@minrk
Oct 20 2014 18:25
I don't think the use case is common enough to warrant that
But maybe it is. There's a disadvantage, implementation-wise, in traitlets vs properties
Jason Grout
@jasongrout
Oct 20 2014 18:26
Initially, +1 to @minrk there. At least, it would be useful to develop the pattern before pushing it upstream
Min RK
@minrk
Oct 20 2014 18:28
The disadvantage is that only validate fires before assignment. the _foo_changed events only fire after a change, so would have to 'undo' the bad assignment.
Otherwise, you would have to modify validate to throw an exception
Sylvain Corlay
@SylvainCorlay
Oct 20 2014 18:29
probably.
The use case occurs
1) when validation and custom logic is implemented in the overloaded models. You want to expose the computed values to the Python.
2) in a quick wrapper I was putting together where you use introspection of a function to develop a wrapper HasTraits instance, with one attribute by argument plus a returned value traitlet attribute, that is only computed.
Matthias Bussonnier
@Carreau
Oct 20 2014 18:30
Would prefer to split traitlets in a separate package before adding things to it.
personal opinion.
Sylvain Corlay
@SylvainCorlay
Oct 20 2014 18:35
The only thing to be added is a context manager "force" in HasTraits and an additional readonly attribute in the traitlets types, equal to False by default.
Min RK
@minrk
Oct 20 2014 18:37
traits proper has a ReadOnly trait
Sylvain Corlay
@SylvainCorlay
Oct 20 2014 18:40
Pseudocode
class bar(HasTraits):
    x = Unicode(0)
    y = Any(None, readonly=True)

    def __init__(self, foo, **kwargs):
        self.foo = foo
        super(bar, self).__init__(**kwargs)
        self.on_trait_change(self._compute, name='x')

    def _compute(self, name, value):
        with self.force():
            self.y = self.foo(value)
Sylvain Corlay
@SylvainCorlay
Oct 20 2014 18:48
@minrk you mean Enthought's traits?
Min RK
@minrk
Oct 20 2014 18:48
I do
Sylvain Corlay
@SylvainCorlay
Oct 20 2014 18:48
meaning that you think that it is in scope for the traitlets to have something along these lines?
Min RK
@minrk
Oct 20 2014 18:49
That's the reference implementation. Traitlets only exists because traits proper couldn't be built without a C compiler. If traits were installable without compilation, we probably would have just added it as a dependency.
Maintaining a system for this kind of thing (especially new features) was never a goal.
But that said, just like everything else, we end up doing things we never plan to.
Especially maintaining support for previously out of scope functionality
Historically, any deviation from traits behavior in traitlets was considered a bug
Just based on the definition of traitlets - a pure Python subset of traits
Min RK
@minrk
Oct 20 2014 18:55
Since we are moving traitlets to its own project, I think the inevitable interpretation is 'a pure python fork of traits', where divergence is discouraged, but allowed.
Sylvain Corlay
@SylvainCorlay
Oct 20 2014 18:55
although I guess that as you use traitlets a lot in IPython, you probably had good ideas on how make it better.
for example, you often need to make a closure to have the handler of on_trait_change have a reference to the HasTraits instance that triggered the event.
Min RK
@minrk
Oct 20 2014 19:15
It rarely (if ever) comes up in IPython itself, because trait notification callbacks are ~universally methods on the HasTraits.
Widgets being HasTraits interacting with each other is the first time that has really come up.
And it doesn't come up in anything in vanilla IPython, only third party users of Widgets.
Jason Grout
@jasongrout
Oct 20 2014 21:10
@minrk: is there some value stored inside the notebook that will change if the notebook changes in any way? Will the signature change if any cells change? I'm trying to think through how to provide some basic "reload or error if changed, rather than save" logic
Min RK
@minrk
Oct 20 2014 21:11
You could check mtime, that's already in the model
rather than content
Jason Grout
@jasongrout
Oct 20 2014 21:11
sure, that makes sense too, and is much faster
I guess that's the standard thing to do.
Min RK
@minrk
Oct 20 2014 21:12
any file model includes last_modified timestamp. If the notebook js just keeps track of that and includes it in the save model, the server can check
or the client can do everything, just querying for last_modified and comparing with what's already stored
rather than try to save, fail, try again (sending the content twice), just check for last_modified before sending the save request
move the logic to the editor rather than the server
Jason Grout
@jasongrout
Oct 20 2014 21:13
and then disable the save button, with a message to refresh
well, there should probably be the option to force save, though
Min RK
@minrk
Oct 20 2014 21:13
I wouldn't disable save, just confirm
Jason Grout
@jasongrout
Oct 20 2014 21:13
right
Min RK
@minrk
Oct 20 2014 21:13
disabling save ensures data is lost just like clobbering
Jason Grout
@jasongrout
Oct 20 2014 21:14
yes, good point
Min RK
@minrk
Oct 20 2014 21:14
it's just letting the first save clobber the second, rather than the other way around (which seems strictly worse than current behavior)
Jason Grout
@jasongrout
Oct 20 2014 21:14
yes, yes, agreed!
Jason Grout
@jasongrout
Oct 20 2014 21:25
@minrk: ipython/ipython#6750
Min RK
@minrk
Oct 20 2014 21:25
excellent, thanks