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


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

Error Testing

Started byScott Novinger <scnovinger@gmail.com>
First post2013-10-19 05:23 -0700
Last post2013-10-21 15:29 -0500
Articles 20 on this page of 43 — 18 participants

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 albert@spenarnc.xs4all.nl (Albert van der Horst) - 2013-10-30 21:43 +0000
              Re: Error Testing Chris Angelico <rosuav@gmail.com> - 2013-10-31 10:50 +1100
              Re: Error Testing Neil Cerutti <neilc@norwich.edu> - 2013-10-31 15:20 +0000
                Re: Error Testing Skip Montanaro <skip@pobox.com> - 2013-10-31 10:51 -0500
                Re: Error Testing rusi <rustompmody@gmail.com> - 2013-10-31 09:05 -0700
                  Re: Error Testing Neil Cerutti <neilc@norwich.edu> - 2013-10-31 17:17 +0000
                    Re: Error Testing William Ray Wing <wrw@mac.com> - 2013-10-31 22:27 -0400
                      Re: Error Testing Grant Edwards <invalid@invalid.invalid> - 2013-11-01 08:32 +0000
                    Re: Error Testing Mark Lawrence <breamoreboy@yahoo.co.uk> - 2013-11-01 03:25 +0000
                      Re: Error Testing rusi <rustompmody@gmail.com> - 2013-10-31 20:42 -0700
                    Re: Error Testing Dennis Lee Bieber <wlfraed@ix.netcom.com> - 2013-11-01 10:51 -0400
                    Re: Error Testing Mark Lawrence <breamoreboy@yahoo.co.uk> - 2013-11-01 15:07 +0000
                  Re: Error Testing Denis McMahon <denismfmcmahon@gmail.com> - 2013-10-31 17:50 +0000
                    Re: Error Testing rusi <rustompmody@gmail.com> - 2013-10-31 10:56 -0700
                      Re: Error Testing Chris Angelico <rosuav@gmail.com> - 2013-11-01 08:00 +1100
                      Re: Error Testing Denis McMahon <denismfmcmahon@gmail.com> - 2013-10-31 22:59 +0000
                        Re: Error Testing rusi <rustompmody@gmail.com> - 2013-10-31 20:50 -0700
                          Re: Error Testing Mark Lawrence <breamoreboy@yahoo.co.uk> - 2013-11-01 09:39 +0000
              Re: Error Testing Mark Lawrence <breamoreboy@yahoo.co.uk> - 2013-11-01 02:00 +0000
          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 2 of 3 — ← Prev page 1 [2] 3  Next page →


#58206

FromChris Angelico <rosuav@gmail.com>
Date2013-11-01 08:00 +1100
Message-ID<mailman.1891.1383253239.18130.python-list@python.org>
In reply to#58197
On Fri, Nov 1, 2013 at 4:56 AM, rusi <rustompmody@gmail.com> wrote:
> On Thursday, October 31, 2013 11:20:52 PM UTC+5:30, Denis McMahon wrote:
>> On Thu, 31 Oct 2013 09:05:04 -0700, rusi wrote:
>> > If I say: "My uncle knows more about flying planes than
>> > the Wright brothers" am I disrespecting the Wright brothers??
>
>> No, but that's not what you said.
>
>> What you said was that "the [FORTRAN] language [was] hacked together
>> haphazardly."
>
>
> I did?!

No, it wasn't you said it (it was Albert, I think). But that _is_ the
line that was said, it's just not yours.

ChrisA

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


#58213

FromDenis McMahon <denismfmcmahon@gmail.com>
Date2013-10-31 22:59 +0000
Message-ID<l4uncn$4dt$1@dont-email.me>
In reply to#58197
On Thu, 31 Oct 2013 10:56:12 -0700, rusi wrote:

> On Thursday, October 31, 2013 11:20:52 PM UTC+5:30, Denis McMahon wrote:
>> On Thu, 31 Oct 2013 09:05:04 -0700, rusi wrote:

>> > If I say: "My uncle knows more about flying planes than the Wright
>> > brothers" am I disrespecting the Wright brothers??

>> No, but that's not what you said.

>> What you said was that "the [FORTRAN] language [was] hacked together
>> haphazardly."

> I did?!

My mistake, that was what Albert said, you were simply standing up for 
him.

Please s/you/he/ in the lines of my previous post quoted above, and 
accept my apologies for my mistake.

-- 
Denis McMahon, denismfmcmahon@gmail.com

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


#58236

Fromrusi <rustompmody@gmail.com>
Date2013-10-31 20:50 -0700
Message-ID<07cfa0a9-2f6f-41e4-ba17-e01a0c5cf8f4@googlegroups.com>
In reply to#58213
On Friday, November 1, 2013 4:29:35 AM UTC+5:30, Denis McMahon wrote:

> My mistake, that was what Albert said, you were simply standing up for 
> him.

> Please s/you/he/ in the lines of my previous post quoted above, and 
> accept my apologies for my mistake.

Heh! Chill!  Yeah there is some hamming distance between the strings
"Albert van der Horst" and "Rusi Mody".  But you were objecting not to the state-er but to the statement...

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


#58252

FromMark Lawrence <breamoreboy@yahoo.co.uk>
Date2013-11-01 09:39 +0000
Message-ID<mailman.1915.1383298781.18130.python-list@python.org>
In reply to#58236
On 01/11/2013 03:50, rusi wrote:
> On Friday, November 1, 2013 4:29:35 AM UTC+5:30, Denis McMahon wrote:
>
>> My mistake, that was what Albert said, you were simply standing up for
>> him.
>
>> Please s/you/he/ in the lines of my previous post quoted above, and
>> accept my apologies for my mistake.
>
> Heh! Chill!  Yeah there is some hamming distance between the strings
> "Albert van der Horst" and "Rusi Mody".  But you were objecting not to the state-er but to the statement...
>
>

Sanity is being restored to this mailing list in that an apology is 
offered and accepted with such good grace.  If only that grumpy old git 
from the south of England, whose name currently escapes me, could always 
behave in the same manner :)

-- 
Python is the second best programming language in the world.
But the best has yet to be invented.  Christian Tismer

Mark Lawrence

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


#58225

FromMark Lawrence <breamoreboy@yahoo.co.uk>
Date2013-11-01 02:00 +0000
Message-ID<mailman.1899.1383271212.18130.python-list@python.org>
In reply to#58131
On 30/10/2013 21:43, Albert van der Horst wrote:
>
> FORTRAN used = and that was a mistake caused by the
> language being hacked together haphazardly.
>
> Groetjes Albert
>

Yes, just imagine the massive amount of research that they had to go on, 
given that Alan Turing had written *THE* paper some 20 years earlier and 
it was 10 years since Tommy Flowers delivered Colussus.  Mind you, maybe 
there's just a tiny little bit of hindsight behind your remark :)

-- 
Python is the second best programming language in the world.
But the best has yet to be invented.  Christian Tismer

Mark Lawrence

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


#57128

FromNed Deily <nad@acm.org>
Date2013-10-19 15:46 -0700
Message-ID<mailman.1275.1382223006.18130.python-list@python.org>
In reply to#57110
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

FromChris Angelico <rosuav@gmail.com>
Date2013-10-20 10:02 +1100
Message-ID<mailman.1276.1382223752.18130.python-list@python.org>
In reply to#57110
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

FromDennis Lee Bieber <wlfraed@ix.netcom.com>
Date2013-10-20 12:18 -0400
Message-ID<mailman.1285.1382285945.18130.python-list@python.org>
In reply to#57110
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

FromNed Batchelder <ned@nedbatchelder.com>
Date2013-10-19 08:44 -0400
Message-ID<mailman.1254.1382186691.18130.python-list@python.org>
In reply to#57091
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

FromRoy Smith <roy@panix.com>
Date2013-10-19 08:57 -0400
Message-ID<roy-1C4E8F.08571219102013@news.panix.com>
In reply to#57094
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

FromChris Angelico <rosuav@gmail.com>
Date2013-10-20 00:04 +1100
Message-ID<mailman.1256.1382187856.18130.python-list@python.org>
In reply to#57096
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

FromNed Batchelder <ned@nedbatchelder.com>
Date2013-10-19 09:07 -0400
Message-ID<mailman.1257.1382188058.18130.python-list@python.org>
In reply to#57096
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

FromRoy Smith <roy@panix.com>
Date2013-10-19 09:09 -0400
Message-ID<roy-85DEDD.09093719102013@news.panix.com>
In reply to#57099
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

FromMark Lawrence <breamoreboy@yahoo.co.uk>
Date2013-10-19 14:19 +0100
Message-ID<mailman.1258.1382188769.18130.python-list@python.org>
In reply to#57096
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

FromChris Angelico <rosuav@gmail.com>
Date2013-10-20 00:01 +1100
Message-ID<mailman.1255.1382187698.18130.python-list@python.org>
In reply to#57091
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

FromDavid Robinow <drobinow@gmail.com>
Date2013-10-19 14:08 -0400
Message-ID<mailman.1262.1382206140.18130.python-list@python.org>
In reply to#57091
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

FromTim Chase <tim@thechases.com>
Date2013-10-19 13:31 -0500
Message-ID<mailman.1263.1382209366.18130.python-list@python.org>
In reply to#57091
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

FromTerry Reedy <tjreedy@udel.edu>
Date2013-10-19 15:50 -0400
Message-ID<mailman.1264.1382212253.18130.python-list@python.org>
In reply to#57091
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)

FromTerry Reedy <tjreedy@udel.edu>
Date2013-10-19 16:35 -0400
SubjectWhat's wrong with Windows Command Prompt (was Re: Error Testing)
Message-ID<mailman.1265.1382214962.18130.python-list@python.org>
In reply to#57091
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]


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

FromChris Angelico <rosuav@gmail.com>
Date2013-10-20 09:15 +1100
SubjectRe: What's wrong with Windows Command Prompt (was Re: Error Testing)
Message-ID<mailman.1268.1382220915.18130.python-list@python.org>
In reply to#57091
On Sun, Oct 20, 2013 at 7:35 AM, Terry Reedy <tjreedy@udel.edu> wrote:
> 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).

This issue applies also to Linux builds with readline. It's Idle's
primary boast, I think, closely followed by hover help for function
signatures.

ChrisA

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


Page 2 of 3 — ← Prev page 1 [2] 3  Next page →

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


csiph-web