Simplify deferred creation of default values

[SylvainCorlay]

This is an attempt to simplify initialization of default values.

The behavior is slightly different in that now:

class Foo(HasTraits):
    bar = Int()

# triggers a trait notification
foo = Foo()
foo.bar = 0

# does not triggers a trait notification
foo = Foo(bar=0)
foo.bar = 0

# accessing the uninitialized trait initiates the default value
foo = Foo()
print(foo.bar)  # prints 0

Previously, the first example would not trigger a trait notification since 0 is equal to the default value which was initialized. I realize this is quite a change, but it really simplifies the code.

[SylvainCorlay]

@takluyver let me know what you think. This is completely deferring the initialization of default values to the first __get__ call. I like that it removes a lot of code.

[SylvainCorlay]

This actually does what @minrk was suggesting there ipython/ipython#8107 (comment) .

This should make a lot of the allow_none=True introduced in ipython/ipython#8107 and ipython/ipython#7708 unnecessary.

[minrk]

It seems like these removed tests should still be failing, rather than removed.

[minrk]

If it requires adding a request for the trait, that's okay, too, but the tests shouldn't be removed altogether.

[SylvainCorlay]

Rebased upon #28

[takluyver]

I think we can avoid the behaviour change if, in __set__, we change this:

try:
    old_value = obj._trait_values[self.name]
except KeyError:
    old_value = Undefined

to this:

try:
    old_value = obj._trait_values[self.name]
except KeyError:
    old_value = self.default_value

self.default_value is Undefined in cases where there's no obvious default, but it is e.g. 0 for an integer if no default was supplied.

[SylvainCorlay]

@takluyver I tried your suggestion but it still fails the test for bad defaults.

[takluyver]

I'd like to avoid adding yet another method, especially in a PR called 'Simplify...'

[SylvainCorlay]

This is part of #28, can we debate this there?

[takluyver]

It seemed like these two PRs were part of the same thing, but I guess that's not how you see it? Should I ignore this one until we have reached a decision on #28?

[SylvainCorlay]

I guess so.

[takluyver]

It looks like you've got rid of all the changes to tests - does that mean that it no longer changes behaviour?

[SylvainCorlay]

No, a commit is missing. Just need a minute.

[SylvainCorlay]

Closing this one for now, since it changes the behavior and we are close to 4.0.