These are chat archives for ipython/ipython

11th
Feb 2015
Min RK
@minrk
Feb 11 2015 00:01
I don't have a lot of nice things to say for autogen api docs
I wonder if it will be nice or not to be able to drop iptest in most packages
only core and parallel should be using the iptest machinery, the rest should be able to just use nose.
Thomas Kluyver
@takluyver
Feb 11 2015 00:03
neither do I, generally, but the thought of documenting APIs without that automation is even more offputting
yes, I think being able to limit the use of iptest will probably be a good thing
Min RK
@minrk
Feb 11 2015 00:03
Agreed.
Thomas Kluyver
@takluyver
Feb 11 2015 00:03
by the way, did you see https://github.com/skoczen/polytester recently?
Min RK
@minrk
Feb 11 2015 00:03
I removed autogen API in pyzmq
I still use autodoc, I just don't autogen the rst
Thomas Kluyver
@takluyver
Feb 11 2015 00:04
I suspect it's a bit of a Hipster project, but it might be worth a look for the notebook test suite
yeah, I do that for most of my smaller projects
but it's a daunting prospect for something as big as IPython
Min RK
@minrk
Feb 11 2015 00:04
pyzmq has a very small, super stable API
Thomas Kluyver
@takluyver
Feb 11 2015 00:04
at least until we define an officially public subset of the API
Min RK
@minrk
Feb 11 2015 00:04
which we probably should
Thomas Kluyver
@takluyver
Feb 11 2015 00:05
indeed
maybe that will be easier to do for subsets of the project post big-split
Min RK
@minrk
Feb 11 2015 00:05
I imagine so
and with smaller projects, we can experiment with different approaches
e.g. I'm trying out nothing but GitHub Wiki on JupyterHub (crazy, and probably terrible)
Thomas Kluyver
@takluyver
Feb 11 2015 00:07
I like RTD for my smaller projects
the setup could be more streamlined, but then there's no need to think about hosting and building docs, which is good
This message was deleted
gah
Min RK
@minrk
Feb 11 2015 00:08
lol
Mathieu
@mathieu1
Feb 11 2015 00:20
Hello there! Quick question regarding #7681 [sorry to bother with 4.0 stuff] : during this morning’s meeting someone mentionned “splitting the PR”, I’m unsure what that would mean. Is that OK if I just commit a simpler version in that same branch? Or should I banch off and create another PR?
Min RK
@minrk
Feb 11 2015 00:20
same branch is fine. We leave it up to you for how you want to organize your own branches.
Mathieu
@mathieu1
Feb 11 2015 00:21
Ok thanks.
Petra Chong
@rekcahpassyla
Feb 11 2015 13:50
Hi there- last week, I asked about soft shutdown of the IPython kernel. This was because in Spyder on Windows, kernel restart is implemented as a hard process termination. Is anyone here able to point me to the bit of code in the IPython qtconsole application that causes a soft shutdown? I need this functionality in Spyder so I was thinking of changing my existing Spyder to include this, but I can't find what to include. I did have a look at the IPython qtconsole source, but I'm lost in the class hierarchy, and I can't debug it because my IDE does naughty things with monkeypatching Qt imports.
Petra Chong
@rekcahpassyla
Feb 11 2015 15:00
I have also had a look at http://ipython.readthedocs.org/en/latest/development/messaging.html but I can't seem to work out how to do it from there either
Cedric GESTES
@cgestes
Feb 11 2015 16:24
Hack of the day: I was able to switch the kernel of a notebook. (so two notebook share the same kernel). It seems to works correctly. (at least widgets are synchronised between the two). dirty commit here: kwikteam/phy@4d800f3
Jonathan Frederic
@jdfreder
Feb 11 2015 17:05
@rekcahpassyla can't you just have the kernel execute a bit of code that causes it to softly shutdown? i.e. python exit()
Thomas Kluyver
@takluyver
Feb 11 2015 17:16
@rekcahpassyla there is a shutdown_request message. Sending that should cause the kernel to shut itself down. http://ipython.org/ipython-doc/dev/development/messaging.html#kernel-shutdown
Jonathan Frederic
@jdfreder
Feb 11 2015 18:12
@takluyver 3.0 rc soon?
Peter Parente
@parente
Feb 11 2015 18:12
have you guys seen http://www.mozillascience.org/collaborate ? would it make sense to submit ipython here to at least get it listed?
Thomas Kluyver
@takluyver
Feb 11 2015 18:12
roughly aiming for Friday
@parente I hadn't seen that. It may make sense.
Peter Parente
@parente
Feb 11 2015 18:15
seems like it can't hurt. they're building a marketplace of sorts (among other thing) for open tools for science.
Thomas Kluyver
@takluyver
Feb 11 2015 18:16
I confess to being somewhat confused by that page - a list of software projects in science seems so generic as to be little use
but as you say, it can't hurt
Peter Parente
@parente
Feb 11 2015 18:19
i think the larger mission is the training and learning http://www.mozillascience.org/training. the collaborate, i agree, is just a laundry list, yet another place to list ipy to maybe get a few more eyes on it.
Thomas Kluyver
@takluyver
Feb 11 2015 18:23
can you submit it?
Peter Parente
@parente
Feb 11 2015 18:29
i think an owner of the github project has to do it. it asks for permission to view my public github projects when i try.
don't worry about it if it's hassle. just found the site in passing and figured i'd mention it here.
Thomas Kluyver
@takluyver
Feb 11 2015 18:36
I think that's just for creating an account
after all, there are projects not on Github
Peter Parente
@parente
Feb 11 2015 18:52
@takluyver i'll give it a shot if i'm not overstepping bounds by doing it. will let you know.
Thomas Kluyver
@takluyver
Feb 11 2015 18:52
thanks :)
Jason Grout
@jasongrout
Feb 11 2015 18:59
@jdfreder - maybe it'd be better to talk here?
and summarize on github
The idea on #7729 would be that straight JSON types are trasmitted just like always - absolutely no change
however, they would be inspected recursively, just like they are now for magic IPY_MODEL references
the only difference is that instead of the sync framework only recognizing IPY_MODEL strings, it recognizes the custom types lists.
if I understand you correctly, basically, you'd like to have types registered into a registry, and python and javascript would both have serializers/deserializers registered for those types
so basically, we'd just be replacing the IPY_MODEL inspection with an inspection that could load a custom serializer/deserializer
Jason Grout
@jasongrout
Feb 11 2015 19:13
However, I do agree with you that it would be simpler to have a namespace for these type names. We gave up on registered namespaces for models and views, however; perhaps we have to do the same for types?
Jonathan Frederic
@jdfreder
Feb 11 2015 19:18
@jasongrout I don't see how we could reliably determine whether or not a value object is a custom type or a dictionary. The way we do it with IPY_MODEL strings is already enough of a kludge, that if I were to sync a string with that value prefix, everything explodes.
Sylvain Corlay
@SylvainCorlay
Feb 11 2015 19:19
@jdfreder
Jason Grout
@jasongrout
Feb 11 2015 19:19
yes, that is the tricky, kludgy part.
Sylvain Corlay
@SylvainCorlay
Feb 11 2015 19:19
{
...
'IPY_TYPE': '.nbextension/...'
}
is a custom type
if it has a IPY_TYPE attribute
Jonathan Frederic
@jdfreder
Feb 11 2015 19:20
I guess that is kind of the duck type way of doing things
Jason Grout
@jasongrout
Feb 11 2015 19:20
(and in my proposal, I made it a list instead -- it seems easier and faster to check)
Sylvain Corlay
@SylvainCorlay
Feb 11 2015 19:20
{
...
}
is just a disctionary
@jasongrout agreed, but could be an early opt
Jason Grout
@jasongrout
Feb 11 2015 19:21
though I guess my way involves constructing an extra list, so maybe it's not so much better. It is easier to read, though
Sylvain Corlay
@SylvainCorlay
Feb 11 2015 19:21
in other word: the special key IPY_TYPE is reserved
Jason Grout
@jasongrout
Feb 11 2015 19:22
and of course, we could put some very unlikely unicode characters in that sentinel string too.
I'm still a bit unsettled about it, but don't see a good way around it. However, I'm also more concerned about this specifying serializer/deserializers
and how that info gets conveyed.
Sylvain Corlay
@SylvainCorlay
Feb 11 2015 19:23
anything but a dict -> usual JSON serialization / deserialization
a dict with no IPY_TYPE key -> usual JSON serialization / deserialization
a dict with IPY_TYPE key -> checks the value of the key that is the client-side traittype module string (or binds to it)
Jason Grout
@jasongrout
Feb 11 2015 19:24
do we include separate paths for each language the notebook might be talking with?
Jonathan Frederic
@jdfreder
Feb 11 2015 19:24
Well I've got an idea of how to convey that information
Using an eventful dict trait
and our existing sync mechanism
Sylvain Corlay
@SylvainCorlay
Feb 11 2015 19:24
in the hastrait class ?
Jonathan Frederic
@jdfreder
Feb 11 2015 19:24
(basically my separate message idea)
yeah
I'll show you
Sylvain Corlay
@SylvainCorlay
Feb 11 2015 19:24
cannot work:
does not handle parameterized types
Tuple(List(Unicode), Int(allow_none=True))
Jason Grout
@jasongrout
Feb 11 2015 19:26
back to the 'how do I specify a serializer/deserializer' discussion - how would you specify a 'type' from python to js, and how would you specify a 'type' back?
Sylvain Corlay
@SylvainCorlay
Feb 11 2015 19:26
anything at the HasTrait level requires having potentially trees for parameterized traits
unless you want to maintain that tree?
Jason Grout
@jasongrout
Feb 11 2015 19:27
using @SylvainCorlay's syntax: {..., IPY_TYPE: 'what/do/I/put/here'} for messages either way...
in particular, we need js messages back to python to work with multiple languages. Say Julia and python, for now.
Jonathan Frederic
@jdfreder
Feb 11 2015 19:28
@jasongrout I think both js/py serialization namespaces would have to be synced.
@SylvainCorlay no, the tree would be flattened.
@jasongrout (if we want to keep the possibility open for dynamic traits)
Sylvain Corlay
@SylvainCorlay
Feb 11 2015 19:29
it's weird to see my last name every time I am mentioned. should change my user name
Jonathan Frederic
@jdfreder
Feb 11 2015 19:29
lol
Can you do that on github?
Jason Grout
@jasongrout
Feb 11 2015 19:29
each of us has their last name in their user name
yes, you can change usernames
Sylvain Corlay
@SylvainCorlay
Feb 11 2015 19:29
Would your mechanism handle Union(Int, Date())
Jonathan Frederic
@jdfreder
Feb 11 2015 19:29
Neet
@SylvainCorlay yes
Sylvain Corlay
@SylvainCorlay
Feb 11 2015 19:30
in bitbucket it changes the URL of your repos
Jonathan Frederic
@jdfreder
Feb 11 2015 19:30
the dict would change
depending on what type was getting sent over the line
Sylvain Corlay
@SylvainCorlay
Feb 11 2015 19:30
So it would inspect the metadata of the Union on change of the Union
Sylvain Corlay
@SylvainCorlay
Feb 11 2015 19:31
OK, Github is better than bitbucket
Jason Grout
@jasongrout
Feb 11 2015 19:32
though if you change your username, you should probably register the old username to prevent people from stealing redirects
Jonathan Frederic
@jdfreder
Feb 11 2015 19:32
@SylvainCorlay actually I'm not sure, my brain's in a pickle now.
/me thinks
Jason Grout
@jasongrout
Feb 11 2015 19:33
This message was deleted
Jonathan Frederic
@jdfreder
Feb 11 2015 19:33
Edits don't work for that apparently.
Jason Grout
@jasongrout
Feb 11 2015 19:33
so back to type specifiers....
Jonathan Frederic
@jdfreder
Feb 11 2015 19:33
:smile:
Jason Grout
@jasongrout
Feb 11 2015 19:33
{..., IPY_TYPE: 'what/do/I/put/here'}
Jonathan Frederic
@jdfreder
Feb 11 2015 19:35
IPY_TYPE: {js: {'some/name/space', 'callbacks_attr_name'}, py: ['some.name.space', 'callbacks_attr_name']}}
Sylvain Corlay
@SylvainCorlay
Feb 11 2015 19:36
ɪᴩy_ᴛyᴩᴇ
Jason Grout
@jasongrout
Feb 11 2015 19:36
so what about messages from js to python?
Sylvain Corlay
@SylvainCorlay
Feb 11 2015 19:36
ipy_type
Jonathan Frederic
@jdfreder
Feb 11 2015 19:36
same
Sylvain Corlay
@SylvainCorlay
Feb 11 2015 19:36
same content
Jason Grout
@jasongrout
Feb 11 2015 19:36
especially since JSON.stringify(new Date()) just works automatically
so what if there are 100 languages that speak the widget protocol. Does the js->kernel message encode 100 different paths, one for each language?
clearly not scalable
(though it is O(n) :)
Sylvain Corlay
@SylvainCorlay
Feb 11 2015 19:37
yes. the str repr of numpy.datetime64 is exactly the one of javascript, but not the one of datetime
Jason Grout
@jasongrout
Feb 11 2015 19:38
the point here is that going from js->kernel, jsoning a list of dates returns a list of strings, not a list of custom date types
while going from kernel->js, we would have a list of custom date types
Sylvain Corlay
@SylvainCorlay
Feb 11 2015 19:40
hum you would use the traittype to serialize on the js side as well jason.
the js traittype.
Jonathan Frederic
@jdfreder
Feb 11 2015 19:41
Well wrt to the scalability question.... Registry!
:)
Sylvain Corlay
@SylvainCorlay
Feb 11 2015 19:41
that is implemented in the requirejs module specified in IPY_TYPE
from the beginning, we proposed the IPY_TYPE to provide a requirejs module path. Where do we need a registry?
Jason Grout
@jasongrout
Feb 11 2015 19:43
can you show what an example message from js-> kernel would look like for dates?
a date
Sylvain Corlay
@SylvainCorlay
Feb 11 2015 19:43
same as python->js
Jonathan Frederic
@jdfreder
Feb 11 2015 19:44
{IPY_TYPE: date_hash, value: serialized_date}
Sylvain Corlay
@SylvainCorlay
Feb 11 2015 19:44
ok, it seems we are all converging
Jonathan Frederic
@jdfreder
Feb 11 2015 19:44
registry[date_hash] = {js: {'some/name/space', 'callbacks_attr_name'}, py: ['some.name.space', 'callbacks_attr_name']}, julia: ['some.name.space', 'callbacks_attr_name']}}
Sylvain Corlay
@SylvainCorlay
Feb 11 2015 19:44
ipy_type:D
Jonathan Frederic
@jdfreder
Feb 11 2015 19:44
etc
Jason Grout
@jasongrout
Feb 11 2015 19:45
who registers the values?
it seems we've had this discussion before...
with model names, view names, etc.
Sylvain Corlay
@SylvainCorlay
Feb 11 2015 19:46
why not avoiding the registry from the start and do everything with the requirejs path?
Jonathan Frederic
@jdfreder
Feb 11 2015 19:46
I would just store it in a synced traitlet
@SylvainCorlay because we also need a path for every supported kernel
Sylvain Corlay
@SylvainCorlay
Feb 11 2015 19:47
a path to what? to the server side trait type?
Jonathan Frederic
@jdfreder
Feb 11 2015 19:47
the (de)serializing methods
Sylvain Corlay
@SylvainCorlay
Feb 11 2015 19:48
aren't they in to_json / from_json?
Jonathan Frederic
@jdfreder
Feb 11 2015 19:48
no
(de)serializing != Trait type
Sylvain Corlay
@SylvainCorlay
Feb 11 2015 19:48
why?
Jonathan Frederic
@jdfreder
Feb 11 2015 19:48
You could, with this scheme, specify different serialization for the same trait type.
Sylvain Corlay
@SylvainCorlay
Feb 11 2015 19:49
if the trait type holds the serialization / deserialization, there is no need to implement anything in the widget itself to deal with things like
Dict(Carrots) or Union(Leeks, Potato)
Jonathan Frederic
@jdfreder
Feb 11 2015 19:50
I thought the current plan was Date(serialization=blah)
Sylvain Corlay
@SylvainCorlay
Feb 11 2015 19:50
that is to optionally override it right @jasongrout ?
OK, I see that jason proposed something else
Jonathan Frederic
@jdfreder
Feb 11 2015 19:51
Well if you can override it, (de)serializing != Trait type
There needs to be enough information in JS to (de)serialize both in JS and Python
Sylvain Corlay
@SylvainCorlay
Feb 11 2015 19:52
@jdfreder, my initial proposal was to do
  • optional box typing as described earlier
    • anything but a dict -> usual JSON serialization / deserialization
    • a dict with no ipy_typekey -> usual JSON serialization / deserialization
    • a dict with ipy_typekey -> checks the value of the key that is the client-side traittype module string (or binds to it)
    • the python serialization / deserialization logic is implemented in to_json and from_json
  • have a js counterpart of the trait type that is in a requirejs module specified in ipy_type
    • this js counterpart has its own serializer to send this to the backend.
  • pretty much nothing in the widget itself.
Jason Grout
@jasongrout
Feb 11 2015 19:54
so: we have a traitlet in python
the traitlet's to_json can return a normal json value, or it can return these special dicts telling js how to deserialize the trait
on the js side, if we discover such a custom type dict, we apply the appropriate deserializer to get the value actually in the backbone model (for example, we construct a js Date object)
going back, we just use standard JSON.stringify on whatever is there. it gets stringified however js does it
the list comes back to python, and python passes that trait's value to from_json to get the value to put in the traitlet
Jonathan Frederic
@jdfreder
Feb 11 2015 19:58
(holding my questions till you are done)
Jason Grout
@jasongrout
Feb 11 2015 19:58
This message was deleted
so basically, the js info is about how to construct an interesting js object from the json/buffer data...
(that's different than what I was thinking, but is simpler and takes care of at least a few of my concerns)
@sylvaincorlay - can you explicitly do an example for List(Date)?
what are the messages in either direction?
Sylvain Corlay
@SylvainCorlay
Feb 11 2015 20:03
List of two Dates and an int. Same message back and forth.
[
    { 
        value : "19820604"
        ipy_type: '/nbextensions/datetime/date'
    },
    { 
        value : "19820605"
        ipy_type: '/nbextensions/datetime/date'
    },
    5,
]
Jason Grout
@jasongrout
Feb 11 2015 20:03
(and what I said won't even work for replacing model references coming back to python, so it still needs some work...)
so that's going python->js, or both ways?
Sylvain Corlay
@SylvainCorlay
Feb 11 2015 20:06
yeah
Jason Grout
@jasongrout
Feb 11 2015 20:06
okay, that's easy to do python->js. And on the js side, easy to convert to a list of Date()s
coming back, we'll have [new Date(), new Date(), 5] to make a message out of
Sylvain Corlay
@SylvainCorlay
Feb 11 2015 20:07
I put an int, to emphasize on dynamic typing
Jonathan Frederic
@jdfreder
Feb 11 2015 20:07
So, if that's the message coming back JS->Python, how does it know '/nbextensions/datetime/date' maps to Date?
Jason Grout
@jasongrout
Feb 11 2015 20:08
how do you see the js knowing how to make this message from just a list [new Date(), new Date(), 5]
Sylvain Corlay
@SylvainCorlay
Feb 11 2015 20:09
like you have a class-level Widget.widget_types on the Python side, you would have TraitType.types on the js side, mapping bare types to specific Types.
Jonathan Frederic
@jdfreder
Feb 11 2015 20:09
mmmm
but the JS side is language agnostic
Sylvain Corlay
@SylvainCorlay
Feb 11 2015 20:10
yes, all this is js side only
right?
Jonathan Frederic
@jdfreder
Feb 11 2015 20:10
What would TraitType.types look like ? It can't be
{
'/nbextensions/datetime/date': 'Date'
}
Sylvain Corlay
@SylvainCorlay
Feb 11 2015 20:11
no, the reverse
{ Date: '/nbextensions/datetime/date'}
Jonathan Frederic
@jdfreder
Feb 11 2015 20:11
Date is Python IPython specific. What if the kernel was VB? Date is called DateTime.
Sylvain Corlay
@SylvainCorlay
Feb 11 2015 20:12
Date is a native js type
Jonathan Frederic
@jdfreder
Feb 11 2015 20:12
oh I see what you're saying
Sylvain Corlay
@SylvainCorlay
Feb 11 2015 20:12
yeas DatTime
Jonathan Frederic
@jdfreder
Feb 11 2015 20:12
well then, how does the back-end know that the JSON is gets is a Date?
{ 
        value : "19820605"
        js_type: 'Date'
    },
?
Sylvain Corlay
@SylvainCorlay
Feb 11 2015 20:13
it gets
    { 
        value : "19820604"
        ipy_type: '/nbextensions/datetime/date'
    },
(my birthday)
Jonathan Frederic
@jdfreder
Feb 11 2015 20:13
:D
Sylvain Corlay
@SylvainCorlay
Feb 11 2015 20:14
we should make it a magic string (my birthday)
Jason Grout
@jasongrout
Feb 11 2015 20:14
young whippersnapper :)
Jonathan Frederic
@jdfreder
Feb 11 2015 20:15
Ah, sorry, the msg from the font-end to the back-end could just be "19820604"
Oh wait...
Not for the case of Union
So the back-end would need a map of
{ '/nbextensions/datetime/date': Date }
(Date is IPython Date there)
Sylvain Corlay
@SylvainCorlay
Feb 11 2015 20:18
yeah
Jonathan Frederic
@jdfreder
Feb 11 2015 20:18
Ok, sounds good. I'm on board so far.
I think the symmetry can still exist when/if we add dynamic traits.
It may complicate things a little bit though.
Jason Grout
@jasongrout
Feb 11 2015 20:19
so we need type registries on js and on python
Sylvain Corlay
@SylvainCorlay
Feb 11 2015 20:19
as long as my birthday becomes a magic string in IPython, causing all the boxes to fall. http://mrdoob.com/projects/chromeexperiments/google-gravity/
Jonathan Frederic
@jdfreder
Feb 11 2015 20:19
Yes
Sylvain Corlay
@SylvainCorlay
Feb 11 2015 20:20
yes but registries are just populated on load of the modules
Jason Grout
@jasongrout
Feb 11 2015 20:20
may I remind everyone that we just went through this discussion for models and views?
Sylvain Corlay
@SylvainCorlay
Feb 11 2015 20:20
on the python, with a decorator, like for the widget
Jonathan Frederic
@jdfreder
Feb 11 2015 20:21
So another question
And it's a bigger one
one sec...
Along the lines of what @jasongrout is getting at, or I think he is, lazy loading turns out to be important in JS (as @takluyver pointed out). Yesterday I worked on a rough draft migration doc for the widget stuff, and I had to describe the motivation behind Promises and the require.js loading scheme. Do those same problems not exist for someone who wants to write custom serialization code with their widget? I haven't thought it through yet, but maybe you have.
For reference, it's in the wiki right now, https://github.com/ipython/ipython/wiki/IPython-3.0-comm-and-widget-migration-document. I'm leaving it there till Friday.
@SylvainCorlay
Sylvain Corlay
@SylvainCorlay
Feb 11 2015 20:26
ok, I will read it
Jason Grout
@jasongrout
Feb 11 2015 20:26
and then it self-destructs?
Jonathan Frederic
@jdfreder
Feb 11 2015 20:26
@SylvainCorlay you don't have to read it, I just posted the link for reference.
Sylvain Corlay
@SylvainCorlay
Feb 11 2015 20:27
I have to walk away to deal with something completely unrelated. will be back in half an hour
ok thanks
Jonathan Frederic
@jdfreder
Feb 11 2015 20:27
ok
Jason Grout
@jasongrout
Feb 11 2015 20:28
okay, so a much simpler proposal - basically static typing for each traitlet type. It sends a traitlet-level deserializer to js in the sync message
Jonathan Frederic
@jdfreder
Feb 11 2015 20:28
Yeah
Sounds like it
Jason Grout
@jasongrout
Feb 11 2015 20:28
the js side, at the top trait-level, simply looks to see if it should apply a custom deserializer. And if so, it does.
Jonathan Frederic
@jdfreder
Feb 11 2015 20:29
Yeah, and Python does the same.
Jason Grout
@jasongrout
Feb 11 2015 20:29
that's it. full stop. it serializes back to python just like normal, and it's python's job to deserialize what it knows is coming intelligently.
Jonathan Frederic
@jdfreder
Feb 11 2015 20:30
The common language they share is the path to the (de)serializer in JS.
Which I think is okay, since widgets aren't really a multifrontend thing right now.
Jason Grout
@jasongrout
Feb 11 2015 20:31
message from python to js: {deserialize: 'path/to/require/date', value: 'somedatevalue'}
message from js to python: "2015-02-11T20:18:29.880Z"
Jonathan Frederic
@jdfreder
Feb 11 2015 20:31
No I think it needs to be the same message back
because of Union
and possible traits like it
Jason Grout
@jasongrout
Feb 11 2015 20:32
all typing exists on the server.
Jonathan Frederic
@jdfreder
Feb 11 2015 20:32
which don't have enough information themselves to determine what the type is
Union(Unicode, Date) would fail with that message
not enough info
Jason Grout
@jasongrout
Feb 11 2015 20:32
yes, so it's dumb to do Union(Unicode, Date). Don't do it.
:)
Jonathan Frederic
@jdfreder
Feb 11 2015 20:32
;)
You know someone may
Jason Grout
@jasongrout
Feb 11 2015 20:33
someone also may write a missile launching system in python. we don't prevent that either...
:)
Jonathan Frederic
@jdfreder
Feb 11 2015 20:33
so I think instead {serializer: 'path/to/require/date', value: 'somedatevalue'} both ways
Jason Grout
@jasongrout
Feb 11 2015 20:33
we have problems tapping into the jsonification of js dates
Jonathan Frederic
@jdfreder
Feb 11 2015 20:34
where path/to/require/date is a JS module that exports serialize and deserialize.
(to get around the JSON.stringify problem)
Jason Grout
@jasongrout
Feb 11 2015 20:34
what json.stringify problem?
Jonathan Frederic
@jdfreder
Feb 11 2015 20:35
The one you mentioned above
You should be able to JSON things that JSON.stringify can't.
Sylvain Corlay
@SylvainCorlay
Feb 11 2015 20:36
We aleady use Union(Float, Date)
a lot
Jason Grout
@jasongrout
Feb 11 2015 20:36
maybe it should be Union(Date, Float)?
Sylvain Corlay
@SylvainCorlay
Feb 11 2015 20:36
and?
Jason Grout
@jasongrout
Feb 11 2015 20:37
no, I guess Union(Float, Date) is fine. When you get a float, fine. If you get a string, it's going to be a date
the union should ask Float to deserialize the date string. When it can't, move on to the Date.
Jonathan Frederic
@jdfreder
Feb 11 2015 20:37
Both front-end and back-end will maintain a map of the JS serializer strings. i.e. VB "path/to/require/date": DateTime .
Ok I think I have enough info to try to prototype something.
Jason Grout
@jasongrout
Feb 11 2015 20:38
I'm saying: nope.
(btw, I've been prototyping already. I pushed my changes from yesterday up to github too)
(to enable custom messages to have buffers, etc.)
Jonathan Frederic
@jdfreder
Feb 11 2015 20:38
Oh cool, then I'll just let you do it :)
Sylvain Corlay
@SylvainCorlay
Feb 11 2015 20:38
so, complete turnaround against box typing?
Jonathan Frederic
@jdfreder
Feb 11 2015 20:39
I haven't started, no point in me repeating what you've done.
@SylvainCorlay yes, for me atleast
I think it will be okay if we only send a single string, the js module path.
Jason Grout
@jasongrout
Feb 11 2015 20:40
yes, it's too complicated. Let's defenestrate it! From the 29th floor!
Jonathan Frederic
@jdfreder
Feb 11 2015 20:40
defenestrate ? Lol
Jason Grout
@jasongrout
Feb 11 2015 20:41
one of my favorite technology words :)
Jonathan Frederic
@jdfreder
Feb 11 2015 20:41
defense + demonstrate
?
Jason Grout
@jasongrout
Feb 11 2015 20:41
(and one of my wife's favorite words when talking about my technological things :)
look it up...
it's a real word.
Jonathan Frederic
@jdfreder
Feb 11 2015 20:42
The second definition is boring "remove or dismiss (someone) from a position of power or authority."
the first is good
"throw (someone) out of a window."
Jason Grout
@jasongrout
Feb 11 2015 20:43
takes on a whole new meaning when you're in a skyscraper...
throwing it down the stairwell is probably just as good, but I don't know the word for that.
probably descala or something
since fenestra is window
and scala is stairs
Jason Grout
@jasongrout
Feb 11 2015 20:48
so: the traitlet takes a new serialization metadata attribute. The first value is a to_json, the second is a from_json. Either can be None (replaced with default json dumps).
@takluyver - so I guess you're saying that the first and second meanings coincide sometimes...
to serialize, you call the python to_json, which returns a value and metadata. The value could be binary or jsonable.
the metadata optionally specifies a js serializer/deserializer.
Jonathan Frederic
@jdfreder
Feb 11 2015 20:51
@jasongrout I don't think there should be any metadata key.
If you're implementing what I thought we settled on above
Jason Grout
@jasongrout
Feb 11 2015 20:51
I'm not settled on anything at the moment.
Jonathan Frederic
@jdfreder
Feb 11 2015 20:51
Ok, then I'm not sure what you're doing
Jason Grout
@jasongrout
Feb 11 2015 20:53
so a message from python->js looks like {state: {trait: value, trait: value, trait:value}, metadata: {trait: metadata, trait: metadata, trait: metadata}, buffers=['trait', 'trait', 'trait']}
Sylvain Corlay
@SylvainCorlay
Feb 11 2015 20:53
fenêtre = window in French
defenestrer -> dewindowing, litterally throwing by the window
ê ~= es
forêt -> forest
hôpital -> hospital
words for which there is an s in the etymology but is not pronounced anymore.
Thomas Kluyver
@takluyver
Feb 11 2015 20:55
hmm, that's cool, I didn't know about that pattern
Sylvain Corlay
@SylvainCorlay
Feb 11 2015 20:55
maître - > maistre -> master
Jonathan Frederic
@jdfreder
Feb 11 2015 21:02
@jasongrout I don't think that would work, with the nested type problem that @SylvainCorlay mentioned. Like Union(List(Float), List(Date))
Jason Grout
@jasongrout
Feb 11 2015 21:03
okay, let's take that.
(bring it on :)
so the python side simply says, hey javascript, when I send you a value, you need to give the value to this function over here to understand it.
Sylvain Corlay
@SylvainCorlay
Feb 11 2015 21:04
I really think that box-typing reflects the nature of the problem, and that the logic should not be implemented at the hastraits level, but only the traittype level,
Jason Grout
@jasongrout
Feb 11 2015 21:04
and whenever you send a value back to me, instead of doing the json thing, just give it to this other function and send the result back to me.
okay, I'm going up to the 29th floor to eat a quick byte and to daydream about defenestrating various complicated schemes :)
be back in a bit.
Jonathan Frederic
@jdfreder
Feb 11 2015 21:06
I say we come up with 3 solutions
and post them
lol
jk
That would be a lot of implementation work
Sylvain Corlay
@SylvainCorlay
Feb 11 2015 21:07
I just got re-fenestrated.
Thrown back inside by the window
Jonathan Frederic
@jdfreder
Feb 11 2015 21:07
lol
Jonathan Frederic
@jdfreder
Feb 11 2015 21:13
@jasongrout @SylvainCorlay the next time I get a chance to sit down and talk with @ellisonbg about this problem, I'll fill him in.
Peter Parente
@parente
Feb 11 2015 21:20
@takluyver re: the mozilla catalog, it only lets me pick repos from my orgs or personal account. so i can't post it. up to you if you want to pursue.
Sylvain Corlay
@SylvainCorlay
Feb 11 2015 22:04
@jdfreder ok thanks
we could have a session on that. Because of our rather nested child widget hierachy, we have a lot of parameterized traits
Thomas Kluyver
@takluyver
Feb 11 2015 22:05
thanks @parente , we may look into it
Jason Grout
@jasongrout
Feb 11 2015 22:10
a big problem with the idea that we should dynamically call javascript tojson methods based on the javascript object type is that it is a rat's nest to introspect a type out of a javascript object
Jonathan Frederic
@jdfreder
Feb 11 2015 22:16
@jasongrout I was under the impression that we wouldn't
Jason Grout
@jasongrout
Feb 11 2015 22:17
I am really confused, then.
Jonathan Frederic
@jdfreder
Feb 11 2015 22:17
the js module specified in the message backend to front would have both serialize and deserialize methods
the method that reads that message
would remember what methods go with what model key names
I guess the problem you're seeing is that traitlets kind of makes Python strongly typed where as in JS we don't have that, so it's only weakly typed, right?
So in theory, the JS could set a value that wasn't the same type as the type sent by the backend.
So in this case:
a = Union(Float, Date)
if a is set to a date value in Python
the types/date module would be specified in the state message
Jonathan Frederic
@jdfreder
Feb 11 2015 22:22
then in the front-end
when the JS code tries to set a to 0.123
it would try to use the types/date.serialize
and fail
Is that what you're talking about?
Jason Grout
@jasongrout
Feb 11 2015 22:24
well, I was more talking about: if a is MyType, it's not clear how to see what the type of a is.
Jonathan Frederic
@jdfreder
Feb 11 2015 22:26
hmm
Maybe we need traits in Javascript
Jason Grout
@jasongrout
Feb 11 2015 22:30
no. that definitely goes out the window :)
Jonathan Frederic
@jdfreder
Feb 11 2015 22:31
:satisfied:
Sylvain Corlay
@SylvainCorlay
Feb 11 2015 22:40
actually, traitlets are not as strongly typed as it seems because of the Union
Jonathan Frederic
@jdfreder
Feb 11 2015 22:42
True
Jason Grout
@jasongrout
Feb 11 2015 22:44
I don't think Union precludes strong typing. I also think "strong typing" means a lot of different things to a lot of different people
I'd say Julia is strongly typed, for example, and it has Unions