[Python-Dev] (#19562) Asserts in Python stdlib code (datetime.py)

[Nick Coghlan]

On 17 November 2013 01:34, Maciej Fijalkowski <fijall at gmail.com> wrote:
> On Sat, Nov 16, 2013 at 5:33 PM, Maciej Fijalkowski <fijall at gmail.com> wrote:
>> On Sat, Nov 16, 2013 at 5:09 PM, Nick Coghlan <ncoghlan at gmail.com> wrote:
>>> On 16 November 2013 23:17, Maciej Fijalkowski <fijall at gmail.com> wrote:
>>>> On Sat, Nov 16, 2013 at 3:51 AM, Terry Reedy <tjreedy at udel.edu> wrote:
>>>>> If user input can trigger an assert, then the code should raise a normal
>>>>> exception that will not disappear with -OO.
>>>>
>>>> May I assert that -OO should instead be killed?
>>>
>>> "I don't care about embedded devices" is not a good rationale for
>>> killing features that really only benefit people running Python on
>>> such systems.
>>>
>>> Cheers,
>>> Nick.
>>
>> Can I see some writeup how -OO benefit embedded devices?
>
> Or more importantly, how removing assert does. And how not naming it
> --remove-asserts would not help (people really have an opinion it
> would optimize their code)

No, that's the wrong question to ask. The onus is on *you* to ask "Who
is this feature for? Do they still need it? Can we meet their needs in
a different way?". You're the one proposing to break things, so it's
up to you to make the case for why that's an OK thing to do.

And until you ask those questions, and openly and honestly do the
research to answer them (rather than assuming the answer you want),
and can provide evidence of having done so, then it's entirely
reasonable for me to dismiss the suggestion as you saying "this
doesn't benefit me, so it doesn't benefit anyone, so it's OK to get
rid of it".

That's not the way this works - backwards compatibility is sacrosanct,
and it requires some seriously compelling evidence to justify a
breach. (This even applies to the Python 3 transition: the really
annoying discrepancies between Python 2 and 3 are the ones where we
allowed a backwards compatibility break without adequate
justification, but now we're locked in to the decision due to internal
backwards compatibility constraints within the Python 3 series).

Cheers,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia