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.
Elazar
בתאריך יום ג׳, 28 בנוב׳ 2017, 09:12, מאת Ivan Pozdeev via Python-ideas
<python-ideas@python.org <mailto:python-ideas@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
something
> 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"
because
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
somewhere
down the line (as some exception or an incorrect result that a
test will
catch).
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
desired
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.
>
>
>
--
Regards,
Ivan
_______________________________________________
Python-ideas mailing list
Python-ideas@python.org <mailto:Python-ideas@python.org>
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/
--
Regards,
Ivan
_______________________________________________
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/
