
Hi everyone, We have released a small experimental package called numtraits that builds on top of the traitlets package and provides a NumericalTrait class that can be used to validate properties such as: * number of dimension (for arrays) * shape (for arrays) * domain (e.g. positive, negative, range of values) * units (with support for astropy.units, pint, and quantities) The idea is to be able to write a class like: class Sphere(HasTraits): radius = NumericalTrait(domain='strictly-positive', ndim=0) position = NumericalTrait(shape=(3,)) and all the validation will then be done automatically when the user sets 'radius' or 'position'. In addition, tuples and lists can get automatically converted to arrays, and default values can be specified. You can read more about the package and see examples of it in use here: https://github.com/astrofrog/numtraits and it can be easily installed with pip install numtraits The package supports both Python 3.3+ and Legacy Python (2.7) :) At this point, we would be very interested in feedback - the package is still very young and we can still change the API if needed. Please open issues with suggestions! Cheers, Tom and Francesco

Hi Thomas On 2015-09-23 09:39:00, Thomas Robitaille <thomas.robitaille@gmail.com> wrote:
This looks great! At the moment, a pip install tries to install a different version of NumPy, even though I already have the development version on my tree. In scikit-image, we use something like the following in setup.py to prevent that from happening: # Do not try and upgrade larger dependencies INSTALL_REQUIRES = ['numpy', 'traitlets'] try: __import__('numpy') INSTALL_REQUIRES = ['traitlets'] except ImportError: pass Stéfan

On Wed, Sep 23, 2015 at 5:10 PM, Stefan van der Walt <stefanv@berkeley.edu> wrote:
FYI the alternative solution is to fix your local numpy install to give pip an accurate picture of what you have installed. The key thing is to make sure you have a .egg-info / .dist-info for your numpy -- that's what pip looks for to figure out what's installed. (python setupegg.py egg_info will generate one IIRC). -n -- Nathaniel J. Smith -- http://vorpus.org

Hi Thomas, This is great news! FYI, the traitlets module has been undergoing significant refactoring lately, improving the API to favor a broader usage in the community. One reason for this is that several projects outside of the Jupyter organization are considering adopting traitlets. You can find a summary of the ongoing work and API changes here: https://github.com/ipython/traitlets/issues/48 One of the items in this discussion is about what would be the best place for a repository of trait types for standard data structures of the scipy stack (numpy array, pandas series and dataframes, etc...) It is unlikely that such trait types would be accepted in those libraries at this moment, and the main traitlets package might not be the right place for it either - hence the need for another repo. However, if we don't work on a centralized project, we will probably see a number of competing implementations in different libraries that are clients of traitlets. Hence the idea would be to propose a new project in the Jupyter incubator with a reference implementation. What would be cool would be to join forces and work on a specification or start a discussion of what the ideal implementation for such trait types would look like. Cheers, Sylvain On Wed, Sep 23, 2015 at 12:39 PM, Thomas Robitaille < thomas.robitaille@gmail.com> wrote:

Hi Sylvain, Sylvain Corlay wrote:
I'm very open to collaborating on centralizing these kind of scipy-stack traits. I'm not particularly attached to the idea of keeping our numtraits implementation separate, and would be very happy to merge it in to a larger effort or only re-use parts of it. Realistically I won't be able to lead/write a proposal for the incubator in the next few weeks, but if no one gets to it first, I can try and work on it later in the year. Cheers, Tom

Hi Thomas On 2015-09-23 09:39:00, Thomas Robitaille <thomas.robitaille@gmail.com> wrote:
This looks great! At the moment, a pip install tries to install a different version of NumPy, even though I already have the development version on my tree. In scikit-image, we use something like the following in setup.py to prevent that from happening: # Do not try and upgrade larger dependencies INSTALL_REQUIRES = ['numpy', 'traitlets'] try: __import__('numpy') INSTALL_REQUIRES = ['traitlets'] except ImportError: pass Stéfan

On Wed, Sep 23, 2015 at 5:10 PM, Stefan van der Walt <stefanv@berkeley.edu> wrote:
FYI the alternative solution is to fix your local numpy install to give pip an accurate picture of what you have installed. The key thing is to make sure you have a .egg-info / .dist-info for your numpy -- that's what pip looks for to figure out what's installed. (python setupegg.py egg_info will generate one IIRC). -n -- Nathaniel J. Smith -- http://vorpus.org

Hi Thomas, This is great news! FYI, the traitlets module has been undergoing significant refactoring lately, improving the API to favor a broader usage in the community. One reason for this is that several projects outside of the Jupyter organization are considering adopting traitlets. You can find a summary of the ongoing work and API changes here: https://github.com/ipython/traitlets/issues/48 One of the items in this discussion is about what would be the best place for a repository of trait types for standard data structures of the scipy stack (numpy array, pandas series and dataframes, etc...) It is unlikely that such trait types would be accepted in those libraries at this moment, and the main traitlets package might not be the right place for it either - hence the need for another repo. However, if we don't work on a centralized project, we will probably see a number of competing implementations in different libraries that are clients of traitlets. Hence the idea would be to propose a new project in the Jupyter incubator with a reference implementation. What would be cool would be to join forces and work on a specification or start a discussion of what the ideal implementation for such trait types would look like. Cheers, Sylvain On Wed, Sep 23, 2015 at 12:39 PM, Thomas Robitaille < thomas.robitaille@gmail.com> wrote:

Hi Sylvain, Sylvain Corlay wrote:
I'm very open to collaborating on centralizing these kind of scipy-stack traits. I'm not particularly attached to the idea of keeping our numtraits implementation separate, and would be very happy to merge it in to a larger effort or only re-use parts of it. Realistically I won't be able to lead/write a proposal for the incubator in the next few weeks, but if no one gets to it first, I can try and work on it later in the year. Cheers, Tom
participants (4)
-
Nathaniel Smith
-
Stefan van der Walt
-
Sylvain Corlay
-
Thomas Robitaille