Re: [Python-Dev] (#19562) Asserts in Python stdlib code (datetime.py)
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 > 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 wrote: > > > On 17 November 2013 01:46, Antoine Pitrou 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 | ncogh...@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 > > ___ 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/archive%40mail-archive.com
Re: [Python-Dev] (#19562) Asserts in Python stdlib code (datetime.py)
I believe the point of removing assertions is also to avoid throwing unhandled developper errors to end-user and not only "performance". It's like "raise" without "try" block. It's certainly because I consider "assert" as a developper util, providing a concrete documentation about methods signatures. In this idea I've made a small bench to determine if it is interesting for an assertion lib to have null functions as default. https://github.com/apieum/BenchAssert I don't make critical performance applications but still doubt of the real interest of having dead code to better document. 2013/11/17 Steven D'Aprano > On Sun, Nov 17, 2013 at 11:35:21AM +0100, Antoine Pitrou wrote: > > > You didn't answer my question: did you actually use -OO in production, > > or not? Saying that -OO could have helped you optimize something you > > didn't care about isn't a very strong argument for -OO :) > > Ah, sorry, I misunderstood your question. > > I didn't use -OO, since I had no reason to remove docstrings. But I did > use -O to remove asserts. I was talking about assertions, not > docstrings. Since I haven't had to write code for embedded devices with > severely constrained memory, I've never cared about using -OO in > production. > > > > What I would like to know is if people *knowingly* add costly asserts > > to performance-critical code, with the intent of disabling them at > > runtime using -OO. > > Yes, I have knowingly added costly asserts to code with the intend of > disabling them at runtime. Was it *performance-critical* code? I don't > know, that was the point of my earlier rambling -- I could demonstrate a > speedup of the individual functions in benchmarks, but nobody spent the > effort to determine which functions were performance critical. > > > > -- > Steven > ___ > 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 > ___ 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/archive%40mail-archive.com
Re: [Python-Dev] One-line abstractmethod function?
Hi,
maybe a syntax like that can correspond:
class MyObject(metaclass=ObjectSpec):
''' MyObject doc'''
'attr1 contains something'
attr1 = None
'attr2 contains something'
attr2 = str
'method1 do something'
method1 = NotImplementedMethod('self', 'arg1', kwarg1=str)
Metaclass "ObjectSpec" would extend ABCMeta to search class source code for
comments before members assignement,
and replace NotImplementedMethod objects by a corresponding method wich
signature can simply be given by arguments or by ArgSpec, FullArgSpec,
Signature...
with factories like these of "Signature" (from_function, from_builtins...).
2013/12/6 Guido van Rossum
> On Thu, Dec 5, 2013 at 6:31 PM, Ethan Furman wrote:
> >> On Thu, Dec 05, 2013 at 01:33:00PM -0800, Guido van Rossum wrote:
> >>> Actually if you want to support multiple inheritance of your ABC, your
> >>> abstract methods *must* be no-ops (or have some kind of default
> >>> behavior that can always be done last).
>
> > Done last or first really depends on what the default behavior is,
> doesn't
> > it? Using __new__ as an example, the chain of calls for that has the
> most
> > ancestorish (yeah, I just made that word up ;) method doing the work
> first,
> > with each less-ancestorish method building on to that as the call chain
> > unwinds.
>
> If you count which call *starts* first, the base class is always
> called later than the subclass (even if it finishes earlier :-).
>
> --
> --Guido van Rossum (python.org/~guido)
> ___
> 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
>
___
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/archive%40mail-archive.com
