You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I propose making validator error messages serve one purpose: indicating where the problem is. In other words, they should contain file and variable names, line numbers, error counts, but should not contain explicit error descriptions.
More explicit error descriptions belong to the documentation and, when needed, can be restored from the error slug by the client.
So for example the message "%s class is too broad; use a more specific exception type" can be restored by the client himself by looking at the error slug.
And messages like "for example, line number %s should be replaced by language-independent constructions like "filename:line_number".
So the output
>>> from fiasko_bro import validate
>>> validate('/path/to/folder/')
[('camel_case_vars', 'for example, rename the following: WorkBook'), ('file_too_long', 'coursera.py')]
I propose making validator error messages serve one purpose: indicating where the problem is. In other words, they should contain file and variable names, line numbers, error counts, but should not contain explicit error descriptions.
More explicit error descriptions belong to the documentation and, when needed, can be restored from the error slug by the client.
So for example the message
"%s class is too broad; use a more specific exception type"
can be restored by the client himself by looking at the error slug.And messages like
"for example, line number %s
should be replaced by language-independent constructions like"filename:line_number"
.So the output
will turn into
The text was updated successfully, but these errors were encountered: