Method for adding error messages to a dictionary given a key The Next CEO of Stack Overflow“Multi-key” dictionaryOutputting all possible words which fit a string of lettersCheck value from two different dictionary with matched keyDictionary of key signatures for various major and minor scalesResolving MySQL 1215 errors in a declarative MySQL migration systemSmall Chatbot challengeSimple Python script seems to stop when N >> 1Make a given number by adding given numbersAdding values from DictReader to empty dictionaryDefine the scope of negation with the Dependency Parser of spaCy
Is there a way to save my career from absolute disaster?
How many extra stops do monopods offer for tele photographs?
Why did CATV standarize in 75 ohms and everyone else in 50?
What did we know about the Kessel run before the prequels?
What flight has the highest ratio of time difference to flight time?
Does soap repel water?
How to get from Geneva Airport to Metabief?
Running a General Election and the European Elections together
Is it ever safe to open a suspicious HTML file (e.g. email attachment)?
How a 64-bit process virtual address space is divided in Linux?
Flying from Cape Town to England and return to another province
Newlines in BSD sed vs gsed
Some questions about different axiomatic systems for neighbourhoods
INSERT to a table from a database to other (same SQL Server) using Dynamic SQL
Is it okay to majorly distort historical facts while writing a fiction story?
Won the lottery - how do I keep the money?
How do I align (1) and (2)?
is it ok to reduce charging current for li ion 18650 battery?
How to invert MapIndexed on a ragged structure? How to construct a tree from rules?
Does increasing your ability score affect your main stat?
I want to delete every two lines after 3rd lines in file contain very large number of lines :
Bartok - Syncopation (1): Meaning of notes in between Grand Staff
What happened in Rome, when the western empire "fell"?
Plot of histogram similar to output from @risk
Method for adding error messages to a dictionary given a key
The Next CEO of Stack Overflow“Multi-key” dictionaryOutputting all possible words which fit a string of lettersCheck value from two different dictionary with matched keyDictionary of key signatures for various major and minor scalesResolving MySQL 1215 errors in a declarative MySQL migration systemSmall Chatbot challengeSimple Python script seems to stop when N >> 1Make a given number by adding given numbersAdding values from DictReader to empty dictionaryDefine the scope of negation with the Dependency Parser of spaCy
$begingroup$
I want this method to be completely understandable just from looking at the code and comments only.
def add_error(error_dict, key, err):
"""Given an error message, or a list of error messages, this method
adds it/them to a dictionary of errors.
Doctests:
>>> add_error(, 'key1', 'error1')
'key1': ['error1']
>>> add_error('key1': ['error1'], 'key1', 'error2')
'key1': ['error1', 'error2']
>>> add_error('key1': ['error1', 'error2'], 'key2', 'error1')
'key1': ['error1', 'error2'], 'key2': ['error1']
>>> add_error(, 'key1', ['error1', 'error2'])
'key1': ['error1', 'error2']
>>> add_error(, 'key1', [])
>>> add_error('key1': ['error1'], 'key2', ['error1', 'error2'])
'key1': ['error1'], 'key2': ['error1', 'error2']
>>> add_error(, 'key1', 23) # doctest: +IGNORE_EXCEPTION_DETAIL
Traceback (most recent call last):
...
TypeError: The error(s) must be a string, or a list of strings.
>>> add_error(, 'key1', [23]) # doctest: +IGNORE_EXCEPTION_DETAIL
Traceback (most recent call last):
...
TypeError: The error(s) must be a string, or a list of strings.
>>> add_error(, 'key1', ['error1', 23]) # doctest:
+IGNORE_EXCEPTION_DETAIL
Traceback (most recent call last):
...
TypeError: The error(s) must be a string, or a list of strings.
"""
if not isinstance(err, list):
err = [err]
if not key in error_dict and len(err) > 0:
error_dict[key] = []
for e in err:
if not isinstance(e, string_types):
raise TypeError(
'The error(s) must be a string, or a list of strings.'
)
error_dict[key].append(e)
return error_dict
Hopefully, the code along with the comment does the job well, but I would still appreciate review(s) of this method. One thing I always keep on wondering is whether this is too many doc-tests for such a simple method. Thanks.
python python-3.x
New contributor
darkhorse is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
$endgroup$
add a comment |
$begingroup$
I want this method to be completely understandable just from looking at the code and comments only.
def add_error(error_dict, key, err):
"""Given an error message, or a list of error messages, this method
adds it/them to a dictionary of errors.
Doctests:
>>> add_error(, 'key1', 'error1')
'key1': ['error1']
>>> add_error('key1': ['error1'], 'key1', 'error2')
'key1': ['error1', 'error2']
>>> add_error('key1': ['error1', 'error2'], 'key2', 'error1')
'key1': ['error1', 'error2'], 'key2': ['error1']
>>> add_error(, 'key1', ['error1', 'error2'])
'key1': ['error1', 'error2']
>>> add_error(, 'key1', [])
>>> add_error('key1': ['error1'], 'key2', ['error1', 'error2'])
'key1': ['error1'], 'key2': ['error1', 'error2']
>>> add_error(, 'key1', 23) # doctest: +IGNORE_EXCEPTION_DETAIL
Traceback (most recent call last):
...
TypeError: The error(s) must be a string, or a list of strings.
>>> add_error(, 'key1', [23]) # doctest: +IGNORE_EXCEPTION_DETAIL
Traceback (most recent call last):
...
TypeError: The error(s) must be a string, or a list of strings.
>>> add_error(, 'key1', ['error1', 23]) # doctest:
+IGNORE_EXCEPTION_DETAIL
Traceback (most recent call last):
...
TypeError: The error(s) must be a string, or a list of strings.
"""
if not isinstance(err, list):
err = [err]
if not key in error_dict and len(err) > 0:
error_dict[key] = []
for e in err:
if not isinstance(e, string_types):
raise TypeError(
'The error(s) must be a string, or a list of strings.'
)
error_dict[key].append(e)
return error_dict
Hopefully, the code along with the comment does the job well, but I would still appreciate review(s) of this method. One thing I always keep on wondering is whether this is too many doc-tests for such a simple method. Thanks.
python python-3.x
New contributor
darkhorse is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
$endgroup$
add a comment |
$begingroup$
I want this method to be completely understandable just from looking at the code and comments only.
def add_error(error_dict, key, err):
"""Given an error message, or a list of error messages, this method
adds it/them to a dictionary of errors.
Doctests:
>>> add_error(, 'key1', 'error1')
'key1': ['error1']
>>> add_error('key1': ['error1'], 'key1', 'error2')
'key1': ['error1', 'error2']
>>> add_error('key1': ['error1', 'error2'], 'key2', 'error1')
'key1': ['error1', 'error2'], 'key2': ['error1']
>>> add_error(, 'key1', ['error1', 'error2'])
'key1': ['error1', 'error2']
>>> add_error(, 'key1', [])
>>> add_error('key1': ['error1'], 'key2', ['error1', 'error2'])
'key1': ['error1'], 'key2': ['error1', 'error2']
>>> add_error(, 'key1', 23) # doctest: +IGNORE_EXCEPTION_DETAIL
Traceback (most recent call last):
...
TypeError: The error(s) must be a string, or a list of strings.
>>> add_error(, 'key1', [23]) # doctest: +IGNORE_EXCEPTION_DETAIL
Traceback (most recent call last):
...
TypeError: The error(s) must be a string, or a list of strings.
>>> add_error(, 'key1', ['error1', 23]) # doctest:
+IGNORE_EXCEPTION_DETAIL
Traceback (most recent call last):
...
TypeError: The error(s) must be a string, or a list of strings.
"""
if not isinstance(err, list):
err = [err]
if not key in error_dict and len(err) > 0:
error_dict[key] = []
for e in err:
if not isinstance(e, string_types):
raise TypeError(
'The error(s) must be a string, or a list of strings.'
)
error_dict[key].append(e)
return error_dict
Hopefully, the code along with the comment does the job well, but I would still appreciate review(s) of this method. One thing I always keep on wondering is whether this is too many doc-tests for such a simple method. Thanks.
python python-3.x
New contributor
darkhorse is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
$endgroup$
I want this method to be completely understandable just from looking at the code and comments only.
def add_error(error_dict, key, err):
"""Given an error message, or a list of error messages, this method
adds it/them to a dictionary of errors.
Doctests:
>>> add_error(, 'key1', 'error1')
'key1': ['error1']
>>> add_error('key1': ['error1'], 'key1', 'error2')
'key1': ['error1', 'error2']
>>> add_error('key1': ['error1', 'error2'], 'key2', 'error1')
'key1': ['error1', 'error2'], 'key2': ['error1']
>>> add_error(, 'key1', ['error1', 'error2'])
'key1': ['error1', 'error2']
>>> add_error(, 'key1', [])
>>> add_error('key1': ['error1'], 'key2', ['error1', 'error2'])
'key1': ['error1'], 'key2': ['error1', 'error2']
>>> add_error(, 'key1', 23) # doctest: +IGNORE_EXCEPTION_DETAIL
Traceback (most recent call last):
...
TypeError: The error(s) must be a string, or a list of strings.
>>> add_error(, 'key1', [23]) # doctest: +IGNORE_EXCEPTION_DETAIL
Traceback (most recent call last):
...
TypeError: The error(s) must be a string, or a list of strings.
>>> add_error(, 'key1', ['error1', 23]) # doctest:
+IGNORE_EXCEPTION_DETAIL
Traceback (most recent call last):
...
TypeError: The error(s) must be a string, or a list of strings.
"""
if not isinstance(err, list):
err = [err]
if not key in error_dict and len(err) > 0:
error_dict[key] = []
for e in err:
if not isinstance(e, string_types):
raise TypeError(
'The error(s) must be a string, or a list of strings.'
)
error_dict[key].append(e)
return error_dict
Hopefully, the code along with the comment does the job well, but I would still appreciate review(s) of this method. One thing I always keep on wondering is whether this is too many doc-tests for such a simple method. Thanks.
python python-3.x
python python-3.x
New contributor
darkhorse is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
New contributor
darkhorse is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
New contributor
darkhorse is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
asked 4 hours ago
darkhorsedarkhorse
1584
1584
New contributor
darkhorse is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
New contributor
darkhorse is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
darkhorse is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
add a comment |
add a comment |
2 Answers
2
active
oldest
votes
$begingroup$
Consider narrowing accepted types
This might not be possible based on the context of your code, but if it is: arguments sharing one of many different types hinders and complicates testability and maintainability. There are many different solutions to this that will help this situation; one is accepting variadic arguments - i.e.
def add_error(error_dict, key, *errs):
This is still easily invocable without needing to wrap a single error in a list.
Use x not in instead of not x in
i.e.
if key not in error_dict
Lose your loop
and also lose your empty-list assignment, instead doing
error_dict.setdefault(key, []).extend(err)
If you use the variadic suggestion above, your entire function becomes that one line.
Immutable or not?
Currently you do two things - alter a dictionary and return it - when you should only pick one. Either make a copy of the dict and return an altered version, or modify the dict and don't return anything.
$endgroup$
add a comment |
$begingroup$
congratulations on writing a fairly clear, readable function! (And welcome!)
What types do you take?
You explicitly check for an instance of type list. I think you should invert your check, and look for a string type instead. The reason is that it would enable you to accept iterables other than list as your errors.
For example, you would be able to do something like:
add_error(edict, 'key', (str(e) for e in ...))
That last parameter is not a list, but it is something you might want to do. Also, *args is not a list but a tuple - you might want to splat a tuple rather than converting it to a list first.
What types do you take?
Your key parameter is always tested as a string. But dicts can have other key-types than string, and you neither test those, nor do you appear to have coded any kind of rejection on that basis. I suggest you add some tests that demonstrate your intent: is it okay to use non-strings as keys, or not?
What constraints exist on the errors?
I don't see any indication of what happens when duplicate errors are added. Is this intended to be allowed, or not?
What constraints exist on the keys?
Is it okay to use None as a key? How about '' (empty string)? Tests, please.
$endgroup$
add a comment |
Your Answer
StackExchange.ifUsing("editor", function ()
return StackExchange.using("mathjaxEditing", function ()
StackExchange.MarkdownEditor.creationCallbacks.add(function (editor, postfix)
StackExchange.mathjaxEditing.prepareWmdForMathJax(editor, postfix, [["\$", "\$"]]);
);
);
, "mathjax-editing");
StackExchange.ifUsing("editor", function ()
StackExchange.using("externalEditor", function ()
StackExchange.using("snippets", function ()
StackExchange.snippets.init();
);
);
, "code-snippets");
StackExchange.ready(function()
var channelOptions =
tags: "".split(" "),
id: "196"
;
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function()
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled)
StackExchange.using("snippets", function()
createEditor();
);
else
createEditor();
);
function createEditor()
StackExchange.prepareEditor(
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: false,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: null,
bindNavPrevention: true,
postfix: "",
imageUploader:
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
,
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
);
);
darkhorse is a new contributor. Be nice, and check out our Code of Conduct.
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fcodereview.stackexchange.com%2fquestions%2f216535%2fmethod-for-adding-error-messages-to-a-dictionary-given-a-key%23new-answer', 'question_page');
);
Post as a guest
Required, but never shown
2 Answers
2
active
oldest
votes
2 Answers
2
active
oldest
votes
active
oldest
votes
active
oldest
votes
$begingroup$
Consider narrowing accepted types
This might not be possible based on the context of your code, but if it is: arguments sharing one of many different types hinders and complicates testability and maintainability. There are many different solutions to this that will help this situation; one is accepting variadic arguments - i.e.
def add_error(error_dict, key, *errs):
This is still easily invocable without needing to wrap a single error in a list.
Use x not in instead of not x in
i.e.
if key not in error_dict
Lose your loop
and also lose your empty-list assignment, instead doing
error_dict.setdefault(key, []).extend(err)
If you use the variadic suggestion above, your entire function becomes that one line.
Immutable or not?
Currently you do two things - alter a dictionary and return it - when you should only pick one. Either make a copy of the dict and return an altered version, or modify the dict and don't return anything.
$endgroup$
add a comment |
$begingroup$
Consider narrowing accepted types
This might not be possible based on the context of your code, but if it is: arguments sharing one of many different types hinders and complicates testability and maintainability. There are many different solutions to this that will help this situation; one is accepting variadic arguments - i.e.
def add_error(error_dict, key, *errs):
This is still easily invocable without needing to wrap a single error in a list.
Use x not in instead of not x in
i.e.
if key not in error_dict
Lose your loop
and also lose your empty-list assignment, instead doing
error_dict.setdefault(key, []).extend(err)
If you use the variadic suggestion above, your entire function becomes that one line.
Immutable or not?
Currently you do two things - alter a dictionary and return it - when you should only pick one. Either make a copy of the dict and return an altered version, or modify the dict and don't return anything.
$endgroup$
add a comment |
$begingroup$
Consider narrowing accepted types
This might not be possible based on the context of your code, but if it is: arguments sharing one of many different types hinders and complicates testability and maintainability. There are many different solutions to this that will help this situation; one is accepting variadic arguments - i.e.
def add_error(error_dict, key, *errs):
This is still easily invocable without needing to wrap a single error in a list.
Use x not in instead of not x in
i.e.
if key not in error_dict
Lose your loop
and also lose your empty-list assignment, instead doing
error_dict.setdefault(key, []).extend(err)
If you use the variadic suggestion above, your entire function becomes that one line.
Immutable or not?
Currently you do two things - alter a dictionary and return it - when you should only pick one. Either make a copy of the dict and return an altered version, or modify the dict and don't return anything.
$endgroup$
Consider narrowing accepted types
This might not be possible based on the context of your code, but if it is: arguments sharing one of many different types hinders and complicates testability and maintainability. There are many different solutions to this that will help this situation; one is accepting variadic arguments - i.e.
def add_error(error_dict, key, *errs):
This is still easily invocable without needing to wrap a single error in a list.
Use x not in instead of not x in
i.e.
if key not in error_dict
Lose your loop
and also lose your empty-list assignment, instead doing
error_dict.setdefault(key, []).extend(err)
If you use the variadic suggestion above, your entire function becomes that one line.
Immutable or not?
Currently you do two things - alter a dictionary and return it - when you should only pick one. Either make a copy of the dict and return an altered version, or modify the dict and don't return anything.
answered 2 hours ago
ReinderienReinderien
4,975925
4,975925
add a comment |
add a comment |
$begingroup$
congratulations on writing a fairly clear, readable function! (And welcome!)
What types do you take?
You explicitly check for an instance of type list. I think you should invert your check, and look for a string type instead. The reason is that it would enable you to accept iterables other than list as your errors.
For example, you would be able to do something like:
add_error(edict, 'key', (str(e) for e in ...))
That last parameter is not a list, but it is something you might want to do. Also, *args is not a list but a tuple - you might want to splat a tuple rather than converting it to a list first.
What types do you take?
Your key parameter is always tested as a string. But dicts can have other key-types than string, and you neither test those, nor do you appear to have coded any kind of rejection on that basis. I suggest you add some tests that demonstrate your intent: is it okay to use non-strings as keys, or not?
What constraints exist on the errors?
I don't see any indication of what happens when duplicate errors are added. Is this intended to be allowed, or not?
What constraints exist on the keys?
Is it okay to use None as a key? How about '' (empty string)? Tests, please.
$endgroup$
add a comment |
$begingroup$
congratulations on writing a fairly clear, readable function! (And welcome!)
What types do you take?
You explicitly check for an instance of type list. I think you should invert your check, and look for a string type instead. The reason is that it would enable you to accept iterables other than list as your errors.
For example, you would be able to do something like:
add_error(edict, 'key', (str(e) for e in ...))
That last parameter is not a list, but it is something you might want to do. Also, *args is not a list but a tuple - you might want to splat a tuple rather than converting it to a list first.
What types do you take?
Your key parameter is always tested as a string. But dicts can have other key-types than string, and you neither test those, nor do you appear to have coded any kind of rejection on that basis. I suggest you add some tests that demonstrate your intent: is it okay to use non-strings as keys, or not?
What constraints exist on the errors?
I don't see any indication of what happens when duplicate errors are added. Is this intended to be allowed, or not?
What constraints exist on the keys?
Is it okay to use None as a key? How about '' (empty string)? Tests, please.
$endgroup$
add a comment |
$begingroup$
congratulations on writing a fairly clear, readable function! (And welcome!)
What types do you take?
You explicitly check for an instance of type list. I think you should invert your check, and look for a string type instead. The reason is that it would enable you to accept iterables other than list as your errors.
For example, you would be able to do something like:
add_error(edict, 'key', (str(e) for e in ...))
That last parameter is not a list, but it is something you might want to do. Also, *args is not a list but a tuple - you might want to splat a tuple rather than converting it to a list first.
What types do you take?
Your key parameter is always tested as a string. But dicts can have other key-types than string, and you neither test those, nor do you appear to have coded any kind of rejection on that basis. I suggest you add some tests that demonstrate your intent: is it okay to use non-strings as keys, or not?
What constraints exist on the errors?
I don't see any indication of what happens when duplicate errors are added. Is this intended to be allowed, or not?
What constraints exist on the keys?
Is it okay to use None as a key? How about '' (empty string)? Tests, please.
$endgroup$
congratulations on writing a fairly clear, readable function! (And welcome!)
What types do you take?
You explicitly check for an instance of type list. I think you should invert your check, and look for a string type instead. The reason is that it would enable you to accept iterables other than list as your errors.
For example, you would be able to do something like:
add_error(edict, 'key', (str(e) for e in ...))
That last parameter is not a list, but it is something you might want to do. Also, *args is not a list but a tuple - you might want to splat a tuple rather than converting it to a list first.
What types do you take?
Your key parameter is always tested as a string. But dicts can have other key-types than string, and you neither test those, nor do you appear to have coded any kind of rejection on that basis. I suggest you add some tests that demonstrate your intent: is it okay to use non-strings as keys, or not?
What constraints exist on the errors?
I don't see any indication of what happens when duplicate errors are added. Is this intended to be allowed, or not?
What constraints exist on the keys?
Is it okay to use None as a key? How about '' (empty string)? Tests, please.
answered 46 mins ago
Austin HastingsAustin Hastings
7,5671233
7,5671233
add a comment |
add a comment |
darkhorse is a new contributor. Be nice, and check out our Code of Conduct.
darkhorse is a new contributor. Be nice, and check out our Code of Conduct.
darkhorse is a new contributor. Be nice, and check out our Code of Conduct.
darkhorse is a new contributor. Be nice, and check out our Code of Conduct.
Thanks for contributing an answer to Code Review Stack Exchange!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
Use MathJax to format equations. MathJax reference.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fcodereview.stackexchange.com%2fquestions%2f216535%2fmethod-for-adding-error-messages-to-a-dictionary-given-a-key%23new-answer', 'question_page');
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown