- 
                Notifications
    You must be signed in to change notification settings 
- Fork 88
Add a TypedReadOnly trait #488
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: main
Are you sure you want to change the base?
Conversation
| sorry @corranwebster and @mdickinson I thought that I had the PR ready but it looks I am still missing something | 
| @mdickinson and @corranwebster this pr is ready for review. | 
| Codecov Report
 @@            Coverage Diff             @@
##           master     #488      +/-   ##
==========================================
+ Coverage   65.15%   65.48%   +0.33%     
==========================================
  Files          44       44              
  Lines        7040     7061      +21     
  Branches     1413     1416       +3     
==========================================
+ Hits         4587     4624      +37     
+ Misses       2030     2014      -16     
  Partials      423      423
 Continue to review full report at Codecov. 
 | 
| @itziakos Thank you! I'll look at this within the next couple of days. | 
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@itziakos Thank you! I'll look at this within the next couple of days.
For a fairly geological interpretation of the word "days", obviously ... Sorry.
A couple of comments, below.
This trait doesn't behave quite the way I expect: I'd expect to get the Undefined object if I access before setting, but instead I get the default value. Perhaps there's no reasonable way to get the expected behaviour here.
>>> class A(HasTraits):
...     foo = TypedReadOnly(Int)
...     bar = ReadOnly()
... 
>>> a = A()
>>> a.foo  # expect undefined, or an error
0
>>> a.foo = 3
>>> a.foo
3
>>> a.foo = 5
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/Users/mdickinson/Enthought/ETS/traits/traits/trait_types.py", line 1314, in set
    raise TraitError(message.format(name, object.__class__.__name__))
traits.trait_errors.TraitError: Cannot set 'foo' of 'A' more than once.
>>> a.bar 
<undefined>
>>> a.bar = 3
>>> a.bar
3
>>> a.bar = 5
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
traits.trait_errors.TraitError: Cannot modify the read only 'bar' attribute of a 'A' object.
| # | ||
| # Thanks for using Enthought open source! | ||
| # | ||
| # Author: Ioannis Tziakos | 
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Let's lose the "Author" and "Date" fields; we can track that information through version control.
|  | ||
| def __init__(self, trait=Any, **metadata): | ||
| if isinstance(trait, type): | ||
| self.inner_traits = (trait(),) | 
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should inner_traits be a method (taking no additional arguments) rather than an attribute? I don't get the behaviour I expect on accessing inner_traits on the corresponding CTrait object:
>>> class A(HasTraits):
...     foo = TypedReadOnly(Int)
...     bar = List(Int)
... 
>>> a = A()
>>> a.traits()["foo"].inner_traits  # gives None
>>> a.traits()["bar"].inner_traits
(<traits.traits.CTrait object at 0x10f4d72c0>,)
| I'm OK with the behaviour of returning a default before a value is set - I think that might be a more pragmatically useful behaviour - but perhaps the name of the trait is wrong: should it be  | 
94cd6bb    to
    d5875c5      
    Compare
  
    
This PR adds a Typed version of the ReadOnly trait.