On Fri, Nov 15, 2013 at 9:10 PM, Tim Peters wrote:
> > _DI4Y = _days_before_year(5)
> > # A 4-year cycle has an extra leap day over what we'd get from pasting
> > # together 4 single years.
> > assert _DI4Y == 4 * 365 + 1
> >
> > To me, the constant should be directly set to its known value.
>
On Nov 17, 2013, at 11:05 PM, Maciej Fijalkowski wrote:
>My problem with -O and -OO is that their arguments are very circular.
>Indeed, I understand the need why you would want in certain and
>limited cases to remove both docstrings and asserts. So some options
>for doing so are ok. But a lot of a
17.11.2013 23:05, Guido van Rossum wrote:
The correct rule should be "don't use assert (the statement) to check
for valid user input" and the stated reason should be that the assert
statement was *designed* to be disabled globally, not to be a
shorthand for "if not X: raise (mumble) Y". A coroll
On Sun, Nov 17, 2013 at 1:05 PM, Maciej Fijalkowski wrote:
> My problem with -O and -OO is that their arguments are very circular.
> Indeed, I understand the need why you would want in certain and
> limited cases to remove both docstrings and asserts. So some options
> for doing so are ok. But a l
Gregory Salvan wrote:
I believe the point of removing assertions is also to avoid throwing
unhandled developper errors to end-user
I'm not sure I buy that. An assert is saying that something
should never happen. If it does happen, either it's going
to lead to an exception further down the track
On Sun, Nov 17, 2013 at 9:02 PM, Barry Warsaw wrote:
> On Nov 17, 2013, at 05:14 PM, Victor Stinner wrote:
>
>>2013/11/16 Maciej Fijalkowski :
>>> Can I see some writeup how -OO benefit embedded devices?
>>
>>You get smaller .pyc files. In an embedded device, the whole OS may be
>>written in a sma
On Nov 17, 2013, at 05:14 PM, Victor Stinner wrote:
>2013/11/16 Maciej Fijalkowski :
>> Can I see some writeup how -OO benefit embedded devices?
>
>You get smaller .pyc files. In an embedded device, the whole OS may be
>written in a small memory, something like 64 MB or smaller. Removing
>doctring
On Sun, 17 Nov 2013 17:14:38 +0100, Victor Stinner
wrote:
> 2013/11/16 Maciej Fijalkowski :
> > Can I see some writeup how -OO benefit embedded devices?
>
> You get smaller .pyc files. In an embedded device, the whole OS may be
> written in a small memory, something like 64 MB or smaller. Removi
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 signatur
On Saturday, November 16, 2013, Steven D'Aprano wrote:
> On Sat, Nov 16, 2013 at 11:16:48AM -0500, Donald Stufft wrote:
> > 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
2013/11/16 Maciej Fijalkowski :
> Can I see some writeup how -OO benefit embedded devices?
You get smaller .pyc files. In an embedded device, the whole OS may be
written in a small memory, something like 64 MB or smaller. Removing
doctrings help to fit in 64 MB.
I don't know if dropping "assert"
Le 17/11/2013 12:27, Steven D'Aprano a écrit :
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 runt
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 yo
On Sun, 17 Nov 2013 21:27:24 +1100
Steven D'Aprano wrote:
> On Sun, Nov 17, 2013 at 11:00:50AM +0100, Antoine Pitrou wrote:
> > On Sun, 17 Nov 2013 18:04:43 +1100
> > Steven D'Aprano wrote:
> > > On Sat, Nov 16, 2013 at 04:46:00PM +0100, Antoine Pitrou wrote:
> > >
> > > > I agree that conflatin
On Sun, Nov 17, 2013 at 11:00:50AM +0100, Antoine Pitrou wrote:
> On Sun, 17 Nov 2013 18:04:43 +1100
> Steven D'Aprano wrote:
> > On Sat, Nov 16, 2013 at 04:46:00PM +0100, Antoine Pitrou wrote:
> >
> > > I agree that conflating the two doesn't help the discussion.
> > > While removing docstrings
On Sun, 17 Nov 2013 18:04:43 +1100
Steven D'Aprano wrote:
> On Sat, Nov 16, 2013 at 04:46:00PM +0100, 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 sing
On Sat, Nov 16, 2013 at 11:16:48AM -0500, Donald Stufft wrote:
> 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* ex
On Sun, Nov 17, 2013 at 01:50:31AM +1000, Nick Coghlan wrote:
> No, that's the wrong question to ask. The onus is on *you* to ask "Who
> is this feature for? Do they still need it? Can we meet their needs in
> a different way?". You're the one proposing to break things, so it's
> up to you to make
On Sat, Nov 16, 2013 at 04:46:00PM +0100, 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 sy
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
On Sat, 16 Nov 2013 11:16:48 -0500
Donald Stufft wrote:
> 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.
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 bi
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
On 17 November 2013 01:34, Maciej Fijalkowski wrote:
> On Sat, Nov 16, 2013 at 5:33 PM, Maciej Fijalkowski wrote:
>> On Sat, Nov 16, 2013 at 5:09 PM, Nick Coghlan wrote:
>>> On 16 November 2013 23:17, Maciej Fijalkowski wrote:
On Sat, Nov 16, 2013 at 3:51 AM, Terry Reedy wrote:
> If u
On Sat, 16 Nov 2013 17:34:15 +0200
Maciej Fijalkowski wrote:
> On Sat, Nov 16, 2013 at 5:33 PM, Maciej Fijalkowski wrote:
> > On Sat, Nov 16, 2013 at 5:09 PM, Nick Coghlan wrote:
> >> On 16 November 2013 23:17, Maciej Fijalkowski wrote:
> >>> On Sat, Nov 16, 2013 at 3:51 AM, Terry Reedy wrote:
On Sat, Nov 16, 2013 at 5:33 PM, Maciej Fijalkowski wrote:
> On Sat, Nov 16, 2013 at 5:09 PM, Nick Coghlan wrote:
>> On 16 November 2013 23:17, Maciej Fijalkowski wrote:
>>> On Sat, Nov 16, 2013 at 3:51 AM, Terry Reedy wrote:
If user input can trigger an assert, then the code should raise
On Sat, Nov 16, 2013 at 5:09 PM, Nick Coghlan wrote:
> On 16 November 2013 23:17, Maciej Fijalkowski wrote:
>> On Sat, Nov 16, 2013 at 3:51 AM, Terry Reedy wrote:
>>> If user input can trigger an assert, then the code should raise a normal
>>> exception that will not disappear with -OO.
>>
>> Ma
On 16 November 2013 23:17, Maciej Fijalkowski wrote:
> On Sat, Nov 16, 2013 at 3:51 AM, Terry Reedy wrote:
>> If user input can trigger an assert, then the code should raise a normal
>> exception that will not disappear with -OO.
>
> May I assert that -OO should instead be killed?
"I don't care
On Sat, Nov 16, 2013 at 3:51 AM, Terry Reedy wrote:
> http://bugs.python.org/issue19562
> propose to change the first assert in Lib/datetime.py
> assert 1 <= month <= 12, month
> to
> assert 1 <= month <= 12,'month must be in 1..12'
> to match the next two asserts out of the *53* in the file.
> Should stdlib code use assert at all?
>
> If user input can trigger an assert, then the code should raise a normal
> exception that will not disappear with -OO.
>
> If the assert is testing program logic, then it seems that the test belongs
> in the test file, in this case, test/test_datetime.py.
[Terry Reedy]
> Should stdlib code use assert at all?
Of course, and for exactly the same reasons we use `assert()` in
Python's C code: to verify preconditions, postconditions, and
invariants that should never fail. Assertions should never be used
to, e.g., verify user-supplied input (or anythin
http://bugs.python.org/issue19562
propose to change the first assert in Lib/datetime.py
assert 1 <= month <= 12, month
to
assert 1 <= month <= 12,'month must be in 1..12'
to match the next two asserts out of the *53* in the file. I think that
is the wrong direction of change, but that is not
32 matches
Mail list logo
