<div dir="ltr"><div><div>Hi,<br>Some languages (C#, java) do the reverse by removing assertions if we don't tell compiler to keep them.<br></div>Personnaly, I find this solution relatively accurate as I expect assertions not to be run in production.<br>
<br></div><div>It would be painful to have this behaviour in python now, but I hope we'll keep a way to remove assertions and find interesting the solution of specific flags (--omit-debug,<br>
--omit-asserts and --omit-docstrings).<br></div><div><br><br></div><div>cheers,<br></div><div>Grégory<br></div></div><div class="gmail_extra"><br><br><div class="gmail_quote">2013/11/16 Donald Stufft <span dir="ltr"><<a href="mailto:donald@stufft.io" target="_blank">donald@stufft.io</a>></span><br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Personally I think that none of the -O* should be removing asserts. It feels<br>
like a foot gun to me. I’ve seen more than one codebase that would be<br>
completely broken under -O* because they used asserts without even knowing<br>
-O* existed.<br>
<br>
Removing __debug__ blogs and doc strings I don’t think is as big of a deal,<br>
although removing doc strings can break code as well.<br>
<div><div class="h5"><br>
On Nov 16, 2013, at 11:08 AM, Nick Coghlan <<a href="mailto:ncoghlan@gmail.com">ncoghlan@gmail.com</a>> wrote:<br>
<br>
> On 17 November 2013 01:46, Antoine Pitrou <<a href="mailto:solipsis@pitrou.net">solipsis@pitrou.net</a>> wrote:<br>
>> I agree that conflating the two doesn't help the discussion.<br>
>> While removing docstrings may be beneficial on memory-constrained<br>
>> devices, I can't remember a single situation where I've wanted to<br>
>> remove asserts on a production system.<br>
><br>
> While I actually agree that having separate flags for --omit-debug,<br>
> --omit-asserts and --omit-docstrings would make more sense than the<br>
> current optimization levels, Maciej first proposed killing off -OO<br>
> (where the most significant effect is removing docstrings which can<br>
> result in substantial program footprint reductions for embedded<br>
> systems), and only later switched to asking about removing asserts<br>
> (part of -O, which also removes blocks guarded by "if __debug__", both<br>
> of which help embedded systems preserve precious ROM space, although<br>
> to a lesser degree than removing docstrings can save RAM).<br>
><br>
> One of the most important questions to ask when proposing the removal<br>
> of something is "What replacement are we offering for those users that<br>
> actually need (or even just think they need) this feature?". Sometimes<br>
> the answer is "Nothing", sometimes it's something that only covers a<br>
> subset of previous use cases, and sometimes it's a complete functional<br>
> equivalent with an improved spelling. But not asking the question at<br>
> all (or, worse, dismissing the concerns of affected users as<br>
> irrelevant and uninteresting) is a guaranteed way to annoy the very<br>
> people that actually rely on the feature that is up for removal or<br>
> replacement, when you *really* want them engaged and clearly<br>
> explaining their use cases.<br>
><br>
> Cheers,<br>
> Nick.<br>
><br>
> --<br>
> Nick Coghlan   |   <a href="mailto:ncoghlan@gmail.com">ncoghlan@gmail.com</a>   |   Brisbane, Australia<br>
> _______________________________________________<br>
> Python-Dev mailing list<br>
> <a href="mailto:Python-Dev@python.org">Python-Dev@python.org</a><br>
> <a href="https://mail.python.org/mailman/listinfo/python-dev" target="_blank">https://mail.python.org/mailman/listinfo/python-dev</a><br>
</div></div>> Unsubscribe: <a href="https://mail.python.org/mailman/options/python-dev/donald%40stufft.io" target="_blank">https://mail.python.org/mailman/options/python-dev/donald%40stufft.io</a><br>
<br>
<br>
-----------------<br>
Donald Stufft<br>
PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA<br>
<br>
<br>_______________________________________________<br>
Python-Dev mailing list<br>
<a href="mailto:Python-Dev@python.org">Python-Dev@python.org</a><br>
<a href="https://mail.python.org/mailman/listinfo/python-dev" target="_blank">https://mail.python.org/mailman/listinfo/python-dev</a><br>
Unsubscribe: <a href="https://mail.python.org/mailman/options/python-dev/apieum%40gmail.com" target="_blank">https://mail.python.org/mailman/options/python-dev/apieum%40gmail.com</a><br>
<br></blockquote></div><br></div>