Personally I think that none of the -O* should be removing asserts. It feels
like a foot gun to me. I’ve seen more than one codebase that would be
completely broken under -O* because they used asserts without even knowing
-O* existed.

Removing __debug__ blogs and doc strings I don’t think is as big of a deal,
although removing doc strings can break code as well.

On Nov 16, 2013, at 11:08 AM, Nick Coghlan <ncoghlan@gmail.com> wrote:

> On 17 November 2013 01:46, Antoine Pitrou <solipsis@pitrou.net> wrote:
>> I agree that conflating the two doesn't help the discussion.
>> While removing docstrings may be beneficial on memory-constrained
>> devices, I can't remember a single situation where I've wanted to
>> remove asserts on a production system.
>
> While I actually agree that having separate flags for --omit-debug,
> --omit-asserts and --omit-docstrings would make more sense than the
> current optimization levels, Maciej first proposed killing off -OO
> (where the most significant effect is removing docstrings which can
> result in substantial program footprint reductions for embedded
> systems), and only later switched to asking about removing asserts
> (part of -O, which also removes blocks guarded by "if __debug__", both
> of which help embedded systems preserve precious ROM space, although
> to a lesser degree than removing docstrings can save RAM).
>
> One of the most important questions to ask when proposing the removal
> of something is "What replacement are we offering for those users that
> actually need (or even just think they need) this feature?". Sometimes
> the answer is "Nothing", sometimes it's something that only covers a
> subset of previous use cases, and sometimes it's a complete functional
> equivalent with an improved spelling. But not asking the question at
> all (or, worse, dismissing the concerns of affected users as
> irrelevant and uninteresting) is a guaranteed way to annoy the very
> people that actually rely on the feature that is up for removal or
> replacement, when you *really* want them engaged and clearly
> explaining their use cases.
>
> Cheers,
> Nick.
>
> --
> Nick Coghlan   |   ncoghlan@gmail.com   |   Brisbane, Australia
> _______________________________________________
> Python-Dev mailing list
> Python-Dev@python.org
> https://mail.python.org/mailman/listinfo/python-dev

> Unsubscribe: https://mail.python.org/mailman/options/python-dev/donald%40stufft.io


-----------------
Donald Stufft
PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA


_______________________________________________
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: https://mail.python.org/mailman/options/python-dev/apieum%40gmail.com