Scalar properties such as ints, floats (and potentially complex values, either the real and imaginary parts or amplitude) should be able to have upper and lower bounds

Undefined values should never make it out of validation. If something is not required and not set, it should be None. Ensure this is the case.

@varyag00 please remove pyexec code from the repo and rely on pip instead.

This repo was made by @lheagy and is available here:
https://github.com/3ptscience/sphinxcontrib-pyexec
https://pypi.python.org/pypi/sphinxcontrib-pyexec

@bsmithyman what is the best way to have development and production requirements.txt??

Right now, this wrapper is used to add_defaults to superclass _defaults - that should probably be more explicit. - These methods should happen on startup and not use self.

There should also be functions to dynamically calculate defaults of properties (something like @properties.default('prop_name').

without adding numpy dep.

try:
    float_val = float(value)
except TypeError:
    self.error(...)
if abs(val - float_val) > TOL:
    self.error(...)
...

Clean up the array validation, rely more on numpy, less for loops!

tobytes was introduced in 1.9

Properties currently have both info() and info_text, where info_text is a class attribute and info() is a dynamic string based on the instance. However there is some muddle about how these are used (ie StringChoice overrides info_text as an @property; some info() methods use info_text, others do not).

Currently, this is only used in the sphinx docs and error messages on property instances, so they could possibly be combined into one method (or @property). At the very least, it should be cleaned up so info_text is a class attribute and info() is an instance method (and perhaps these could have more descriptive names).

Should be able to alphabetize them programatically.

Is it possible to extend the functionality of properties to support function variables?

Something like this

arg1 = properties.Float('Argument description', default=1.0, min=0.).as_argument()

def my_function(arg1):
    """
    Function description
    """
    # Argument description would be combined and
    # arg1 could be validated as with properties
    arg1.validite() 
    result = do_work_with_arg1
    return result

This would be really useful when you have the same variable/argument as an input in multiple functions in a library.

We do not currently have the ability to store descriptions on the StringChoice property.

"choices": [
    "C",
    "N",
    "F"
],
"descriptions": [
    "Cell centred data",
    "Nodal data",
    "Face data"
]

Right now Arrays are restricted to floats and ints. Could this be extended to include bools as well? eg

import numpy as np
np.array(np.ones(4), dtype=bool)

or perhaps a separate BoolArray class?

• Take open file or filename
• mode
• validates to open file

I am working on implementing properties in the Regularization class of SimPEG. We have defined a custom class Utils.Zero that acts like a zero by overwriting the ufuncs (https://github.com/simpeg/simpeg/blob/master/SimPEG/Utils/matutils.py#L469). Since it is not inheriting from numpy and doesn't have a dtype, it is not recognized as an allowable type on validation.

from SimPEG import Utils

class Regularization(properties.HasProperties): 
    mref = properties.Array("reference model", default=Utils.Zero())

Do you have a recommendation for how to have Utils.Zero() interpoerate with the properties.Array?

Can we add something like regexp to the strings? Similar to how we can bound floats with min/max.

email = properties.String("The users email", regexp=r".+\@.+\..+", strip=" ")

We are requiring that the user pass a list or tuple here (or a dict). However, we are using it like a set. At the least, we should accept a set. In some ways, I would prefer that we handle this in a way that does not require direct inheritance from set, list, tuple or dict, but rather uses ABCs.

Right now, different Property classes are well documented, but the only thing the docs say about HasProperties is that properties must be defined inside them (just a footnote).

When overriding __init__ in HasProperties classes, super must be called first. This is a bit unintuitive and perhaps can be fixed by doing some setup in __new__ instead?

String properties should work with unicode in Python 2 and 3.

ie define __get__ and __set__ in _set_property_meta, rather than using property/fget/fset.

Not pressing, since tasks are relatively simple and not widely used, but this would be good to add sometime.

Could we please remove the import * parts of properties and replace with the the suggestions from PEP328.

http://legacy.python.org/dev/peps/pep-0328/

PEP0328

(import * is not an option ;-)

Instead, it should be possible to use Python's standard grouping mechanism (parentheses) to write the import statement:

from Tkinter import (Tk, Frame, Button, Entry, Canvas, Text,
    LEFT, DISABLED, NORMAL, RIDGE, END)

https://www.quantifiedcode.com/app/issue_class/1ynDCGAE

I've noticed this because we accidentally tried to build a Colour Legend from a list of float tuples. The float tuples did not pass the Colour validation (good) but they passed the Float validation (bad).
So, passing a tuple of floats into a Float passes the validation, but it should not.
The validator checks if the value is of type (float, integer_types) but it does not raise an exception if this fails. The following in_bounds check is skipped if the Float has no min/max values set.

This would be useful for defining one property with a value totally dependent on other properties. The behaviour would be very similar to defining and @property, but as a Property it would have additional documentation, declarative definition, possibly additional validation.

For example, instead of something like this:

class BuriedSource(properties.HasProperties):
    depth = properties.Float(
        doc='Depth of source'
    )
    @property
    def loc_vector(self):
        return vectormath.Vector3([0., 0., -self.depth])

you could do:

class BuriedSource(properties.HasProperties):
    depth = properties.Float(
        doc='Depth of source'
    )
    loc_vector = properties.Vector3(
        doc='Vector location of source',
        dynamic_value=lambda self: [0., 0., -self.depth]
    )

loc_vector would then be auto-documented and coerced to a Vector3 automatically.

By default, a property with dynamic_value defined would be otherwise immutable - the value is only calculated on get and never set. Possibly there could be another attribute like overwritable where the dynamic value can be permanently overwritten (at least until it is deleted).

It is less likely a property is optional than required, I think. Especially now that required properties can have defaults - being required doesn't necessarily mean the user of the HasProperties class has to worry about setting it.

As long as float or int is contained in dtype, no error is raised:

This needs to be stricter.

• In docs

Allow setting metadata values of properties that are not predefined attributes.

Something along the lines of how Traitlets does it:

num = Integer(5, help="a number").tag(config=True)

This will prevent resources from getting _dirty if they are set to the same thing, and prevent _on_prop_change from firing.

This requires implementing equal in properties.

Currently the functionality rejects setting default required properties. This should be rethought.

Property validation is sometimes used without HasProperties class (for example in PropertyMetaclass or possibly as a standalone Property instance). In this case, self.name is '' and the instance is NoneType. Validation still works, but if there is an error, it looks like this:

Instead a shorter error message should be displayed - ie the second half of that message only.

validator functions are able to coerce values, but the new values are not currently saved.

Properties are validated on set; List modifications by index do not trigger this validation (nor change notifications). This is somewhat mitigated by calling validate() on the HasProperties class, however that only checks if the elements are valid - it does not coerce them. (For example a List of Colors may have an entry 'red'. That will pass validation but will not be coerced to the expected RGB value.) The only way to ensure list validation and coercion occurs is setting the entire list (even if it's just to itself): my_object.my_list = my_object.my_list

The best way to fix this is probably using a custom List that is able to listen for changes to it's elements. There may be less drastic intermediate steps to mitigate this.

The validation only matches the types defined in TYPE_MAPPINGS against the allowed types in Array.dtype

When passing in a numpy array with dtype=='O', the validation passes (but the serialization fails).

The validation should fail.

Undefined auto_create=True pointers to other PropertyClasses with auto_create=True pointers have infinite recursion problems on validate.

All the nice markup features that make the sphinx docs look good cause the plain text docstrings (those accessed by ? in the notebook) to look messy. As we start linking docs with intersphinx, things get more and more complicated.

Should we somehow separate these into two different docstrings, sphinx and plain text?

The auto-generated docs are starting to look a bit messy using Sphinx built in property/attribute tags. It is strange that "Required" and "Parameters" are on different lines, then the immutable "attributes" are formatted differently (see screenshot below). I think we need some more customized formatting that doesn't use the builtin property/attribute tags.

Ability to have a write once property.

@fwkoch, @varyag00, @rowanc1: What are your thoughts on the viability of removing the numpy dependency from properties and putting it in something like properties_array? The numpy dependency is a major deployment hurdle for lightweight web environments.

Thanks!

For example, setting color property default to 'random' should validate it, but still give 'random' if you get the default.

Need to ensure default is validated whenever it needs to be then.

This will allow the required numpy version to be older

Could we add this to the readme?

https://www.quantifiedcode.com/app/project/f79abeb2219a4a2d9b683f8d57bcdab5/settings?tab=badges

this should immediately error: properties.Int('My int', default='one hundred')