-
-
Notifications
You must be signed in to change notification settings - Fork 208
added a key_trait argument to Dict #306
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
Merged
Merged
Changes from 4 commits
Commits
Show all changes
6 commits
Select commit
Hold shift + click to select a range
90ff8dc
added a key_trait argument to Dict
burnpanck b0b3c7d
fixed ignoring of Dict.key_trait when no other sub-traits are set
burnpanck 8b75d38
Merge branch 'master' into add-Dict-key-validation
burnpanck d9f1e6d
cleanup Dict.validate_elements
burnpanck 92e3323
restored backwards compatiblity for argument order in Dict, and depre…
burnpanck 3dca190
added missing calls to `class_init` and `instance_init` for `key_trait`
burnpanck File filter
Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
There are no files selected for viewing
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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.
To avoid backward-incompatibility with positional args, can you add key_trait to the end?
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.
To be honest, I think this schema feature accessible via the
traitsargument doesn't belong intoDictat all. I'd rather not have it block access tokey_trait. What about a compromise: Keepkey_traitbeforetraitsand when an instance ofdict(the python class, not the trait) is encountered inkey_trait, raise a warning and map it totraits?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.
My preference would be for all of these after the first to be keyword-only arguments, but Python 2 doesn't make that very easy other than
**kwargs. I would add it to the end and treat it as if it were keyword-only.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.
To me the keys of a dict are at least as important as the values if not more. I have the feeling everyone here seems to implicitly assume unicode keys for their dicts, but that is not validated in the current implementation. I'd put the key trait even before the value trait if not for backwards compatibility.
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.
I'm concerned more with clarity than priority. I don't view the order as being significant (to me, there is only one positional arg for any TraitType, but Python 2 doesn't make this easy). If you'd like to make
value_traitandkey_trait, that would be fine by me, as long as it's done in a backward-compatible way (i.e. positional args retain their order). I wouldn't expect anyone to pass key_trait positionally ever, and I'm AOK encouraging people to pass value_trait by keyword-arg, as well, since that would be clearest.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.
I don't see how there is a general one positional arg that would have a well defined meaning for all TraitType's, so the positional args could equally well be trait specific. But then, I guess backwards compatibility shouldn't be broken lightly, so it's anyway too late. I'll shut up now and will just fix backwards compatibility.