[Python-ideas] Repurpose `assert' into a general-purpose check

[Paul Moore]

Grr, Google Groups gateway messes up reply-to. Apologies to anyone who
gets a double-post, please can posters ensure that reply-to is set to
the list, and *not* to the Google Groups gateway? Thanks.
Paul

On 16 January 2018 at 15:54, Paul Moore <p.f.moore at gmail.com> wrote:
> On 16 January 2018 at 15:37, smarie
> <sylvain.marie at schneider-electric.com> wrote:
>
>>> If you, the developer, don't want a check to be disabled, then you
>>> shouldn't call it an assertion and use assert.
>>
>>
>> That is exactly what I'm saying. It seems that we both agree that
>> applicative value validation is different from asserts, and that assert
>> should not be used for applicative value validation.
>> For this reason, I do not suggest to go in the direction the OP is
>> mentioning but rather to explicitly separate the 2 concepts by creating a
>> new statement for value validation.
>>
>>>
>>> The problem with a statement called "validate" is that it will break a
>>> huge number of programs that already include functions and methods using
>>> that name.
>>
>> You definitely make a point here. But that would be the case for absolutely
>> *any* language evolution as soon as the proposed statements are plain old
>> english words. Should it be a show-stopper ? I dont think so.
>
> Why does this need to be a statement at all? Unlike assert, it's
> always executed, so it can be defined as a simple function:
>
> def validate(test, message):
>     if not test:
>         raise ValidartionError(message)
>
>>> But apart from the use of a keyword, we already have a way to do almost
>>> exactly what you want:
>>>
>>>     if not expression: raise ValidationError(message)
>>>
>>> after defining some appropriate ValidationError class. And it is only a
>>> few key presses longer than the proposed:
>>>
>>>     validate expression, ValidationError, message
>>
>>
>> This is precisely what is not good in my opinion: here you do not separate
>> <validation means> from <validation intent>. Of course if <validation means>
>> is just a "x > 0" statement, it works, but now what if you rely on a
>> 3d-party provided validation function (or even yours) such as e.g.
>> "is_foo_compliant" ?
>>
>> if not is_foo_compliant(x): raise ValidationError(message)
>>
>> What if this third part method raises an exception instead of returning
>> False in some cases ?
>>
>> try:
>>     if not is_foo_compliant(x): raise ValidationError(message)
>> except:
>>     raise MyValidationError(message)
>>
>> What if you want to compose this third party function with *another* one
>> that returns False but not exceptions ? Say, with an OR ? (one or the other
>> should work). Yields:
>>
>> try:
>>     if not is_foo_compliant(x): raise ValidationError(message)
>> except:
>>     if not is_bar_compliant(x):
>>         raise MyValidationError(message)
>>
>> It starts to be quite ugly, messy... while the applicative intent is clear
>> and could be expressed directly as:
>>
>>     validate is_foo_compliant(x) or is_bar_compliant(x)
>> ValidationError(message)
>
> I don't see how a validate statement avoids having to deal with all of
> the complexity you mention here. And it's *far* easier to handle this
> as a standalone function - if you find a new requirement like the ones
> you suggest above, you simply modify the function (and release an
> updated version of your package, if you choose to release your code on
> PyPI) and you're done. With a new statement, you'd need to raise a
> Python feature request, wait for at least the next Python release to
> see the modification, and *still* have to support people on older
> versions of Python with the unfixed version.
>
> Also, a validate() function will wor on older versions of Python, all
> the way back to Python 2.7 if you want.
>
> Paul