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

Gregory Salvan apieum at gmail.com
Sat Nov 16 17:41:41 CET 2013

Hi, Some languages (C#, java) do the reverse by removing assertions if we don't tell compiler to keep them. Personnaly, I find this solution relatively accurate as I expect assertions not to be run in production.

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, --omit-asserts and --omit-docstrings).

cheers, Grégory

2013/11/16 Donald Stufft <donald at stufft.io>

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 at gmail.com> wrote: > On 17 November 2013 01:46, Antoine Pitrou <solipsis at 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 at gmail.com | Brisbane, Australia _> ________________________ > Python-Dev mailing list > Python-Dev at 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 at python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/apieum%40gmail.com -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mail.python.org/pipermail/python-dev/attachments/20131116/95647e5b/attachment.html>

More information about the Python-Dev mailing list