These are chat archives for ipython/ipython

28th
Apr 2015
Brian E. Granger
@ellisonbg
Apr 28 2015 03:17
@dalejung @minrk Sorry I am way behind on stuff right now...I think it depends on what is meant by an IDE
If you mean text editor + terminal + notebook all on one pages in a paneled/tabbed layout system
Then yes we are moving in that direction
In my mind rodeo is in that category (currently)
However, some people mean something very different by IDE - they think of Ecllipse or Visual Studio type applications focused on handling software projects with millions of lines of code
But perhaps the more important shift in our direction is that our frontend code will be modular so others can easily add new or alternative components on the page without reinventing everything
We may not ship something by default like rodeo, but I expect that it will be only a few lines of code or configuration to build something like that
Min RK
@minrk
Apr 28 2015 15:14
@SylvainCorlay you mentioned simplifying the trait-side link, dlink. What do you think about removing link, dlink from traitlets and moving them to widgets? They seem really widget-specific.
Brian E. Granger
@ellisonbg
Apr 28 2015 16:02
@minrk we are using link in nbgrader to link config=True attributes in various places
Min RK
@minrk
Apr 28 2015 16:03
hm, weird. What for?
Brian E. Granger
@ellisonbg
Apr 28 2015 16:03
It is hard to explain, better to describe at the dev meeting...
Min RK
@minrk
Apr 28 2015 16:03
It seems like link should only ever be used for after-the-fact linking of traits of objects you don't control.
ok
Used to consolidate config across a set of classes that don't inherit from a common base
Min RK
@minrk
Apr 28 2015 16:04
Should the values ever be allowed to diverge?
Brian E. Granger
@ellisonbg
Apr 28 2015 16:05
I don't think so
Only one of the classes is ever instantiated in a given process - they are the different nbgrader sub-apps
Min RK
@minrk
Apr 28 2015 16:05
So the link is never hooked up to anything?
Brian E. Granger
@ellisonbg
Apr 28 2015 16:05
Some of those apps are nbconvert subclasses, others are not
Min RK
@minrk
Apr 28 2015 16:06
Seems like a perfect case for properties instead of trait links.
Brian E. Granger
@ellisonbg
Apr 28 2015 16:06
Not quite sure what you mean by that. The link is between the app class and the common config class
We can definitely ask Jess
Min RK
@minrk
Apr 28 2015 16:07
sure
Brian E. Granger
@ellisonbg
Apr 28 2015 16:07
But I have also used link in other non-widget code
Min RK
@minrk
Apr 28 2015 16:07
ok
Brian E. Granger
@ellisonbg
Apr 28 2015 16:07
Would have to look up where - don't remember right now
Min RK
@minrk
Apr 28 2015 16:07
It doesn't make any sense to me, but if it's already in use, might as well leave it where it is.
Brian E. Granger
@ellisonbg
Apr 28 2015 16:08
Lets put it on the agenda for today - I am open to it moving, but I definitely see the usage cases for it being in traitlets
Matthias Bussonnier
@Carreau
Apr 28 2015 17:00
meeting ?
Brian E. Granger
@ellisonbg
Apr 28 2015 17:01
yep
At least I think so...
Sylvain Corlay
@SylvainCorlay
Apr 28 2015 18:26
@minrk, sorry for the late reply
So regarding the trait-link, I would be ok to move it to widgets.
The first modification that I wanted to do is one of the following:
  • Only allow only for one target HasTrait, and rollback to the previous value in case of TraitError when setting the link.
  • Or, keep the multiple targets HasTrait but make the following change: in case of a TraitError when setting the link, don't stop setting links for the following targets in the list. Otherwise you end up with half the links set up...
The first option is not backward compatible but simplifies things.
Sylvain Corlay
@SylvainCorlay
Apr 28 2015 18:37
By the way, I recall that you were opposed to having success and failure callbacks in link.