On 5/13/20 10:54 PM, Greg Ewing wrote:
> On 14/05/20 8:55 am, Richard Damon wrote:
>> On 5/13/20 2:03 PM, Rhodri James wrote:
>>>
>>> I'm sorry, but I think the correct response is to give them a spanking
>>> in code review. I certainly wouldn't pass any code that actually
>>> relied on assert doi
On 14/05/2020 03:54, Greg Ewing wrote:
On 14/05/20 8:55 am, Richard Damon wrote:
On 5/13/20 2:03 PM, Rhodri James wrote:
I'm sorry, but I think the correct response is to give them a spanking
in code review. I certainly wouldn't pass any code that actually
relied on assert doing anything.
M
On 14/05/20 8:55 am, Richard Damon wrote:
On 5/13/20 2:03 PM, Rhodri James wrote:
I'm sorry, but I think the correct response is to give them a spanking
in code review. I certainly wouldn't pass any code that actually
relied on assert doing anything.
My thought was he just needs to add that
On 13May2020 16:20, chris.the.develope...@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
On Wed, May 13, 2020 at 05:28:20PM -, Chris . wrote:
> 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
On 5/13/20 2:03 PM, Rhodri James wrote:
> On 13/05/2020 17:20, chris.the.develope...@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
On 13/05/2020 17:20, chris.the.develope...@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.
I'm sorry, but I think the correct resp
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 .
wrote:
> That's what I did on my first day :D
> Setting up
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
On Thu, May 14, 2020 at 2:20 AM 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, maki
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 print
On 5/13/2020 10:40 AM, Rhodri James wrote:
On 13/05/2020 15:22, chris.the.develope...@gmail.com wrote:
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 AssertionEr
On 13/05/2020 15:22, chris.the.develope...@gmail.com wrote:
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
13 matches
Mail list logo
