Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.python > #57091 > unrolled thread

Error Testing

Back to article view | Back to comp.lang.python

Contents

  Error Testing Scott Novinger <scnovinger@gmail.com> - 2013-10-19 05:23 -0700
    Re: Error Testing Mark Lawrence <breamoreboy@yahoo.co.uk> - 2013-10-19 13:37 +0100
      Re: Error Testing Scott Novinger <scnovinger@gmail.com> - 2013-10-19 06:34 -0700
        Re: Error Testing Chris Angelico <rosuav@gmail.com> - 2013-10-20 00:42 +1100
        Re: Error Testing rusi <rustompmody@gmail.com> - 2013-10-19 09:22 -0700
          Re: Error Testing Chris Angelico <rosuav@gmail.com> - 2013-10-20 09:28 +1100
          Re: Error Testing Ned Deily <nad@acm.org> - 2013-10-19 15:46 -0700
          Re: Error Testing Chris Angelico <rosuav@gmail.com> - 2013-10-20 10:02 +1100
          Re: Error Testing Dennis Lee Bieber <wlfraed@ix.netcom.com> - 2013-10-20 12:18 -0400
    Re: Error Testing Ned Batchelder <ned@nedbatchelder.com> - 2013-10-19 08:44 -0400
      Re: Error Testing Roy Smith <roy@panix.com> - 2013-10-19 08:57 -0400
        Re: Error Testing Chris Angelico <rosuav@gmail.com> - 2013-10-20 00:04 +1100
        Re: Error Testing Ned Batchelder <ned@nedbatchelder.com> - 2013-10-19 09:07 -0400
          Re: Error Testing Roy Smith <roy@panix.com> - 2013-10-19 09:09 -0400
        Re: Error Testing Mark Lawrence <breamoreboy@yahoo.co.uk> - 2013-10-19 14:19 +0100
    Re: Error Testing Chris Angelico <rosuav@gmail.com> - 2013-10-20 00:01 +1100
    Re: Error Testing David Robinow <drobinow@gmail.com> - 2013-10-19 14:08 -0400
    Re: Error Testing Tim Chase <tim@thechases.com> - 2013-10-19 13:31 -0500
    Re: Error Testing Terry Reedy <tjreedy@udel.edu> - 2013-10-19 15:50 -0400
    What's wrong with Windows Command Prompt (was Re: Error Testing) Terry Reedy <tjreedy@udel.edu> - 2013-10-19 16:35 -0400
    Re: What's wrong with Windows Command Prompt (was Re: Error Testing) Chris Angelico <rosuav@gmail.com> - 2013-10-20 09:15 +1100
    Re: Error Testing Chris Angelico <rosuav@gmail.com> - 2013-10-20 09:20 +1100
    Re: What's wrong with Windows Command Prompt (was Re: Error Testing) David Robinow <drobinow@gmail.com> - 2013-10-21 15:55 -0400
    Re: What's wrong with Windows Command Prompt (was Re: Error Testing) Tim Chase <python.list@tim.thechases.com> - 2013-10-21 15:29 -0500

Page 1 of 2  [1] 2  Next page →

#57091 — Error Testing

Hello.

I've written a program for my kids to calculate arc length.  I want to include some error testing for value types entered that are something other than integer values.

My goal is to make sure that the value entered for the radius is an integer value.

How could I rewrite this code to make sure I accomplish my goal of getting an integer value entered?  I know the construct is not correct.  I'm just learning how to program.

    # Create the variable for radius, "radius".
    print('Please enter the circle radius and press ENTER:')
    radius = input()

    # Check to make sure the entered value is an integer.
    if type(radius) != type(int):
        print('You must enter an integer value.')
        print('Please enter the circle radius and press ENTER:')
        radius = input()
    else:
        print('The radius you entered is: ' + radius)
    
    radius = int(radius)

Thanks for your help. I'm using Python v3.2 for windows.

Scott

[toc] | [next] | [standalone]

#57093

On 19/10/2013 13:23, Scott Novinger wrote:
> Hello.
>
> I've written a program for my kids to calculate arc length.  I want to include some error testing for value types entered that are something other than integer values.
>
> My goal is to make sure that the value entered for the radius is an integer value.
>
> How could I rewrite this code to make sure I accomplish my goal of getting an integer value entered?  I know the construct is not correct.  I'm just learning how to program.
>
>      # Create the variable for radius, "radius".
>      print('Please enter the circle radius and press ENTER:')
>      radius = input()
>
>      # Check to make sure the entered value is an integer.
>      if type(radius) != type(int):
>          print('You must enter an integer value.')
>          print('Please enter the circle radius and press ENTER:')
>          radius = input()
>      else:
>          print('The radius you entered is: ' + radius)
>
>      radius = int(radius)
>
> Thanks for your help. I'm using Python v3.2 for windows.
>
> Scott
>

Please see the example here 
http://docs.python.org/3/tutorial/errors.html#handling-exceptions.  If 
you want further data feel free to ask, we don't bite :)

-- 
Roses are red,
Violets are blue,
Most poems rhyme,
But this one doesn't.

Mark Lawrence

[toc] | [prev] | [next] | [standalone]

#57102

On Saturday, October 19, 2013 8:37:01 AM UTC-4, Mark Lawrence wrote:
> On 19/10/2013 13:23, Scott Novinger wrote:
> 
> > Hello.
> 
> >
> 
> > I've written a program for my kids to calculate arc length.  I want to include some error testing for value types entered that are something other than integer values.
> 
> >
> 
> > My goal is to make sure that the value entered for the radius is an integer value.
> 
> >
> 
> > How could I rewrite this code to make sure I accomplish my goal of getting an integer value entered?  I know the construct is not correct.  I'm just learning how to program.
> 
> >
> 
> >      # Create the variable for radius, "radius".
> 
> >      print('Please enter the circle radius and press ENTER:')
> 
> >      radius = input()
> 
> >
> 
> >      # Check to make sure the entered value is an integer.
> 
> >      if type(radius) != type(int):
> 
> >          print('You must enter an integer value.')
> 
> >          print('Please enter the circle radius and press ENTER:')
> 
> >          radius = input()
> 
> >      else:
> 
> >          print('The radius you entered is: ' + radius)
> 
> >
> 
> >      radius = int(radius)
> 
> >
> 
> > Thanks for your help. I'm using Python v3.2 for windows.
> 
> >
> 
> > Scott
> 
> >
> 
> 
> 
> Please see the example here 
> 
> http://docs.python.org/3/tutorial/errors.html#handling-exceptions.  If 
> 
> you want further data feel free to ask, we don't bite :)
> 
> 
> 
> -- 
> 
> Roses are red,
> 
> Violets are blue,
> 
> Most poems rhyme,
> 
> But this one doesn't.
> 
> 
> 
> Mark Lawrence

Mark/ All,

I read the link on Handling Exceptions.  The first bit of code worked for my purposes. I was able to reduce my number of lines of code significantly and my program works! Thank you all for your help solving this problem!

My plan is to create several different programs that perform specific Algebraic operations.  My boys are learning Algebra 2 and I thought it might be a fun way to help us all learn Algebra and programming together.  Python seems to be a good language for learning how to program.

Thanks again!

Scott

[toc] | [prev] | [next] | [standalone]

#57103

On Sun, Oct 20, 2013 at 12:34 AM, Scott Novinger <scnovinger@gmail.com> wrote:
> I read the link on Handling Exceptions.  The first bit of code worked for my purposes. I was able to reduce my number of lines of code significantly and my program works! Thank you all for your help solving this problem!

As you get accustomed to exception handling, you'll find that it's a
really clean and easy way to... well, handle exceptional situations :)
Tip: In quick throw-away scripts that are run from the command line,
don't even bother catching most exceptions. Just let 'em happen if
they want to happen... your script will terminate with an error
message, and you can deal with it as a human. That saves you even more
code!

> My plan is to create several different programs that perform specific Algebraic operations.  My boys are learning Algebra 2 and I thought it might be a fun way to help us all learn Algebra and programming together.  Python seems to be a good language for learning how to program.

It is an excellent language for that. It's also a great language for
applications. It may not be the fastest in the world, but all
computers wait at the same speed anyway...

Just one thing: When you post here, please either don't use Google
Groups, or follow the advice here:

https://wiki.python.org/moin/GoogleGroupsPython

Preferably, just avoid GG, as a number of people just filter those
posts out. It's not an indictment of you as a person, but the majority
of GG posts are, quite frankly, very annoying for the reasons set out
in the wiki article.

Hope to see you around more!

ChrisA

[toc] | [prev] | [next] | [standalone]

#57110

On Saturday, October 19, 2013 7:04:30 PM UTC+5:30, Scott Novinger wrote:
> 
> My plan is to create several different programs that perform specific Algebraic 
> operations.  My boys are learning Algebra 2 and I thought it might be a fun way 
> to help us all learn Algebra and programming together.  Python seems to be a 
> good language for learning how to program.

If you are a programmer and want to start doing some 'real' math stuff, your approach is fine.

Conversely if you are a mathematician (or at least someone whose math fundamentals are well established) then too to start by getting your hands dirty with coding up some paper-pen/chalk-blackboard math into a system is a good goal and python is as good a language for this as any.

The system sage http://www.sagemath.org/ does some serious math with python as glue.

However if your boys are new to both math and programming, you are doing them a disservice by mixing the two using python.

The problem is that python is an imperative language and uses the '=' sign for assignment.  In math of course '=' stands for equality.

Now these two usages of '=' are both center-stage and completely different:
- the math = is by definition symmetric -- we can replace x=y by y=x. Whereas in programming we can never replace x=1 by 1=x
- More significantly and dangerously the programming var=rhs has a timing element and in fact introduces a basic notion of a 'unit of computation', --the statement -- a notion completely absent from the math something=somethingElse

Now one word or signifier meaning different things -- a pun -- is not necessarily bad. To the extent that we humans have more entities to deal with than ready words its even inevitable.  Just yesterday there was a discussion about whether 'python' is a TV comic character or a snake, pike a fish or a poker.  I think these are relatively harmless.

However with '=' in math and programming, the two are too different to be equated(!!) and too close to be separated.
Because after the programming statement var = lhs
the math predicate var = lhs is typically true.

But then what happens with something like this?  x = x+1
For a programmer this is common daily fare.
For a mathematician its an impossibility.

So I suggest you try it (x=x+1) on your boys.
If they think its ok, youve damaged their mathematical acumen
If not, they've yet to begin programming.
If they can answer to the effect that in some contexts its natural and in some not then of course they are very mature and/or geniuses.

I should mention that John Backus, the creator of the first hi-level language and a Turing award winner, more or less said that the assignment is the single biggest problem why programming languages are in such a mess:
http://www.thocp.net/biographies/papers/backus_turingaward_lecture.pdf

Having said that, I also need to say that most programmers dont agree with that.
The minority that do, would earlier be called 'declarative-devotees'; nowadays the fashionable term is functional programming.
My own rather fringe minority position is that Backus et al are right in denouncing the assignment. However so far the attempts at practically  realizing this smack of throwing out the baby with the bathwater.

So for the time being, languages like python remain eminently practical.
Its just that they are not so good for building kids' theoretical foundations -- especially of a mathematical sort.

[toc] | [prev] | [next] | [standalone]

#57124

On Sun, Oct 20, 2013 at 3:22 AM, rusi <rustompmody@gmail.com> wrote:
> The problem is that python is an imperative language and uses the '=' sign for assignment.  In math of course '=' stands for equality.

Pascal tried to create a new operator, := to be read "becomes", to
deal with the whole equality-vs-assignment issue. Did it really help
anything? I don't think so. Just syntactic salt. Even the comparison
isn't really mathematical - in maths, "x = y" is a statement of truth,
whereas in programming, it's a question ("is x equal to y").

Teaching maths and programming at once is like teaching any other two
arts at once - there'll be differences to grok as well as similarities
to jump on. I would say that the expression evaluator in (almost) any
modern language is a fairly close parallel to standard mathematical
expressions; yes, abutting tokens is multiplication in algebra, but on
the flip side, we don't use (or need) subscript to make multi-letter
identifiers in code. Programming uses more words and less blackboard
notations (compare abs(x) to |x| for example), but it's expressing
things in fairly similar ways most of the time.

ChrisA

[toc] | [prev] | [next] | [standalone]

#57128

In article 
<CAPTjJmqRRxSx0rhU0bShQHBAwYm6_NWb6eX3hKetjwMDADQQxg@mail.gmail.com>,
 Chris Angelico <rosuav@gmail.com> wrote:
> Pascal tried to create a new operator, := to be read "becomes", to
> deal with the whole equality-vs-assignment issue.

Um, Pascal was just following the lead of ALGOL 60, roughly a decade earlier.

-- 
 Ned Deily,
 nad@acm.org

[toc] | [prev] | [next] | [standalone]

#57130

On Sun, Oct 20, 2013 at 9:46 AM, Ned Deily <nad@acm.org> wrote:
> In article
> <CAPTjJmqRRxSx0rhU0bShQHBAwYm6_NWb6eX3hKetjwMDADQQxg@mail.gmail.com>,
>  Chris Angelico <rosuav@gmail.com> wrote:
>> Pascal tried to create a new operator, := to be read "becomes", to
>> deal with the whole equality-vs-assignment issue.
>
> Um, Pascal was just following the lead of ALGOL 60, roughly a decade earlier.

Sorry, the word "create" was poorly chosen. Would "deploy" be better?
I'm aware there's a family; what I'm trying to say is that, in Pascal
(I prefer to use a better-known language for discussion, where
possible), there's a new operator instead of =.

Anyway, my point is that it doesn't really help much. Imperative code
is temporal (maybe functional or declarative code could be closer to
maths, but we're talking Python here, which is imperative), where
mathematical truth is timeless. If a² + b² = c² now, then it still
will be true tomorrow. In programming, that's far from guaranteed
(though compilers will often optimize if they know there's a section
of code where the three won't change). You have to get your head
around that, whether you're doing assignment or comparison, and using
a different symbol to represent them is doing yourself as much of a
disservice as avoiding + for addition of floats to emphasize that they
don't always work like real numbers.

ChrisA

[toc] | [prev] | [next] | [standalone]

#57151

On Sun, 20 Oct 2013 10:02:23 +1100, Chris Angelico <rosuav@gmail.com>
declaimed the following:

>On Sun, Oct 20, 2013 at 9:46 AM, Ned Deily <nad@acm.org> wrote:
>> In article
>> <CAPTjJmqRRxSx0rhU0bShQHBAwYm6_NWb6eX3hKetjwMDADQQxg@mail.gmail.com>,
>>  Chris Angelico <rosuav@gmail.com> wrote:
>>> Pascal tried to create a new operator, := to be read "becomes", to
>>> deal with the whole equality-vs-assignment issue.
>>
>> Um, Pascal was just following the lead of ALGOL 60, roughly a decade earlier.
>
>Sorry, the word "create" was poorly chosen. Would "deploy" be better?
>I'm aware there's a family; what I'm trying to say is that, in Pascal
>(I prefer to use a better-known language for discussion, where
>possible), there's a new operator instead of =.
>

	The point is that Algol-60 already used ":=" for that operation. It was
not new with Pascal. (Actually, Algol-58 [IAL] introduced the := )(And if
one trusts Wikipedia, the \ was added to ASCII to support some Algol
operators).


-- 
	Wulfraed                 Dennis Lee Bieber         AF6VN
    wlfraed@ix.netcom.com    HTTP://wlfraed.home.netcom.com/

[toc] | [prev] | [next] | [standalone]

#57094

On 10/19/13 8:23 AM, Scott Novinger wrote:
> Hello.
>
> I've written a program for my kids to calculate arc length.  I want to include some error testing for value types entered that are something other than integer values.
>
> My goal is to make sure that the value entered for the radius is an integer value.
>
> How could I rewrite this code to make sure I accomplish my goal of getting an integer value entered?  I know the construct is not correct.  I'm just learning how to program.
>
>      # Create the variable for radius, "radius".
>      print('Please enter the circle radius and press ENTER:')
>      radius = input()
>
>      # Check to make sure the entered value is an integer.
>      if type(radius) != type(int):
>          print('You must enter an integer value.')
>          print('Please enter the circle radius and press ENTER:')
>          radius = input()
>      else:
>          print('The radius you entered is: ' + radius)
>      
>      radius = int(radius)
>
> Thanks for your help. I'm using Python v3.2 for windows.
>
> Scott
Hi Scott, welcome!

This line doesn't do what you want:

     if type(radius) != type(int):

for a few reasons:  First, radius is the result of input(), so it is 
always a string, never an int.  Second, "int" itself is already a type, 
so type(int) is actually "class" (or something like it), not "int".

What you want is to know whether the string inputted can be properly 
converted to an int.  In Python, the way to do that is to try converting 
it, and be prepared for it to fail:

     try:
         radius = int(radius)
     except ValueError:
         print('You must enter an integer value.')

--Ned.

[toc] | [prev] | [next] | [standalone]

#57096

On 10/19/13 8:23 AM, Scott Novinger wrote:
> > My goal is to make sure that the value entered for the radius is an integer 
> > value.

In article <mailman.1254.1382186691.18130.python-list@python.org>,
 Ned Batchelder <ned@nedbatchelder.com> wrote:

> First, radius is the result of input(), so it is 
> always a string, never an int.

input() returns ints or floats for values which can be converted to 
those.  I suspect you're thinking of raw_input()?

[toc] | [prev] | [next] | [standalone]

#57098

On Sat, Oct 19, 2013 at 11:57 PM, Roy Smith <roy@panix.com> wrote:
> On 10/19/13 8:23 AM, Scott Novinger wrote:
>> > My goal is to make sure that the value entered for the radius is an integer
>> > value.
>
> In article <mailman.1254.1382186691.18130.python-list@python.org>,
>  Ned Batchelder <ned@nedbatchelder.com> wrote:
>
>> First, radius is the result of input(), so it is
>> always a string, never an int.
>
> input() returns ints or floats for values which can be converted to
> those.  I suspect you're thinking of raw_input()?

Negative. The OP stated Python 3.2, in which Ned's statement is
correct. :) In Python 2.x, yes, input() will return an int if it
evaluates as one, but in 2.x, I would STRONGLY advise against ever
using non-raw input(). (To be honest, I'd have to say that the
innocuous name 'input' concealing code evaluation is an embarrassment,
and one that I'm very much glad is now removed from the language.)

ChrisA

[toc] | [prev] | [next] | [standalone]

#57099

On 10/19/13 8:57 AM, Roy Smith wrote:
> On 10/19/13 8:23 AM, Scott Novinger wrote:
>>> My goal is to make sure that the value entered for the radius is an integer
>>> value.
> In article <mailman.1254.1382186691.18130.python-list@python.org>,
>   Ned Batchelder <ned@nedbatchelder.com> wrote:
>
>> First, radius is the result of input(), so it is
>> always a string, never an int.
> input() returns ints or floats for values which can be converted to
> those.  I suspect you're thinking of raw_input()?
In Python 3, input() returns a string.

--Ned.

[toc] | [prev] | [next] | [standalone]

#57100

In article <mailman.1257.1382188058.18130.python-list@python.org>,
 Ned Batchelder <ned@nedbatchelder.com> wrote:

> On 10/19/13 8:57 AM, Roy Smith wrote:
> > On 10/19/13 8:23 AM, Scott Novinger wrote:
> >>> My goal is to make sure that the value entered for the radius is an 
> >>> integer
> >>> value.
> > In article <mailman.1254.1382186691.18130.python-list@python.org>,
> >   Ned Batchelder <ned@nedbatchelder.com> wrote:
> >
> >> First, radius is the result of input(), so it is
> >> always a string, never an int.
> > input() returns ints or floats for values which can be converted to
> > those.  I suspect you're thinking of raw_input()?
> In Python 3, input() returns a string.
> 
> --Ned.

Duh.  My bad.

[toc] | [prev] | [next] | [standalone]

#57101

On 19/10/2013 13:57, Roy Smith wrote:
> On 10/19/13 8:23 AM, Scott Novinger wrote:
>>> My goal is to make sure that the value entered for the radius is an integer
>>> value.
>
> In article <mailman.1254.1382186691.18130.python-list@python.org>,
>   Ned Batchelder <ned@nedbatchelder.com> wrote:
>
>> First, radius is the result of input(), so it is
>> always a string, never an int.
>
> input() returns ints or floats for values which can be converted to
> those.  I suspect you're thinking of raw_input()?
>

Really, not what it says here 
http://docs.python.org/3/library/functions.html#input and shown by the 
following?

In [5]: a=input()
12345

In [6]: a
Out[6]: '12345'

In [7]: type(a)
Out[7]: builtins.str

-- 
Roses are red,
Violets are blue,
Most poems rhyme,
But this one doesn't.

Mark Lawrence

[toc] | [prev] | [next] | [standalone]

#57097

On Sat, Oct 19, 2013 at 11:23 PM, Scott Novinger <scnovinger@gmail.com> wrote:
>     # Create the variable for radius, "radius".
>     print('Please enter the circle radius and press ENTER:')
>     radius = input()
>
>     # Check to make sure the entered value is an integer.
>     if type(radius) != type(int):
>         print('You must enter an integer value.')
>         print('Please enter the circle radius and press ENTER:')
>         radius = input()
>     else:
>         print('The radius you entered is: ' + radius)
>
>     radius = int(radius)
>
> Thanks for your help. I'm using Python v3.2 for windows.

In Python 3, the input() function always returns a string. Your type
check is never going to succeed. Also, you're not checking what you
think you're checking; you're actually looking to see if input()
returned a type, because the type of int is type:

>>> type(int)
<class 'type'>

You might want:

if type(radius) != int:

But that still won't work, because input() will always return a string:

>>> radius = input()
42
>>> type(radius)
<class 'str'>

You can try all these out in the interactive interpreter (you probably
have IDLE installed, which on Windows is rather nicer to work with
than the default interactive mode).

A better check would be to just try to turn the inputted value into an
integer, and fail if that doesn't work. Again, try this interactively:

>>> int("42")
42
>>> int("not an integer")
Traceback (most recent call last):
  File "<pyshell#58>", line 1, in <module>
    int("not an integer")
ValueError: invalid literal for int() with base 10: 'not an integer'

With a couple of quick checks, you can easily see what happens if the
conversion fails, and then you can deal with that failure. So
effectively, just drop the whole if: block, go straight to the "radius
= int(radius)" line, and deal with the error there.

ChrisA

[toc] | [prev] | [next] | [standalone]

#57112

On Sat, Oct 19, 2013 at 9:01 AM, Chris Angelico <rosuav@gmail.com> wrote:

> You can try all these out in the interactive interpreter (you probably
> have IDLE installed, which on Windows is rather nicer to work with
> than the default interactive mode).
 IDLE is cross-platform.  Could you explain why you say "on Windows"?

[toc] | [prev] | [next] | [standalone]

#57113

On 2013-10-19 14:08, David Robinow wrote:
> On Sat, Oct 19, 2013 at 9:01 AM, Chris Angelico wrote:
>> You can try all these out in the interactive interpreter (you
>> probably have IDLE installed, which on Windows is rather nicer to
>> work with than the default interactive mode).  
>
>  IDLE is cross-platform.  Could you explain why you say "on
> Windows"?

In my experience, the Win32 Python console lacks readline support
(like my stock Python on the Mac OS X machine I have here), and as
such lacks a lot of the niceties.  At least on Win32, there is
recall of previous commands (my Mac lacks even that), but there's no
easy "search for the previous command I typed that contains the
following keyword" (control-R followed by search term), no easy
"insert all matching filenames here" (alt+asterisk), etc.

Idle may not provide all that, but it hopefully provides at least
*some* basic features that the console python.exe lacks.

-tkc

[toc] | [prev] | [next] | [standalone]

#57114

On 10/19/2013 2:08 PM, David Robinow wrote:
> On Sat, Oct 19, 2013 at 9:01 AM, Chris Angelico <rosuav@gmail.com> wrote:
>
>> You can try all these out in the interactive interpreter (you probably
>> have IDLE installed, which on Windows is rather nicer to work with
>> than the default interactive mode).
>   IDLE is cross-platform.  Could you explain why you say "on Windows"?

The command line console on *nix is apparently less obnoxious that the 
one on Windows. So for people who use an editor other than the Idle 
editor, there is less reason to use just the Idle shell.

-- 
Terry Jan Reedy

[toc] | [prev] | [next] | [standalone]

#57115 — What's wrong with Windows Command Prompt (was Re: Error Testing)

On 10/19/2013 2:31 PM, Tim Chase wrote:
> On 2013-10-19 14:08, David Robinow wrote:
>> On Sat, Oct 19, 2013 at 9:01 AM, Chris Angelico wrote:
>>> You can try all these out in the interactive interpreter (you
>>> probably have IDLE installed, which on Windows is rather nicer to
>>> work with than the default interactive mode).
>>
>>   IDLE is cross-platform.  Could you explain why you say "on
>> Windows"?
>
> In my experience, the Win32 Python console lacks readline support
> (like my stock Python on the Mac OS X machine I have here), and as
> such lacks a lot of the niceties.  At least on Win32, there is
> recall of previous commands (my Mac lacks even that), but there's no
> easy "search for the previous command I typed that contains the
> following keyword" (control-R followed by search term), no easy
> "insert all matching filenames here" (alt+asterisk), etc.
>
> Idle may not provide all that, but it hopefully provides at least
> *some* basic features that the console python.exe lacks.

Command Prompt almost 'religiously' imitates the DOS character 
interface. The mouse is mostly ignored; it is not tied to the cursor. 
Idle is a normal Windows gui app.

Command Prompt displays a window of k lines of a circular queue of n 
lines, which are initialized as blank. The default n=300 is not enough 
for a test suite run or many help() outputs. If you find the box on the 
3rd tab of properties, n can be increased up to 9999, but if you do, the 
scroll bar becomes rather useless, as it scrolls through all n lines.

Idle has a normal expanding buffer, with no extra blank lines added.

CP does not have proper cut and paste. I'll leave out most of the 
obnoxious details, but selections are rectangular blocks. This is the 
only function for the mouse, and uses a separate mouse cursor. Idle has 
normal cut and paste that works like any other Windows app.

Idle can recall previous input two different ways, by cursor or key. One 
can use the mouse to select where to edit. CP requires use of arrow keys 
to move the cursor around. Idle recall input *statements*. CP recalls 
input *lines*. Previous multiline statements have to be recalled a line 
at a time. CP was not designed for true multiline commands (as opposed 
to long commands that wrap and display as multiple lines).

CP has no menu (other than a few entries when one right-clicks on the 
icon in the upper left). There is no way to directly save or print the 
buffer.

-- 
Terry Jan Reedy

[toc] | [prev] | [next] | [standalone]

Page 1 of 2  [1] 2  Next page →

Back to top | Article view | comp.lang.python

csiph-web