Making asserts non-recoverable.
How adverse would you guys feel about a change to the way asserts are handled so that they are not recoverable? Asserts could latch on to the first failed assert and always throw an AssertionError on subsequent assert statements. Another way would be for subsequent asserts to turn off after the first failure. As long as developers keep the contract that asserts should never fail, they wont notice this change; and it blocks developers from writing code that is dependent on asserts.
On 5/13/2020 10:40 AM, Rhodri James wrote:
Agreed. Is the OP saying that if you catch the AssertError and continue, then every assert after that would also raise an AssertError, even if the condition were True? So if say I got an assertion in my user code and ignored it, then assertions in (say) the stdlib would start throwing, even if they otherwise wouldn't? You're linking together otherwise unrelated things, and that doesn't seem desirable. I don't see where this would be useful, but am willing to be proven wrong. Eric
I'm working with developers that have decided to use asserts every time they want to throw an exception. I feel that their should be something that dissuades this behavior in the language design. This could be making asserts not recoverable, making it so you can't stop assert failures from printing to stdout, forcing the return code to -1 on process termination if an assert fails, or something else.
On Thu, May 14, 2020 at 2:20 AM <chris.the.developer.0@gmail.com> wrote:
I'm working with developers that have decided to use asserts every time they want to throw an exception. I feel that their should be something that dissuades this behavior in the language design. This could be making asserts not recoverable, making it so you can't stop assert failures from printing to stdout, forcing the return code to -1 on process termination if an assert fails, or something else.
There is something! Run your code with -OO and those asserts won't happen any more. You can easily demonstrate that this will then break their code, and thus prove that asserts are not the right tool to use. ChrisA
That's what I did on my first day :D Setting up my dev environment for the first time, the 'run this to make sure it is set up' script was failing. After walking the debugger through several 'this should not happen' oddities, the developer that was helping me eventually figured out I was running with '-O'. Ended my first day with "No-one uses -O, don't use it." After spending some time thinking about it, I concluded that I can't be the only developer to be in this situation. I think that if the bar was higher than 'Don't use -O' for using assertions as part of program logic, people new to the language wont be as likely to pick up this habit.
I'm sorry, but it is just unreasonable to expect us to consider a random backwards incompatible language change just because you can't get your developers to follow a reasonable coding guideline. On Wed, May 13, 2020 at 10:30 AM Chris . <chris.the.developer.0@gmail.com> wrote:
-- --Guido van Rossum (python.org/~guido) *Pronouns: he/him **(why is my pronoun here?)* <http://feministing.com/2015/02/03/how-using-they-as-a-singular-pronoun-can-c...>
On Wed, May 13, 2020 at 05:28:20PM -0000, Chris . wrote:
I use -O and sometimes it even makes a difference to performance. I know that people using embedded Python sometimes like to use not just -O but -OO to remove docstrings because every byte matters. "No one uses -O" is, I'm afraid, one of those myths popular among Python users, like "No one uses anything but CPython" and "Everyone uses an IDE". I feel your pain -- I used to work with an otherwise really good Python coder who was strict about following every best practice in the book *except* he insisted on using assert for all his error checking. Very frustrating! -- Steven
On 14/05/20 8:55 am, Richard Damon wrote:
This person seems to be a new team member who doesn't have the power to force the others to do anything against their will. So suggestions like this aren't going to help him. Mind you, changing the language as he requests probably wouldn't help him either, as the other developers would just refuse to upgrade to this new version that breaks their code. -- Greg
On 5/13/20 10:54 PM, Greg Ewing wrote:
But normally getting a test case added to unit tests is easier that establishing policy. You file a bug report that code fails with the -O option, an and a unit test to reproduce. (Which would seem justifiable unless the spec actually says -O not supported). To remove the test, someone is likely going to need to go on record that -O is not supported, which if it isn't really the policy, they would likely be a bit hesitant to do. -- Richard Damon
On 13May2020 16:20, chris.the.developer.0@gmail.com <chris.the.developer.0@gmail.com> wrote:
I'm working with developers that have decided to use asserts every time they want to throw an exception.
Since asserts are disabled when the optimiser is activated, I'd say these devs don't speak Python. Also, AssertionErrors are a pretty vague way to raise an exception, and there's a whole suite of exceptions available.
I feel that their should be something that dissuades this behavior in the language design.
Bad code can be written in any language, of any design. You would FAR better off finding out _why_ they want to use this approach, since the language documentation makes it clear that asserts may have NO EFFECT AT RUNTIME, depending on the mode. The only thing I can think of for this is that: assert x > 0 is much more concise than: if x <= 0: raise ValueError("x should be > 0, got %s" % x)
Making asserts inflexible, in a complete lack of consistency with every other exception type, seems very artificial. You'lll just push the devs from misusing asserts to misusing something else. _Are_ your devs catching AssertionError and preventing programme termination? Cheers, Cameron Simpson <cs@cskk.id.au>
On 5/13/2020 10:40 AM, Rhodri James wrote:
Agreed. Is the OP saying that if you catch the AssertError and continue, then every assert after that would also raise an AssertError, even if the condition were True? So if say I got an assertion in my user code and ignored it, then assertions in (say) the stdlib would start throwing, even if they otherwise wouldn't? You're linking together otherwise unrelated things, and that doesn't seem desirable. I don't see where this would be useful, but am willing to be proven wrong. Eric
I'm working with developers that have decided to use asserts every time they want to throw an exception. I feel that their should be something that dissuades this behavior in the language design. This could be making asserts not recoverable, making it so you can't stop assert failures from printing to stdout, forcing the return code to -1 on process termination if an assert fails, or something else.
On Thu, May 14, 2020 at 2:20 AM <chris.the.developer.0@gmail.com> wrote:
I'm working with developers that have decided to use asserts every time they want to throw an exception. I feel that their should be something that dissuades this behavior in the language design. This could be making asserts not recoverable, making it so you can't stop assert failures from printing to stdout, forcing the return code to -1 on process termination if an assert fails, or something else.
There is something! Run your code with -OO and those asserts won't happen any more. You can easily demonstrate that this will then break their code, and thus prove that asserts are not the right tool to use. ChrisA
That's what I did on my first day :D Setting up my dev environment for the first time, the 'run this to make sure it is set up' script was failing. After walking the debugger through several 'this should not happen' oddities, the developer that was helping me eventually figured out I was running with '-O'. Ended my first day with "No-one uses -O, don't use it." After spending some time thinking about it, I concluded that I can't be the only developer to be in this situation. I think that if the bar was higher than 'Don't use -O' for using assertions as part of program logic, people new to the language wont be as likely to pick up this habit.
I'm sorry, but it is just unreasonable to expect us to consider a random backwards incompatible language change just because you can't get your developers to follow a reasonable coding guideline. On Wed, May 13, 2020 at 10:30 AM Chris . <chris.the.developer.0@gmail.com> wrote:
-- --Guido van Rossum (python.org/~guido) *Pronouns: he/him **(why is my pronoun here?)* <http://feministing.com/2015/02/03/how-using-they-as-a-singular-pronoun-can-c...>
On Wed, May 13, 2020 at 05:28:20PM -0000, Chris . wrote:
I use -O and sometimes it even makes a difference to performance. I know that people using embedded Python sometimes like to use not just -O but -OO to remove docstrings because every byte matters. "No one uses -O" is, I'm afraid, one of those myths popular among Python users, like "No one uses anything but CPython" and "Everyone uses an IDE". I feel your pain -- I used to work with an otherwise really good Python coder who was strict about following every best practice in the book *except* he insisted on using assert for all his error checking. Very frustrating! -- Steven
On 14/05/20 8:55 am, Richard Damon wrote:
This person seems to be a new team member who doesn't have the power to force the others to do anything against their will. So suggestions like this aren't going to help him. Mind you, changing the language as he requests probably wouldn't help him either, as the other developers would just refuse to upgrade to this new version that breaks their code. -- Greg
On 5/13/20 10:54 PM, Greg Ewing wrote:
But normally getting a test case added to unit tests is easier that establishing policy. You file a bug report that code fails with the -O option, an and a unit test to reproduce. (Which would seem justifiable unless the spec actually says -O not supported). To remove the test, someone is likely going to need to go on record that -O is not supported, which if it isn't really the policy, they would likely be a bit hesitant to do. -- Richard Damon
On 13May2020 16:20, chris.the.developer.0@gmail.com <chris.the.developer.0@gmail.com> wrote:
I'm working with developers that have decided to use asserts every time they want to throw an exception.
Since asserts are disabled when the optimiser is activated, I'd say these devs don't speak Python. Also, AssertionErrors are a pretty vague way to raise an exception, and there's a whole suite of exceptions available.
I feel that their should be something that dissuades this behavior in the language design.
Bad code can be written in any language, of any design. You would FAR better off finding out _why_ they want to use this approach, since the language documentation makes it clear that asserts may have NO EFFECT AT RUNTIME, depending on the mode. The only thing I can think of for this is that: assert x > 0 is much more concise than: if x <= 0: raise ValueError("x should be > 0, got %s" % x)
Making asserts inflexible, in a complete lack of consistency with every other exception type, seems very artificial. You'lll just push the devs from misusing asserts to misusing something else. _Are_ your devs catching AssertionError and preventing programme termination? Cheers, Cameron Simpson <cs@cskk.id.au>
participants (10)
-
Cameron Simpson -
Chris . -
Chris Angelico -
chris.the.developer.0＠gmail.com
-
Eric V. Smith -
Greg Ewing -
Guido van Rossum -
Rhodri James -
Richard Damon -
Steven D'Aprano