These are chat archives for ipython/ipython

1st
Feb 2016
Sylvain Corlay
@SylvainCorlay
Feb 01 2016 15:27

@minrk after a discussion in another repo it seems that it is not necessary to do

version_ns = {}
with open(pjoin(here, name, '_version.py')) as f:
    exec(f.read(), {}, version_ns)

to fetch the version number, but we can instead do

from traitlets import __version__
since we must run setup.py install from the setup.py directory anyway and it also works with pip.
Is there another reason why we manually get the file?
Min RK
@minrk
Feb 01 2016 15:34
Yes, traitlets isn't generally importable when setup.py is executed (dependencies have not been installed).
Sylvain Corlay
@SylvainCorlay
Feb 01 2016 15:50
@minrk thanks
Scott Sanderson
@ssanderson
Feb 01 2016 17:58
@minrk @SylvainCorlay is it intentional that traits' instance_initmethods are called on an object before that object's __init__ fires?
Sylvain Corlay
@SylvainCorlay
Feb 01 2016 18:21
I think so
actually, now there are two stages:
  • class_init, which runs at the instantiation of the metaclass, ie definition of the class
  • instance_init, which runs at the instantiation of the class, ie definition of the instance
before, everything was in instance_init (including what is now in class_init and was duplicated for every time we instantiated some HasTraits). So it was critical that it is called before __init__.
it might not be the case anymore.
Scott Sanderson
@ssanderson
Feb 01 2016 18:23
gotcha
it seems like we'd want to call instance_init on fully-initialized objects though, right?
Sylvain Corlay
@SylvainCorlay
Feb 01 2016 18:24
dunno
Scott Sanderson
@ssanderson
Feb 01 2016 18:24
in particular, I think we're ad-hoc initializing _cross_validation_lock in 2-3 different places
Sylvain Corlay
@SylvainCorlay
Feb 01 2016 18:24
I need to get back into the code.
Scott Sanderson
@ssanderson
Feb 01 2016 18:24
because it's set in __init__, but various instance_init calls depend on it
Sylvain Corlay
@SylvainCorlay
Feb 01 2016 18:24
I agree for _cross_validation_lock.
Scott Sanderson
@ssanderson
Feb 01 2016 18:24
so they end up setting it prematurely
I opened ipython/traitlets#166 to clean up some of that
Sylvain Corlay
@SylvainCorlay
Feb 01 2016 18:25
ok, thanks. I agree that this can be improved.
Scott Sanderson
@ssanderson
Feb 01 2016 18:25
the challenge, I think is that we want instance_inits to fire in TraitType.__new__ so that you can't get a reference to a malformed object
but Python calls an object's __init__ by default when it's returned from __new__
so if we call __init__ ourselves, it will get called twice
Sylvain Corlay
@SylvainCorlay
Feb 01 2016 18:26
A lot of what was in instance_initwas moved to class_init so it might be possible to defer it a bit.
However, for people who defined custom trait types, it might be a breaking change to do so.
I need to run sorry. I can look at the PR tomorrow.
Scott Sanderson
@ssanderson
Feb 01 2016 18:27
I think we're calling instance_init in the right place conceptually, I think that design is just incompatible with initalizing HasTraits state in a __init__
np
thanks for confirming
Michael Bradley
@michaelsbradleyjr
Feb 01 2016 23:46
I’m having some trouble with metakernel/metakernel_bash, the kernel can’t manage to connect properly, having trouble figuring out the problem; I’m new to jupyter and not super experienced with conda,pip,etc.