> This is cool. Thank you. Much appreciated. > AFAIK pytest does something like this. How does your implementation differ? The pytest implementation is very powerful in the way of hints and suggestions that point to the difference and source, but when the asserted expression has more than one sub-expression, the thread-style breakdown is unreadable. I believe my chart-style implementation offers better readability.
> What is your argument for making this part of the language? Why not a 3rd > party library? The first argument is that asserts are fundamental, which is why they are a core part of the language in the first place. If they're already part of the core, we can improve them to provide more constructive feedback, without having to pull in mammoth testing frameworks, which brings me to my second argument. My understanding of the compiler is that a 3rd party library can't simply rewrite AST during the standard compilation. If one wants to intervene with the AST phase, one must rewrite and execute the python files. This is a very intrusive and impractical process for a scope of a 3rd party library. It's definitely more fitting for frameworks that act as executers such as pytest and my framework Nimoy. Please correct me if I'm mistaken. > What about asserts that are not used for testing, but as classic “unless > there’s a bug, this should hold”? Those may not want to incur the extra cost. Correct. I believe that the proper way to handle this is a switch much like `-O`. The feature will be opt-in, and one can opt-in using that switch. _______________________________________________ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/SPUISYVZWRAHJMY5IP5AZ42SDQKW6E6D/ Code of Conduct: http://python.org/psf/codeofconduct/
