> I haven't yet seen any justification for syntax here. The nearest I've seen 
> is that this "ensure" action is more like:
>
> try:
>     cond = x >= 0
> except BaseException:
>     raise AssertionError("x must be positive")
> else:
>     if not cond:
>         raise AssertionError("x must be positive")
>
> Which, IMO, is a bad idea, and I'm not sure anyone was actually advocating it 
> anyway.
> 
> ChrisA

Indeed, I was the one advocating for it :) 

Based on all the feedback I received from this discussion, I realized that my 
implementation was completely flawed by the fact that I had done the class and 
functions decorators first, and wanted to apply the same pattern to the inline 
validator, resulting in this assert_valid with overkill delayed evaluation. 
Resulting in me saying that the only way out would be a new python language 
element.

I tried my best to update valid8 and reached a new stable point with version 
3.0.0, providing 2 main utilities for inline validation:
 - the simple but not so powerful `quick_valid` function 
 - the more verbose (2 lines) but much more generic `wrap_valid` context 
manager (that's the best I can do today !)

The more capable but delayed-evaluation based `assert_valid` is not recommended 
anymore, or just a tool to replicate what is done in the function and class 
validation decorators. Like the decorators, it adds the ability to blend two 
styles of base functions (boolean testers and failure raisers) with boolean 
operators seamlessly. But the complexity is not worth it for inline validation 
(it seems to be worth it for decorators).

See https://smarie.github.io/python-valid8 for the new updated documentation. I 
also updated the problem description page at 
https://smarie.github.io/python-valid8/why_validation/ so as to keep a 
reference of the problem description and "wishlist" (whether it is implemented 
by this library or by new language elements in the future). Do not hesitate to 
contribute or send me your edits (off-list).

I would love to get feedback from anyone concerning this library, whether you 
consider it's useless or "interesting but...". We should probably take this 
offline though, so as not to pollute the initial thread.

Thanks again, a great weekend to all (end of the day here in france ;) )
Kind regards

Sylvain 

_______________________________________________
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Reply via email to