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.mo...@gmail.com> wrote: > On 16 January 2018 at 15:37, smarie > <sylvain.ma...@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 _______________________________________________ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
