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

[Gregory Salvan]

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>