[Python-ideas] Repurpose `assert' into a general-purpose check
vano at mail.mipt.ru
Tue Nov 28 02:58:34 EST 2017
On 28.11.2017 10:22, Elazar wrote:
> Just a note : in typechecked code (such as mypy's source code) assert
> is used to guide the checker:
> assert isinstance(x, CallableType)
> return x.args # checker knows it's valid
> So the assert becomes a kind of type annotation. The runtime check
> helps during tests, but is not that important - failure will be caught
> relatively soon. And I believe that the ability to remove the check at
> runtime is important, since isinstance calls have non-negligible
> impact on performance in mypy.
> (but other contributors here can correct me on this).
This results in two different interfaces. In normal mode, it enforces
types while in -O, accepts anything that passes the duck test.
> בתאריך יום ג׳, 28 בנוב׳ 2017, 09:12, מאת Ivan Pozdeev via Python-ideas
> <python-ideas at python.org <mailto:python-ideas at python.org>>:
> On 28.11.2017 8:59, Steven D'Aprano wrote:
> > On Tue, Nov 28, 2017 at 07:35:45AM +0300, Ivan Pozdeev via
> Python-ideas wrote:
> >> Actually, the way I'm using them,
> >> assert condition, "error message", type
> >> would probably be the most expressive way.
> > I disagree that is expressive -- I call it *misleading*. I see
> > which looks like an assertion (that is, a checked comment, a
> contract, a
> > check on an internal piece of logic etc) but it is actually
> being used
> > as a test.
> >> I can do anything in any Turing-complete language without any
> changes to
> >> the language. That's no reason to never change anything, is it.
> > "We can change this" is not a reason to change this. There needs
> to be a
> > *good* reason to change, and you have given no good reasons for this
> > change.
> >> The rationale basically is:
> >> * As it was intended, the statement has no practical use --
> basically a
> >> rudiment, due to disappear eventually
> > Nonsense. I make extensive use of assert as a way of checking
> > assertions, and I will fight tooth and nail against any proposal to
> > either remove it or to misuse it for public input tests instead of
> > assertions.
> I invite you to show me a single use case for those "assertions"
> after ~20 years of experience in coding (that included fairly large
> projects), I've yet to see one.
> Any, every check that you make at debug time either
> * belongs in production as well (all the more because it's harder to
> diagnose there), or
> * belongs in a test -- something coded independently from the program
> (if your code as a whole cannot be trusted, how any specific part
> of it
> can?), or
> * isn't needed at all because a fault will inevitably surface
> down the line (as some exception or an incorrect result that a
> test will
> Finally, I've got much experience using existing code outside its
> original use cases, where the original author's assumptions may no
> longer hold but the specific logic can be gauded to produce the
> result. Coding these assumptions in would undermine that goal.
> So, I see "debug assertions" as either intentionally compromizing
> correctness for performance (a direct opposite of Python's design
> principles), or as an inferiour, faulty, half-measure rudiment from
> times when CI wasn't a thing (thus not something that should be taught
> and promoted as a best practice any longer).
> >> * It can instead be reused as syntax sugar to cover a very
> common use case
> > There is no need for such syntactic sugar. It would be harmful
> > to use assert for something which is not an assertion.
> Python-ideas mailing list
> Python-ideas at python.org <mailto:Python-ideas at python.org>
> Code of Conduct: http://python.org/psf/codeofconduct/
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Python-ideas