gmane.comp.python.tutor

Re: keyboard interrupt

Jim Mooney — 2013-05-22T20:30:29

Figured it out. Ctrl-C only works in the Windows Command window, not
in an editor.

Jim

Re: try..except - what about that ton of **Error statements?

Dave Angel — 2013-05-22T20:31:50

I had a young lady working for me that was writing a printer driver, the 
kind that these days would be embedded inside the printer.  I believe it 
was a daisy-wheel printer.  It used a stepper motor which was stepped up 
gradually from zero to full speed and back again.  Anyway, she put a 
breakpoint in the code at the point where the carriage was ramped up, 
and the code stopped, but the carriage kept going, It almost made it 
through the outer wall of the printer - totalled.

Re: keyboard interrupt

Jim Mooney — 2013-05-22T20:24:02

Actually, I did, using Win 7 - and I put exit() in place of pass. I
tried ctrl-c, ctrl-x, esc, and del. Windows doesn't seem to respond to
anything. The prog just goes to the end

Jim
_______________________________________________
Tutor maillist  -  Tutor< at >python.org
To unsubscribe or change subscription options:
http://mail.python.org/mailman/listinfo/tutor

Re: keyboard interrupt

Jerry Hill — 2013-05-22T20:11:01

The KeyboardInterrupt exception is raised when someone presses Ctrl-C.  If
you catch it, and ignore it (which is what your code above is doing), then
pressing Ctrl-C doesn't do anything.  If you just take out the try/except,
then you can hit Ctrl-C and interrupt your program as normal.

Re: keyboard interrupt

Marc Tompkins — 2013-05-22T20:10:28

I've not used it myself, but I believe the KeyboadInterrupt is only
generated by one _specific_ keypress.  You mentioned that you pressed a key
- did you try Control-C?

http://effbot.org/zone/stupid-exceptions-keyboardinterrupt.htm
_______________________________________________
Tutor maillist  -  Tutor< at >python.org
To unsubscribe or change subscription options:
http://mail.python.org/mailman/listinfo/tutor

keyboard interrupt

Jim Mooney — 2013-05-22T19:47:17

I made a simple ear frequency-tester, but I don't want it to go on
forever, so I tried stopping it when I  pressed a key, as below, but
that doesn't work. I did check out keyboard interrupts but they seem
unnecessarily complex just to stop a program. I'm not passing keys. Is
there something simple I'm missing?

import winsound

try:
    for freq in range(100,32000,100):
        winsound.Beep(freq, 1000)
except KeyboardInterrupt:
    pass

Re: Fwd: Available characters

Jim Mooney — 2013-05-22T19:29:28

That was really useful for another reason. After I checked and saw it
was in DLLs, I investigated the other Python DLLs  - which had
heretofore seemed mysterious - and found winsound. I happen to be
interested in frequency generation.

Jim
_______________________________________________
Tutor maillist  -  Tutor< at >python.org
To unsubscribe or change subscription options:
http://mail.python.org/mailman/listinfo/tutor

Fwd: Available characters

Citizen Kant — 2013-05-22T19:12:35

The unicodedata module provides access to the Unicode database that Python
uses:

http://docs.python.org/2/library/unicodedata#unicodedata.unidata_version

Here are the versions of the database for Python 2.6.8, 2.7.3, 3.2.3, and
3.3.1:

    >>> unicodedata.unidata_version # 2.6.8
    '5.1.0'
    >>> unicodedata.unidata_version # 2.7.3
    '5.2.0'
    >>> unicodedata.unidata_version # 3.2.3
    '6.0.0'
    >>> unicodedata.unidata_version # 3.3.1
    '6.1.0'


Thanks! This is perfect.
_______________________________________________
Tutor maillist  -  Tutor< at >python.org
To unsubscribe or change subscription options:
http://mail.python.org/mailman/listinfo/tutor

Re: try..except - what about that ton of **Error statements?

Albert-Jan Roskam — 2013-05-22T19:03:14



There used to be a program that would let your harddisk "sing" a melody by letting it frantically spin. I always thought this was *not* a good idea, though I have never heard of accidents with it. ;-)

_______________________________________________
Tutor maillist  -  Tutor< at >python.org
To unsubscribe or change subscription options:
http://mail.python.org/mailman/listinfo/tutor

Re: Available characters

eryksun — 2013-05-22T18:26:18

The unicodedata module provides access to the Unicode database that Python uses:

http://docs.python.org/2/library/unicodedata#unicodedata.unidata_version

Here are the versions of the database for Python 2.6.8, 2.7.3, 3.2.3, and 3.3.1:

    >>> unicodedata.unidata_version # 2.6.8
    '5.1.0'
    >>> unicodedata.unidata_version # 2.7.3
    '5.2.0'
    >>> unicodedata.unidata_version # 3.2.3
    '6.0.0'
    >>> unicodedata.unidata_version # 3.3.1
    '6.1.0'
_______________________________________________
Tutor maillist  -  Tutor< at >python.org
To unsubscribe or change subscription options:
http://mail.python.org/mailman/listinfo/tutor

Available characters

Citizen Kant — 2013-05-22T18:14:55

Does anybody know if there's a Python method that gives or stores the
complete list of ascii characters or unicode characters? The list of every
single character available would be perfect.

Thanks.
_______________________________________________
Tutor maillist  -  Tutor< at >python.org
To unsubscribe or change subscription options:
http://mail.python.org/mailman/listinfo/tutor

Re: try..except - what about that ton of **Error statements?

Marc Tompkins — 2013-05-22T17:23:11


I agree with you a LOT more strongly in the case of compiled languages,
where the error dump amounts to a memory location and a blob of
hexadecimal.  When that happens, nobody but the original programmer (or
software company) is likely to find out the cause, and even then not
without a symbolic debugger.  But in Python, the error messages/tracebacks
are fairly self-explanatory (to someone familiar with Python) and even
include the actual line number where the error occurred.  It's true that
the average end-user won't be able to fix it, but the pool of potential
help is actually quite wide.
_______________________________________________
Tutor maillist  -  Tutor< at >python.org
To unsubscribe or change subscription options:
http://mail.python.org/mailman/listinfo/tutor

Re: try..except - what about that ton of **Error statements?

Steven D'Aprano — 2013-05-22T17:20:19


Does your computer have a DVD drive? Or Blu-Ray? Is it region-locked? Some region-locked drives let you change the region up to a maximum of (say) 3 times. A malicious or unlucky program may "accidentally" change the region 3 times, then you are locked for good. If you're locked in the wrong region, the drive might as well be dead.

Some DVD burners are capable of operating at speeds faster than low-quality discs can stand. DVDs have been known to shatter inside the drive, destroying both the disk and the drive. If a program runs the DVD at excessively high speed, not only do the mechanical parts wear faster, but cheap disks could shatter.

(I never shattered a DVD or CD, but I went through about 50 blank CDs, back when they were about two dollars each, making "coasters" from them because I was trying to burn data to them faster than the disc was capable of dealing with. I will never forgot the moment I realised why four out of five of my burns were failing: it was when I reached for the SECOND LAST DISC i

Re: try..except - what about that ton of **Error statements?

boB Stepp — 2013-05-22T16:50:34

[...]


Would you define "exiting gracefully"? It appears you mean a
controlled (by the programmer's code) exit that gives a meaningful (to
the user or the programmer?) error message instead of in an
uncontrolled manner where the only available information would be
whatever the OS generates.


Thanks for the example! Unfortunately these devastating errors
continue. The New York Times has reported on some radiation therapy
incidents in the past few years, some of which were caused by
programming errors (along with the usual errors by the people using
the software).


I like very much how you put this. Integrity in programming!


I guess I'll pick the first alternative. However, this brings to mind
my biggest gripe as a user of software, particularly here at work
where the programmer obviously has no medical background: cryptic
error messages that might be meaningful to the programmer, but are
totally unhelpful to me, the user, who has to figure out what to do
next.

[...]

Thanks for the clarifications!

boB

Re: Tutor Digest, Vol 111, Issue 72

eryksun — 2013-05-22T16:45:32

You can configure Gmail to default to reply all in the general
settings. Of course that's of no use if you're replying to a digest,
so switch to receiving individual messages. Receiving the list as a
digest is unnecessary with Gmail. Just create a label for the list,
and use a filter to automatically label and archive messages from the
list out of your inbox.
_______________________________________________
Tutor maillist  -  Tutor< at >python.org
To unsubscribe or change subscription options:
http://mail.python.org/mailman/listinfo/tutor

To error statement or not to error statement

Jim Mooney — 2013-05-22T16:27:59

Then am I right to assume that rather than put in error statements I
barely understand at this point, the best thing would be to work the
hell out of the program in hope of seeing an error?  Does Python have
something that would do this automatically since I can't see running a
program a hundred times by hand?

Mainly, I'm just learning all this stuff for future reference. I
really doubt I'll need to use nose to find errors in twenty-line
programs. Print, assert, and staring at it for a long time should be
enough for now - and the Wing debugger now and then.

From the varied replies so far, it sounds to me that debugging is more
of an art than a science. So far the books I've looked at just mention
the basics but don't get into the philosophy of when and how.

Jim
_______________________________________________
Tutor maillist  -  Tutor< at >python.org
To unsubscribe or change subscription options:
http://mail.python.org/mailman/listinfo/tutor

Re: Tutor Digest, Vol 111, Issue 72

Steven D'Aprano — 2013-05-22T16:24:52


If you look at your subscription options:

http://mail.python.org/mailman/listinfo/tutor


you have an option to receive a digest containing many posts in a single email, or to receive individual emails. If you are going to reply to messages, please pick individual emails. Then when you wish to respond to one email, you hit "Reply To List" (if your email program has that option) or "Reply All" (if it doesn't), edit your reply, and send.

If you are planning to be busy or away, and still wish to receive the emails, but not reply to them, some people like to go onto digest mode. I've tried that, and would not bother.

Re: Tutor Digest, Vol 111, Issue 72

Jim Mooney — 2013-05-22T16:13:51

So is Reply to All the way to go? For some odd reason Gmail won't
always Reply to All. I'll have to figure out why.

Jim
_______________________________________________
Tutor maillist  -  Tutor< at >python.org
To unsubscribe or change subscription options:
http://mail.python.org/mailman/listinfo/tutor

Re: challenge-chapter 2

Evans Anyokwu — 2013-05-22T16:11:06

Hi Andrew,

I'm sure the exercises at the end of the each chapters are there for you to
attempt. Asking for help here without attempting it is not the best way to
learn.
If however, you've tried something - and it didn't work, by all means ask
for help.

In the mean time show us what you have so far.


Good luck,
Evans


On Wed, May 22, 2013 at 6:02 AM, Andrew Triplett <andrew139668< at >yahoo.com>wrote:

_______________________________________________
Tutor maillist  -  Tutor< at >python.org
To unsubscribe or change subscription options:
http://mail.python.org/mailman/listinfo/tutor

Re: try..except - what about that ton of **Error statements?

boB Stepp — 2013-05-22T16:09:14

Thanks, Steve, for your last two posts. You have made things much
clearer for me.

On Wed, May 22, 2013 at 9:49 AM, Steven D'Aprano <steve< at >pearwood.info> wrote:

[...]


I was not aware that hardware damage could be caused by poor
programming. I am curious; can you give some examples of how this
might occur?

I would like to ask some general questions here. Problems can arise
from bugs in the operating system, bugs in the programming language(s)
being used, bugs in packages/modules being used, bugs in any third
party packages being used, etc. Also, whenever any one of these things
is updated/upgraded, it can introduce new issues. What strategies can
one use to deal with these possibilities that seem entirely out of the
programmer's control?

boB
_______________________________________________
Tutor maillist  -  Tutor< at >python.org
To unsubscribe or change subscription options:
http://mail.python.org/mailman/listinfo/tutor

Re: try..except - what about that ton of **Error statements?

Steven D'Aprano — 2013-05-22T14:49:32


Yes!


Well, within reason. If you are programming in C, a crash can be a nasty thing to deal with. It could cause memory corruption, leading to a Blue Screen of Death or equivalent. In the absolute worst case, low-level C or assembly bugs can actually cause hardware damage! So you don't want to be writing low-level code like that if you can avoid it.

But in a high-level language like Python, exceptions are not to be feared. They are perfectly safe, and should be welcomed, since they show you where your code needs to be improved.