On Thu, Jun 30, 2016, at 00:12, Steven D'Aprano wrote:
> I tried to find the actual implementation of os.abort(), but I
> couldn't work out where it was or what it does. Can somebody
> enlighten me?
It's in posixmodule.c, it calls abort(), which is a standard C function,
equivalent to killing the
On Wed, Jun 29, 2016 at 11:12 PM, Steven D'Aprano wrote:
> On Thu, 30 Jun 2016 11:28 am, Chris Angelico wrote:
>
>> On Thu, Jun 30, 2016 at 10:27 AM, Steven D'Aprano
>> wrote:
>>> Following os.abort(), the interpreter exits in the hardest, quickest
>>>
On Thu, Jun 30, 2016 at 2:12 PM, Steven D'Aprano wrote:
> On Thu, 30 Jun 2016 11:28 am, Chris Angelico wrote:
>
>> On Thu, Jun 30, 2016 at 10:27 AM, Steven D'Aprano
>> wrote:
>>> Following os.abort(), the interpreter exits in the hardest, quickest
>>>
On Thu, 30 Jun 2016 11:28 am, Chris Angelico wrote:
> On Thu, Jun 30, 2016 at 10:27 AM, Steven D'Aprano
> wrote:
>> Following os.abort(), the interpreter exits in the hardest, quickest
>> manner possible.
>
> os.kill(os.getpid(), 9)
>
> Now THAT is the hardest way to
On Wed, Jun 29, 2016, at 22:26, Rustom Mody wrote:
> > os.kill(os.getpid(), 9)
> >
> > Now THAT is the hardest way to abort. You ain't comin' back from
> > this one!
>
> Is it?
>
> | On Windows, signal() can only be called with SIGABRT, SIGFPE,
> | SIGILL, SIGINT, SIGSEGV, or SIGTERM. A ValueError
On Thursday, June 30, 2016 at 6:58:42 AM UTC+5:30, Chris Angelico wrote:
> On Thu, Jun 30, 2016 at 10:27 AM, Steven D'Aprano wrote:
> > Following os.abort(), the interpreter exits in the hardest, quickest manner
> > possible.
>
> os.kill(os.getpid(), 9)
>
> Now THAT is the hardest way to abort.
On Thu, Jun 30, 2016 at 10:27 AM, Steven D'Aprano wrote:
> Following os.abort(), the interpreter exits in the hardest, quickest manner
> possible.
os.kill(os.getpid(), 9)
Now THAT is the hardest way to abort. You ain't comin' back from this one!
ChrisA
--
On Wed, 29 Jun 2016 08:01 pm, Victor Savu wrote:
> There are many posts trying to explain the else after for or while. Here
> is my take on it:
>
> There are three ways of getting out of a (for/while) loop: throw, break or
> the iterator gets exhausted.
- reaching the end of the loop
- raise
On 6/29/2016 6:01 AM, Victor Savu wrote:
There are many posts trying to explain the else after for or while.
My take: a while statement *is* a repeated if statement, and that is how
it is implemented.
while condition:
true()
is equivalent to and implemented in machine language without
On 2016-06-29, Steven D'Aprano wrote:
[...]
> is "insane" too, but still legal. The Python interpreter does not
> judge your code.
That's what Usenet is for.
--
Grant Edwards grant.b.edwardsYow! I'm a nuclear
at
Steven D'Aprano at 2016/6/29 UTC+8 10:43:52AM wrote:
> The "else" in for...else has nothing to do with any "if" inside the for
> block.
Yes, the "else" has nothing to do with "break" syntactically in Python
language, but semantically in English it cause confusion. When I said "insane",
I just
There are many posts trying to explain the else after for or while. Here is
my take on it:
There are three ways of getting out of a (for/while) loop: throw, break or
the iterator gets exhausted. The question is, how cab we tell which way we
exited? For the throw, we have the except clause. This
On Wed, 29 Jun 2016 11:41 am, jf...@ms4.hinet.net wrote:
> Anyone who wrote the code below must be insane:-)
>
> for x in range(3):
> print(x)
> else:
> print('I am done')
*shrug* Insane or not, it's legal.
import math
pass
import os
pass
import sys
is "insane" too,
Anyone who wrote the code below must be insane:-)
for x in range(3):
print(x)
else:
print('I am done')
But here it seems perfectly OK:
for x in range(3):
print(x)
if x == 1: break
else:
print('I am done')
To me, the "else" was bonded
14 matches
Mail list logo