I think having a means for such validations separate from assertions would be helpful. However, I agree with Steven that 'validate' would be a bad keyword choice. Besides breaking compatibility with programs that use 'validate', it would break wsgiref.validate <https://docs.python.org/3.6/library/wsgiref.html#module-wsgiref.validate> in the standard library.
ᐧ On Tue, Jan 16, 2018 at 2:22 PM, Juancarlo Añez <apal...@gmail.com> wrote: > Perhaps the OP can look into Python macro libraries to get the wanted > syntax? > > https://github.com/lihaoyi/macropy > > On Tue, Jan 16, 2018 at 2:35 PM, Paul Moore <p.f.mo...@gmail.com> wrote: > >> On 16 January 2018 at 17:36, Sylvain MARIE >> <sylvain.ma...@schneider-electric.com> wrote: >> > (trying with direct reply this time) >> > >> >> Why do you do this? What's the requirement for delaying evaluation of >> the condition? >> > >> > Thanks for challenging my poorly chosen examples :) >> > >> > The primary requirement is about *catching* >> unwanted/uncontrolled/heterogenous exceptions happening in the >> underlying functions that are combined together to provide the validation >> means, so as to provide a uniform/consistent outcome however diverse the >> underlying functions are (they can return booleans or raise exceptions, or >> both). >> > >> > In your proposal, if 'is_foo_compliant' raises an exception, it will >> not be caught by 'assert_valid', therefore the ValidationError will not be >> raised. So this is not what I want as an application developer. >> >> Ah, OK. But nothing in your proposal for a new statement suggests you >> wanted that, and assert doesn't work like that, so I hadn't realised >> that's what you were after. >> >> You could of course simply do: >> >> def assert_valid(expr, help_msg): >> # Catch exceptions in expr() as you see fit >> if not expr(): >> raise ValidationError(help_msg) >> >> assert_valid(lambda: 0 <= surf < 10000 and is_foo_compliant(surf), >> help_msg="surface should be 0=<x<10000 or foo compliant") >> >> No need for a whole expression language :-) >> >> 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/ >> > > > > -- > Juancarlo *Añez* > > _______________________________________________ > Python-ideas mailing list > Python-ideas@python.org > https://mail.python.org/mailman/listinfo/python-ideas > Code of Conduct: http://python.org/psf/codeofconduct/ > >
_______________________________________________ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/