(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:


Hello there

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 language.
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 exception_message>'

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 :

class InvalidSurface(ValidationError):
    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
Kind regards


Sylvain