[Python-ideas] Repurpose `assert' into a general-purpose check
sylvain.marie at schneider-electric.com
Tue Jan 16 04:38:25 EST 2018
(for some reason google groups has accepted the message but the mailing
list rejected it. Re-posting it, sorry for the inconvenience)
Le mardi 28 novembre 2017 04:22:13 UTC+1, Nathan Schneider a écrit :
> I think it would be interesting to investigate how assert statements are
> used in the wild. I can think of three kinds of uses:
> 1) Nonredundant checking:
> 2) Redundant checking:
> 3) Temporary debugging:
I am very much interested by this topic, as I spent a couple months trying
to come up with a solution with the obvious constraint of not changing the
My goal was type checking and value validation for applications wishing to
get these features (so obviously, with the possibly to not disable it at
runtime even if the rest of the application is optimized). For type
checking I discovered PEP484 and many type-checkers (enforce, pytypes...)
out there, but for value validation I found nothing really satisfying to me
except many sources saying not to use assert.
I personally align with the idea already mentioned in this thread that
assert is not a tool for "end-user value validation", but a tool for other
kind of purposes - that are perfectly valid but are just not the same that
"end-user value validation" (if the name is not perfect, feel free to
propose another). What I think we're missing is “get consistent and
customizable validation outcome, whatever the inner validation means”.
Typically ‘assert isfinite(x)‘ is today a good example of what is wrong:
1. it can be disabled globally by end-users even if the lib developer
does not want it,
2. if x is None the exception is different from the exception you get if
x is not finite,
3. you can not customize the exception type for easy error codes
internationalization, you can only customize the message.
My proposal would be to rather define another statement for example
'validate <expression> <exception, exception_type or
with specific constraints on the type of exception to ensure consistency
(for example only subclasses of a ValidationError defined in the stdlib)
You can find my attempt to do that in the valid8 project
https://smarie.github.io/python-valid8, with the 'assert_valid(...)'
function. With the current language limitations I could not define
something as simple as 'validate <expression> <exception, exception_type or
exception_message>', but I created a mini lambda library to at least keep
some level of simplicity for the <expression>. The result is for example :
help_msg = 'Surface should be a positive number'
assert_valid('surface', surf, x > 0, error_type=InvalidSurface)
Oh, by the way, in valid8 I have the notion of variable name everywhere
(again, because thats interesting to the application) but I'm not sure
whether it would make sense to keep it in a 'validate' statement.
Let me know what you think
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Python-ideas