Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.python > #72180 > unrolled thread
| Started by | Larry Martell <larry.martell@gmail.com> |
|---|---|
| First post | 2014-05-28 14:23 -0500 |
| Last post | 2014-05-31 09:28 -0800 |
| Articles | 20 on this page of 324 — 57 participants |
Back to article view | Back to comp.lang.python
Python 3 is killing Python Larry Martell <larry.martell@gmail.com> - 2014-05-28 14:23 -0500
Re: Python 3 is killing Python Johannes Bauer <dfnsonfsduifb@gmx.de> - 2014-05-28 21:39 +0200
Re: Python 3 is killing Python Marko Rauhamaa <marko@pacujo.net> - 2014-05-28 22:41 +0300
Re: Python 3 is killing Python Paul Rubin <no.email@nospam.invalid> - 2014-05-28 12:49 -0700
Re: Python 3 is killing Python Larry Martell <larry.martell@gmail.com> - 2014-05-28 14:58 -0500
Re: Python 3 is killing Python Steven D'Aprano <steve@pearwood.info> - 2014-05-29 03:49 +0000
Re: Python 3 is killing Python Paul Rubin <no.email@nospam.invalid> - 2014-05-28 21:23 -0700
Re: Python 3 is killing Python Larry Martell <larry.martell@gmail.com> - 2014-05-29 06:38 -0500
Re: Python 3 is killing Python Chris Angelico <rosuav@gmail.com> - 2014-05-29 06:15 +1000
Re: Python 3 is killing Python Mark Lawrence <breamoreboy@yahoo.co.uk> - 2014-05-28 21:24 +0100
Re: Python 3 is killing Python wxjmfauth@gmail.com - 2014-05-28 23:14 -0700
Re: Python 3 is killing Python Rick Johnson <rantingrickjohnson@gmail.com> - 2014-07-14 15:12 -0700
Re: Python 3 is killing Python mm0fmf <none@mailinator.com> - 2014-07-14 23:37 +0100
Re: Python 3 is killing Python MRAB <python@mrabarnett.plus.com> - 2014-07-14 23:47 +0100
Re: Python 3 is killing Python Rick Johnson <rantingrickjohnson@gmail.com> - 2014-07-14 18:00 -0700
Re: Python 3 is killing Python Chris Angelico <rosuav@gmail.com> - 2014-07-15 11:18 +1000
Re: Python 3 is killing Python Chris Angelico <rosuav@gmail.com> - 2014-07-15 09:28 +1000
Re: Python 3 is killing Python Rick Johnson <rantingrickjohnson@gmail.com> - 2014-07-14 18:54 -0700
Re: Python 3 is killing Python Chris Angelico <rosuav@gmail.com> - 2014-07-15 12:11 +1000
Re: Python 3 is killing Python Rick Johnson <rantingrickjohnson@gmail.com> - 2014-07-14 21:18 -0700
Re: Python 3 is killing Python Chris Angelico <rosuav@gmail.com> - 2014-07-15 14:40 +1000
Re: Python 3 is killing Python Martin S <shieldfire@gmail.com> - 2014-07-15 06:31 +0200
Re: Python 3 is killing Python Steven D'Aprano <steve@pearwood.info> - 2014-07-15 05:41 +0000
Re: Python 3 is killing Python Tim Roberts <timr@probo.com> - 2014-07-16 20:18 -0700
Re: Python 3 is killing Python Rick Johnson <rantingrickjohnson@gmail.com> - 2014-07-16 22:15 -0700
Re: Python 3 is killing Python Gregory Ewing <greg.ewing@canterbury.ac.nz> - 2014-07-17 17:36 +1200
Re: Python 3 is killing Python Chris Angelico <rosuav@gmail.com> - 2014-07-17 15:45 +1000
Re: Python 3 is killing Python Chris Angelico <rosuav@gmail.com> - 2014-07-17 15:45 +1000
Re: Python 3 is killing Python Mark Lawrence <breamoreboy@yahoo.co.uk> - 2014-07-15 08:05 +0100
Re: Python 3 is killing Python alister <alister.nospam.ware@ntlworld.com> - 2014-07-15 12:30 +0000
Re: Python 3 is killing Python Mark Lawrence <breamoreboy@yahoo.co.uk> - 2014-07-15 00:59 +0100
Re: Python 3 is killing Python alister <alister.nospam.ware@ntlworld.com> - 2014-07-15 12:19 +0000
Re: Python 3 is killing Python MRAB <python@mrabarnett.plus.com> - 2014-07-15 15:50 +0100
Re: Python 3 is killing Python alister <alister.nospam.ware@ntlworld.com> - 2014-07-15 17:38 +0000
Re: Python 3 is killing Python Grant Edwards <invalid@invalid.invalid> - 2014-07-15 18:23 +0000
Re: Python 3 is killing Python Mark Lawrence <breamoreboy@yahoo.co.uk> - 2014-07-15 16:35 +0100
Re: Python 3 is killing Python Ben Finney <ben@benfinney.id.au> - 2014-05-29 08:38 +1000
Re: Python 3 is killing Python Paul Rubin <no.email@nospam.invalid> - 2014-05-28 16:22 -0700
Re: Python 3 is killing Python beliavsky@aol.com - 2014-08-06 06:47 -0700
Re: Python 3 is killing Python Terry Reedy <tjreedy@udel.edu> - 2014-08-06 14:42 -0400
Re: Python 3 is killing Python Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2014-08-07 12:42 +1000
Re: Python 3 is killing Python Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2014-08-07 13:37 +1000
Re: Python 3 is killing Python Dennis Lee Bieber <wlfraed@ix.netcom.com> - 2014-08-07 21:07 -0400
Re: Python 3 is killing Python Terry Reedy <tjreedy@udel.edu> - 2014-05-28 21:57 -0400
Re: Python 3 is killing Python Steve Hayes <hayesstw@telkomsa.net> - 2014-05-31 12:07 +0200
Re: Python 3 is killing Python Johannes Bauer <dfnsonfsduifb@gmx.de> - 2014-05-31 13:09 +0200
Re: Python 3 is killing Python Stefan Behnel <stefan_ml@behnel.de> - 2014-05-31 13:22 +0200
Re: Python 3 is killing Python Steve Hayes <hayesstw@telkomsa.net> - 2014-06-01 04:57 +0200
Re: Python 3 is killing Python Chris Angelico <rosuav@gmail.com> - 2014-06-01 13:35 +1000
Re: Python 3 is killing Python Rustom Mody <rustompmody@gmail.com> - 2014-05-31 21:11 -0700
Re: Python 3 is killing Python Steve Hayes <hayesstw@telkomsa.net> - 2014-06-01 13:38 +0200
Re: Python 3 is killing Python Bob Martin <bob.martin@excite.com> - 2014-06-01 07:01 +0100
Re: Python 3 is killing Python Mark Lawrence <breamoreboy@yahoo.co.uk> - 2014-06-01 07:52 +0100
Re: Python 3 is killing Python Steve Hayes <hayesstw@telkomsa.net> - 2014-06-01 13:41 +0200
Re: Python 3 is killing Python Mark Lawrence <breamoreboy@yahoo.co.uk> - 2014-06-01 12:53 +0100
Re: Python 3 is killing Python alister <alister.nospam.ware@ntlworld.com> - 2014-06-01 17:21 +0000
Re: Python 3 is killing Python Bob Martin <bob.martin@excite.com> - 2014-06-02 07:14 +0100
Re: Python 3 is killing Python Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2014-05-31 12:30 +0000
Re: Python 3 is killing Python wxjmfauth@gmail.com - 2014-05-31 08:48 -0700
Re: Python 3 is killing Python Ian Kelly <ian.g.kelly@gmail.com> - 2014-06-02 09:01 -0600
Re: Python 3 is killing Python Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2014-06-02 16:15 +0000
Re: Python 3 is killing Python Roy Smith <roy@panix.com> - 2014-06-02 12:21 -0400
Re: Python 3 is killing Python Chris Angelico <rosuav@gmail.com> - 2014-06-03 02:30 +1000
Re: Python 3 is killing Python Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2014-06-02 16:52 +0000
Re: Python 3 is killing Python Johannes Bauer <dfnsonfsduifb@gmx.de> - 2014-06-02 19:16 +0200
Re: Python 3 is killing Python Ian Kelly <ian.g.kelly@gmail.com> - 2014-06-02 11:53 -0600
Re: Python 3 is killing Python Mark Lawrence <breamoreboy@yahoo.co.uk> - 2014-06-02 18:59 +0100
Re: Python 3 is killing Python wxjmfauth@gmail.com - 2014-06-02 23:12 -0700
Re: Python 3 is killing Python Rustom Mody <rustompmody@gmail.com> - 2014-06-02 23:30 -0700
Re: Python 3 is killing Python Mark Lawrence <breamoreboy@yahoo.co.uk> - 2014-06-03 09:03 +0100
Re: Python 3 is killing Python Ned Batchelder <ned@nedbatchelder.com> - 2014-06-03 07:22 -0400
Re: Python 3 is killing Python Michael Torrie <torriem@gmail.com> - 2014-07-14 21:58 -0600
Re: Python 3 is killing Python wxjmfauth@gmail.com - 2014-07-15 00:23 -0700
Re: Python 3 is killing Python Mark Lawrence <breamoreboy@yahoo.co.uk> - 2014-07-15 08:31 +0100
Re: Python 3 is killing Python Michael Torrie <torriem@gmail.com> - 2014-07-14 21:47 -0600
Re: Python 3 is killing Python Chris Angelico <rosuav@gmail.com> - 2014-07-15 14:20 +1000
Re: Python 3 is killing Python Fabien <fabien.maussion@gmail.com> - 2014-07-15 14:17 +0200
Re: Python 3 is killing Python Chris Angelico <rosuav@gmail.com> - 2014-07-15 23:00 +1000
Re: Python 3 is killing Python Kevin Walzer <kw@codebykevin.com> - 2014-07-15 09:57 -0400
Re: Python 3 is killing Python Chris Angelico <rosuav@gmail.com> - 2014-07-16 00:31 +1000
Re: Python 3 is killing Python Marko Rauhamaa <marko@pacujo.net> - 2014-07-15 20:38 +0300
Re: Python 3 is killing Python Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2014-07-15 19:06 +0000
Re: Python 3 is killing Python Marko Rauhamaa <marko@pacujo.net> - 2014-07-15 23:01 +0300
Re: Python 3 is killing Python Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2014-07-16 03:51 +0000
Re: Python 3 is killing Python Chris Angelico <rosuav@gmail.com> - 2014-07-16 14:20 +1000
Re: Python 3 is killing Python Steven D'Aprano <steve@pearwood.info> - 2014-07-16 07:33 +0000
Re: Python 3 is killing Python Marko Rauhamaa <marko@pacujo.net> - 2014-07-16 08:52 +0300
Re: Python 3 is killing Python Chris Angelico <rosuav@gmail.com> - 2014-07-16 16:26 +1000
Re: Python 3 is killing Python Marko Rauhamaa <marko@pacujo.net> - 2014-07-16 09:44 +0300
Re: Python 3 is killing Python Chris Angelico <rosuav@gmail.com> - 2014-07-16 16:50 +1000
Re: Python 3 is killing Python wxjmfauth@gmail.com - 2014-07-16 00:11 -0700
Re: Python 3 is killing Python Steven D'Aprano <steve@pearwood.info> - 2014-07-16 07:49 +0000
Re: Python 3 is killing Python Chris Angelico <rosuav@gmail.com> - 2014-07-16 18:44 +1000
Re: Python 3 is killing Python Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2014-07-16 11:35 +0000
Re: Python 3 is killing Python Chris Angelico <rosuav@gmail.com> - 2014-07-16 21:54 +1000
Re: Python 3 is killing Python Marko Rauhamaa <marko@pacujo.net> - 2014-07-16 13:46 +0300
Re: Python 3 is killing Python Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2014-07-16 12:10 +0000
Re: Python 3 is killing Python Chris Angelico <rosuav@gmail.com> - 2014-07-16 22:55 +1000
Re: Python 3 is killing Python wxjmfauth@gmail.com - 2014-07-16 06:10 -0700
Re: Python 3 is killing Python Marko Rauhamaa <marko@pacujo.net> - 2014-07-16 16:11 +0300
Re: Python 3 is killing Python wxjmfauth@gmail.com - 2014-07-16 06:22 -0700
Re: Python 3 is killing Python Chris Angelico <rosuav@gmail.com> - 2014-07-17 00:04 +1000
Re: Python 3 is killing Python Marko Rauhamaa <marko@pacujo.net> - 2014-07-16 17:39 +0300
Re: Python 3 is killing Python Chris Angelico <rosuav@gmail.com> - 2014-07-17 01:23 +1000
Re: Python 3 is killing Python Marko Rauhamaa <marko@pacujo.net> - 2014-07-16 18:48 +0300
Re: Python 3 is killing Python Chris Angelico <rosuav@gmail.com> - 2014-07-17 02:07 +1000
Re: Python 3 is killing Python Marko Rauhamaa <marko@pacujo.net> - 2014-07-16 19:20 +0300
Re: Python 3 is killing Python Steven D'Aprano <steve@pearwood.info> - 2014-07-17 02:51 +0000
Re: Python 3 is killing Python Chris Angelico <rosuav@gmail.com> - 2014-07-17 13:15 +1000
Re: Python 3 is killing Python MRAB <python@mrabarnett.plus.com> - 2014-07-17 12:27 +0100
Re: Python 3 is killing Python "Frank Millman" <frank@chagford.com> - 2014-07-17 07:18 +0200
Re: Python 3 is killing Python Steven D'Aprano <steve@pearwood.info> - 2014-07-17 07:49 +0000
Re: Python 3 is killing Python Rustom Mody <rustompmody@gmail.com> - 2014-07-30 14:31 -0700
Re: Python 3 is killing Python Terry Reedy <tjreedy@udel.edu> - 2014-07-16 17:02 -0400
Re: Python 3 is killing Python Terry Reedy <tjreedy@udel.edu> - 2014-07-16 18:47 -0400
Re: Python 3 is killing Python "Frank Millman" <frank@chagford.com> - 2014-07-16 16:27 +0200
Re: Python 3 is killing Python Rick Johnson <rantingrickjohnson@gmail.com> - 2014-07-16 15:41 -0700
Re: Python 3 is killing Python Mark Lawrence <breamoreboy@yahoo.co.uk> - 2014-07-17 00:00 +0100
Re: Python 3 is killing Python Rick Johnson <rantingrickjohnson@gmail.com> - 2014-07-16 18:16 -0700
Re: Python 3 is killing Python Steven D'Aprano <steve@pearwood.info> - 2014-07-17 03:14 +0000
Re: Python 3 is killing Python Mark Lawrence <breamoreboy@yahoo.co.uk> - 2014-07-17 08:17 +0100
Re: Python 3 is killing Python alex23 <wuwei23@gmail.com> - 2014-07-18 12:49 +1000
Re: Python 3 is killing Python Dan Stromberg <drsalists@gmail.com> - 2014-07-17 20:34 -0700
Re: Python 3 is killing Python Grant Edwards <invalid@invalid.invalid> - 2014-07-18 14:17 +0000
Re: Python 3 is killing Python Chris Angelico <rosuav@gmail.com> - 2014-07-17 13:20 +1000
Re: Python 3 is killing Python Mark Lawrence <breamoreboy@yahoo.co.uk> - 2014-07-17 23:54 +0100
Re: Python 3 is killing Python Steven D'Aprano <steve@pearwood.info> - 2014-07-17 03:16 +0000
Re: Python 3 is killing Python Rick Johnson <rantingrickjohnson@gmail.com> - 2014-07-16 21:47 -0700
Re: Python 3 is killing Python Fabien <fabien.maussion@gmail.com> - 2014-07-17 12:12 +0200
Re: Python 3 is killing Python Chris Angelico <rosuav@gmail.com> - 2014-07-17 21:12 +1000
Re: Python 3 is killing Python Rick Johnson <rantingrickjohnson@gmail.com> - 2014-07-17 11:15 -0700
Re: Python 3 is killing Python Chris Angelico <rosuav@gmail.com> - 2014-07-18 04:27 +1000
Re: Python 3 is killing Python Marko Rauhamaa <marko@pacujo.net> - 2014-07-17 21:44 +0300
Re: Python 3 is killing Python Rick Johnson <rantingrickjohnson@gmail.com> - 2014-07-17 19:24 -0700
Re: Python 3 is killing Python Chris Angelico <rosuav@gmail.com> - 2014-07-18 12:39 +1000
Re: Python 3 is killing Python Michael Torrie <torriem@gmail.com> - 2014-07-17 21:40 -0600
Re: Python 3 is killing Python Marko Rauhamaa <marko@pacujo.net> - 2014-07-18 08:24 +0300
Re: Python 3 is killing Python Mark Lawrence <breamoreboy@yahoo.co.uk> - 2014-07-18 08:34 +0100
Re: Python 3 is killing Python Grant Edwards <invalid@invalid.invalid> - 2014-07-18 14:19 +0000
Re: Python 3 is killing Python Larry Martell <larry.martell@gmail.com> - 2014-07-18 08:35 -0600
Re: Python 3 is killing Python Torsten Bronger <bronger@physik.rwth-aachen.de> - 2014-07-18 17:25 +0200
Re: Python 3 is killing Python Terry Reedy <tjreedy@udel.edu> - 2014-07-18 19:45 -0400
Re: Python 3 is killing Python Mark Lawrence <breamoreboy@yahoo.co.uk> - 2014-07-17 20:06 +0100
Re: Python 3 is killing Python Emile van Sebille <emile@fenx.com> - 2014-07-17 12:22 -0700
Re: Python 3 is killing Python Mark Lawrence <breamoreboy@yahoo.co.uk> - 2014-07-17 21:37 +0100
Re: Python 3 is killing Python Terry Reedy <tjreedy@udel.edu> - 2014-07-17 17:30 -0400
Re: Python 3 is killing Python Terry Reedy <tjreedy@udel.edu> - 2014-07-17 20:13 -0400
Re: Python 3 is killing Python Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2014-07-18 18:38 +0000
Re: Python 3 is killing Python Mark Lawrence <breamoreboy@yahoo.co.uk> - 2014-07-18 01:26 +0100
Re: Python 3 is killing Python alex23 <wuwei23@gmail.com> - 2014-07-18 12:54 +1000
Re: Python 3 is killing Python Andrew Berg <aberg010@my.hennepintech.edu> - 2014-07-17 19:45 -0500
Re: Python 3 is killing Python alex23 <wuwei23@gmail.com> - 2014-07-18 13:01 +1000
Re: Python 3 is killing Python Mark Lawrence <breamoreboy@yahoo.co.uk> - 2014-07-18 16:45 +0100
Re: Python 3 is killing Python Chris Angelico <rosuav@gmail.com> - 2014-07-18 12:15 +1000
Re: Python 3 is killing Python Rick Johnson <rantingrickjohnson@gmail.com> - 2014-07-17 20:37 -0700
Re: Python 3 is killing Python Chris Angelico <rosuav@gmail.com> - 2014-07-18 15:34 +1000
Re: Python 3 is killing Python Ian Kelly <ian.g.kelly@gmail.com> - 2014-07-18 02:21 -0600
Re: Python 3 is killing Python Chris Angelico <rosuav@gmail.com> - 2014-07-18 18:27 +1000
Re: Python 3 is killing Python MRAB <python@mrabarnett.plus.com> - 2014-07-18 16:46 +0100
Re: Python 3 is killing Python Mark Lawrence <breamoreboy@yahoo.co.uk> - 2014-07-18 16:49 +0100
Re: Python 3 is killing Python Mark Lawrence <breamoreboy@yahoo.co.uk> - 2014-07-18 16:50 +0100
Re: Python 3 is killing Python Mark Lawrence <breamoreboy@yahoo.co.uk> - 2014-07-18 17:22 +0100
Re: Python 3 is killing Python Terry Reedy <tjreedy@udel.edu> - 2014-07-18 21:27 -0400
Re: Python 3 is killing Python Terry Reedy <tjreedy@udel.edu> - 2014-07-18 21:21 -0400
Re: Python 3 is killing Python Rick Johnson <rantingrickjohnson@gmail.com> - 2014-07-19 09:29 -0700
Re: Python 3 is killing Python Chris Angelico <rosuav@gmail.com> - 2014-07-20 02:41 +1000
Re: Python 3 is killing Python Ian Kelly <ian.g.kelly@gmail.com> - 2014-07-19 12:00 -0600
Re: Python 3 is killing Python Rick Johnson <rantingrickjohnson@gmail.com> - 2014-07-19 13:39 -0700
Re: Python 3 is killing Python Chris Angelico <rosuav@gmail.com> - 2014-07-20 09:13 +1000
Improving Idle (was Re: Python 3 ...) Terry Reedy <tjreedy@udel.edu> - 2014-07-19 16:45 -0400
Re: Improving Idle (was Re: Python 3 ...) Rick Johnson <rantingrickjohnson@gmail.com> - 2014-07-19 18:31 -0700
Re: Improving Idle (was Re: Python 3 ...) Chris Angelico <rosuav@gmail.com> - 2014-07-20 11:42 +1000
Re: Improving Idle (was Re: Python 3 ...) Mark Lawrence <breamoreboy@yahoo.co.uk> - 2014-07-20 12:40 +0100
Idle's Shell: prompts and indents (was ...) Idle users please read Terry Reedy <tjreedy@udel.edu> - 2014-07-20 17:52 -0400
Re: Idle's Shell: prompts and indents (was ...) Idle users please read Rick Johnson <rantingrickjohnson@gmail.com> - 2014-07-20 18:22 -0700
Re: Idle's Shell: prompts and indents (was ...) Idle users please read Chris Angelico <rosuav@gmail.com> - 2014-07-21 11:32 +1000
Re: Idle's Shell: prompts and indents (was ...) Idle users please read Terry Reedy <tjreedy@udel.edu> - 2014-07-20 23:49 -0400
Re: Idle's Shell: prompts and indents (was ...) Idle users please read Chris Angelico <rosuav@gmail.com> - 2014-07-21 10:55 +1000
Re: Idle's Shell: prompts and indents (was ...) Idle users please read Terry Reedy <tjreedy@udel.edu> - 2014-07-20 23:28 -0400
Re: Idle's Shell: prompts and indents (was ...) Idle users please read Chris Angelico <rosuav@gmail.com> - 2014-07-21 13:34 +1000
Re: Idle's Shell: prompts and indents (was ...) Idle users please read Terry Reedy <tjreedy@udel.edu> - 2014-07-21 05:00 -0400
Re: Idle's Shell: prompts and indents (was ...) Idle users please read wxjmfauth@gmail.com - 2014-07-21 13:00 -0700
Re: Idle's Shell: prompts and indents (was ...) Idle users please read Chris Angelico <rosuav@gmail.com> - 2014-07-21 20:56 +1000
Re: Idle's Shell: prompts and indents (was ...) Idle users please read Terry Reedy <tjreedy@udel.edu> - 2014-07-21 14:30 -0400
Re: Idle's Shell: prompts and indents (was ...) Idle users please read Chris Angelico <rosuav@gmail.com> - 2014-07-22 04:35 +1000
Re: Python 3 is killing Python Rick Johnson <rantingrickjohnson@gmail.com> - 2014-07-19 15:50 -0700
Re: Python 3 is killing Python Terry Reedy <tjreedy@udel.edu> - 2014-07-19 19:23 -0400
Re: Python 3 is killing Python Chris Angelico <rosuav@gmail.com> - 2014-07-20 09:10 +1000
Re: Improving Idle (was Re: Python 3 ...) Mark Lawrence <breamoreboy@yahoo.co.uk> - 2014-07-21 02:54 +0100
Re: Python 3 is killing Python Mark Lawrence <breamoreboy@yahoo.co.uk> - 2014-07-18 08:24 +0100
Re: Python 3 is killing Python Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2014-07-18 18:20 +0000
Re: Python 3 is killing Python Mark Lawrence <breamoreboy@yahoo.co.uk> - 2014-07-18 19:31 +0100
Re: Python 3 is killing Python MRAB <python@mrabarnett.plus.com> - 2014-07-18 20:44 +0100
Re: Python 3 is killing Python Rick Johnson <rantingrickjohnson@gmail.com> - 2014-07-18 14:37 -0700
Re: Python 3 is killing Python Ned Batchelder <ned@nedbatchelder.com> - 2014-07-18 18:09 -0400
Python and IDEs [was Re: Python 3 is killing Python] Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2014-07-19 07:28 +0000
Re: Python and IDEs [was Re: Python 3 is killing Python] "C.D. Reimer" <chris@cdreimer.com> - 2014-07-19 11:08 -0700
Re: Python and IDEs [was Re: Python 3 is killing Python] Terry Reedy <tjreedy@udel.edu> - 2014-07-19 14:31 -0400
Re: Python and IDEs [was Re: Python 3 is killing Python] Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2014-07-20 01:23 +0000
Re: Python and IDEs [was Re: Python 3 is killing Python] Chris Angelico <rosuav@gmail.com> - 2014-07-20 11:39 +1000
Re: Python and IDEs [was Re: Python 3 is killing Python] "C.D. Reimer" <chris@cdreimer.com> - 2014-07-19 18:53 -0700
Re: Python and IDEs [was Re: Python 3 is killing Python] CHIN Dihedral <dihedral88888@gmail.com> - 2014-07-21 08:37 -0700
Re: Python and IDEs [was Re: Python 3 is killing Python] Tim Delaney <timothy.c.delaney@gmail.com> - 2014-07-20 14:18 +1000
Re: Python and IDEs [was Re: Python 3 is killing Python] Tim Delaney <timothy.c.delaney@gmail.com> - 2014-07-20 07:50 +1000
Re: Python and IDEs [was Re: Python 3 is killing Python] Chris Angelico <rosuav@gmail.com> - 2014-07-20 09:19 +1000
Re: Python and IDEs [was Re: Python 3 is killing Python] Tim Delaney <timothy.c.delaney@gmail.com> - 2014-07-20 10:41 +1000
Re: Python and IDEs [was Re: Python 3 is killing Python] "C.D. Reimer" <chris@cdreimer.com> - 2014-07-19 18:24 -0700
Re: Python and IDEs [was Re: Python 3 is killing Python] TP <wingusr@gmail.com> - 2014-07-19 19:03 -0700
Re: Python and IDEs [was Re: Python 3 is killing Python] "C.D. Reimer" <chris@cdreimer.com> - 2014-07-19 20:10 -0700
Re: Python and IDEs [was Re: Python 3 is killing Python] Wolfgang Keller <feliphil@gmx.net> - 2014-08-01 13:10 +0200
Re: Python and IDEs [was Re: Python 3 is killing Python] Chris Angelico <rosuav@gmail.com> - 2014-08-01 21:22 +1000
Re: Python and IDEs Marko Rauhamaa <marko@pacujo.net> - 2014-08-01 15:19 +0300
Re: Python and IDEs Chris Angelico <rosuav@gmail.com> - 2014-08-01 22:30 +1000
Re: Python and IDEs Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2014-08-01 23:10 +1000
Re: Python and IDEs Chris Angelico <rosuav@gmail.com> - 2014-08-01 23:30 +1000
Re: Python and IDEs Marko Rauhamaa <marko@pacujo.net> - 2014-08-01 18:13 +0300
Re: Python and IDEs [was Re: Python 3 is killing Python] Wolfgang Keller <feliphil@gmx.net> - 2014-08-06 14:38 +0200
Re: Python and IDEs [was Re: Python 3 is killing Python] Chris Angelico <rosuav@gmail.com> - 2014-08-06 22:51 +1000
Re: Python and IDEs [was Re: Python 3 is killing Python] Wolfgang Keller <feliphil@gmx.net> - 2014-08-11 11:08 +0200
Re: Python and IDEs [was Re: Python 3 is killing Python] Nicholas Cole <nicholas.cole@gmail.com> - 2014-08-01 15:28 +0100
Re: Python and IDEs [was Re: Python 3 is killing Python] Wolfgang Keller <feliphil@gmx.net> - 2014-08-06 14:47 +0200
Re: Python and IDEs [was Re: Python 3 is killing Python] Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2014-08-07 13:32 +1000
Re: Python and IDEs [was Re: Python 3 is killing Python] Wolfgang Keller <feliphil@gmx.net> - 2014-08-11 11:08 +0200
Re: Python and IDEs [was Re: Python 3 is killing Python] alister <alister.nospam.ware@ntlworld.com> - 2014-08-11 09:37 +0000
Re: Python and IDEs [was Re: Python 3 is killing Python] Chris Angelico <rosuav@gmail.com> - 2014-08-11 20:20 +1000
Re: Python and IDEs [was Re: Python 3 is killing Python] Mark Lawrence <breamoreboy@yahoo.co.uk> - 2014-08-11 14:45 +0100
Re: Python and IDEs [was Re: Python 3 is killing Python] Grant Edwards <invalid@invalid.invalid> - 2014-08-11 18:42 +0000
Re: Python and IDEs [was Re: Python 3 is killing Python] Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2014-08-12 10:11 +1000
Re: Quoting and attribution (was: Python and IDEs [was Re: Python 3 is killing Python]) Tim Chase <python.list@tim.thechases.com> - 2014-08-11 19:27 -0500
Re: Quoting and attribution (was: Python and IDEs [was Re: Python 3 is killing Python]) Steven D'Aprano <steve@pearwood.info> - 2014-08-12 02:07 +0000
Re: Quoting and attribution (was: Python and IDEs [was Re: Python 3 is killing Python]) Chris Angelico <rosuav@gmail.com> - 2014-08-12 12:13 +1000
Re: Quoting and attribution (was: Python and IDEs [was Re: Python 3 is killing Python]) Tim Chase <python.list@tim.thechases.com> - 2014-08-11 21:23 -0500
Re: Python and IDEs [was Re: Python 3 is killing Python] Wolfgang Keller <feliphil@gmx.net> - 2014-08-13 12:42 +0200
Re: Python and IDEs [was Re: Python 3 is killing Python] Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2014-08-13 23:35 +1000
Re: Python and IDEs [was Re: Python 3 is killing Python] Mark Lawrence <breamoreboy@yahoo.co.uk> - 2014-08-13 16:51 +0100
Re: Python and IDEs [was Re: Python 3 is killing Python] Chris Angelico <rosuav@gmail.com> - 2014-08-02 00:39 +1000
Re: Python and IDEs [was Re: Python 3 is killing Python] Gregory Ewing <greg.ewing@canterbury.ac.nz> - 2014-08-02 11:14 +1200
Re: Python and IDEs [was Re: Python 3 is killing Python] Chris Angelico <rosuav@gmail.com> - 2014-08-02 09:50 +1000
Re: Python and IDEs [was Re: Python 3 is killing Python] Olaf Hering <olaf@aepfle.de> - 2014-08-02 09:10 +0200
Re: Python and IDEs [was Re: Python 3 is killing Python] Gregory Ewing <greg.ewing@canterbury.ac.nz> - 2014-08-02 23:38 +1200
Re: Python and IDEs [was Re: Python 3 is killing Python] Dietmar Schwertberger <maillist@schwertberger.de> - 2014-08-01 19:16 +0200
Re: Python and IDEs [was Re: Python 3 is killing Python] Wolfgang Keller <feliphil@gmx.net> - 2014-08-06 14:47 +0200
Re: Python and IDEs [was Re: Python 3 is killing Python] Grant Edwards <invalid@invalid.invalid> - 2014-08-11 18:39 +0000
Re: Python and IDEs [was Re: Python 3 is killing Python] Wolfgang Keller <feliphil@gmx.net> - 2014-08-13 13:46 +0200
Re: Python and IDEs [was Re: Python 3 is killing Python] Michael Torrie <torriem@gmail.com> - 2014-08-01 14:22 -0600
Re: Python and IDEs [was Re: Python 3 is killing Python] MRAB <python@mrabarnett.plus.com> - 2014-08-01 22:09 +0100
Re: Python and IDEs [was Re: Python 3 is killing Python] Gregory Ewing <greg.ewing@canterbury.ac.nz> - 2014-08-02 12:00 +1200
Re: Python and IDEs [was Re: Python 3 is killing Python] Chris Angelico <rosuav@gmail.com> - 2014-08-02 10:20 +1000
Re: Python and IDEs [was Re: Python 3 is killing Python] Gregory Ewing <greg.ewing@canterbury.ac.nz> - 2014-08-02 23:33 +1200
Re: Python and IDEs [was Re: Python 3 is killing Python] Chris Angelico <rosuav@gmail.com> - 2014-08-02 23:01 +1000
Re: Python and IDEs [was Re: Python 3 is killing Python] Gregory Ewing <greg.ewing@canterbury.ac.nz> - 2014-08-03 12:01 +1200
Re: Python and IDEs [was Re: Python 3 is killing Python] Chris Angelico <rosuav@gmail.com> - 2014-08-03 11:12 +1000
Re: Python and IDEs [was Re: Python 3 is killing Python] MRAB <python@mrabarnett.plus.com> - 2014-08-02 14:55 +0100
Re: Python and IDEs [was Re: Python 3 is killing Python] Gregory Ewing <greg.ewing@canterbury.ac.nz> - 2014-08-03 12:04 +1200
Re: Python and IDEs [was Re: Python 3 is killing Python] Dietmar Schwertberger <maillist@schwertberger.de> - 2014-08-03 09:46 +0200
Re: Python and IDEs [was Re: Python 3 is killing Python] Roy Smith <roy@panix.com> - 2014-08-02 10:27 -0400
Re: Python and IDEs [was Re: Python 3 is killing Python] Gregory Ewing <greg.ewing@canterbury.ac.nz> - 2014-08-03 12:20 +1200
Re: Python and IDEs [was Re: Python 3 is killing Python] Chris Angelico <rosuav@gmail.com> - 2014-08-02 09:48 +1000
Re: Python and IDEs [was Re: Python 3 is killing Python] Duncan Booth <duncan.booth@invalid.invalid> - 2014-08-05 13:29 +0000
Re: Python and IDEs [was Re: Python 3 is killing Python] Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2014-08-06 02:50 +1000
Re: Python and IDEs [was Re: Python 3 is killing Python] Duncan Booth <duncan.booth@invalid.invalid> - 2014-08-05 19:25 +0000
Re: Python and IDEs [was Re: Python 3 is killing Python] TP <wingusr@gmail.com> - 2014-08-05 14:28 -0700
Re: Python 3 is killing Python Terry Reedy <tjreedy@udel.edu> - 2014-07-18 19:26 -0400
Re: Python 3 is killing Python Kevin Walzer <kw@codebykevin.com> - 2014-08-03 21:21 -0400
Re: Python 3 is killing Python Chris Angelico <rosuav@gmail.com> - 2014-07-17 01:18 +1000
Re: Python 3 is killing Python Javier <nospam@nospam.com> - 2014-07-16 17:33 +0000
Re: Python 3 is killing Python Ian Kelly <ian.g.kelly@gmail.com> - 2014-07-16 11:50 -0600
Re: Python 3 is killing Python Steven D'Aprano <steve@pearwood.info> - 2014-07-17 03:33 +0000
Re: Python 3 is killing Python Steven D'Aprano <steve@pearwood.info> - 2014-07-17 04:25 +0000
Re: Python 3 is killing Python "Neil D. Cerutti" <neilc@norwich.edu> - 2014-07-16 11:48 -0400
Re: Python 3 is killing Python Mark Lawrence <breamoreboy@yahoo.co.uk> - 2014-07-16 18:34 +0100
Re: Python 3 is killing Python "Frank Millman" <frank@chagford.com> - 2014-07-17 08:31 +0200
Re: Python 3 is killing Python Chris Angelico <rosuav@gmail.com> - 2014-07-17 16:41 +1000
Re: Python 3 is killing Python "Frank Millman" <frank@chagford.com> - 2014-07-17 09:09 +0200
Re: Python 3 is killing Python Chris Angelico <rosuav@gmail.com> - 2014-07-17 17:59 +1000
Re: Python 3 is killing Python Glenn Linderman <v+python@g.nevcal.com> - 2014-08-01 23:18 -0700
Re: Python 3 is killing Python Mark Lawrence <breamoreboy@yahoo.co.uk> - 2014-07-15 21:24 +0100
Re: Python 3 is killing Python Devin Jeanpierre <jeanpierreda@gmail.com> - 2014-07-15 13:47 -0700
Re: Python 3 is killing Python Abhiram R <abhi.darkness@gmail.com> - 2014-07-16 03:07 +0530
Re: Python 3 is killing Python Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2014-07-16 02:08 +0000
Re: Python 3 is killing Python Abhiram R <abhi.darkness@gmail.com> - 2014-07-16 03:05 +0530
Re: Python 3 is killing Python Mark Lawrence <breamoreboy@yahoo.co.uk> - 2014-07-15 22:49 +0100
Re: Python 3 is killing Python Abhiram R <abhi.darkness@gmail.com> - 2014-07-16 03:43 +0530
Re: Python 3 is killing Python Kevin Walzer <kw@codebykevin.com> - 2014-07-15 18:30 -0400
Re: Python 3 is killing Python Abhiram R <abhi.darkness@gmail.com> - 2014-07-16 04:10 +0530
Re: Python 3 is killing Python Rick Johnson <rantingrickjohnson@gmail.com> - 2014-07-15 16:53 -0700
Re: Python 3 is killing Python MRAB <python@mrabarnett.plus.com> - 2014-07-16 02:57 +0100
Re: Python 3 is killing Python Tim Roberts <timr@probo.com> - 2014-07-16 20:20 -0700
Re: Python 3 is killing Python Chris Angelico <rosuav@gmail.com> - 2014-07-17 13:38 +1000
Re: Python 3 is killing Python Abhiram R <abhi.darkness@gmail.com> - 2014-07-16 09:07 +0530
Re: Python 3 is killing Python Mark Lawrence <breamoreboy@yahoo.co.uk> - 2014-07-16 09:18 +0100
Re: Python 3 is killing Python Chris “Kwpolska” Warrick <kwpolska@gmail.com> - 2014-07-16 12:20 +0200
Re: Python 3 is killing Python Ben Finney <ben@benfinney.id.au> - 2014-07-17 14:17 +1000
Re: Python 3 is killing Python Joshua Landau <joshua@landau.ws> - 2014-07-16 00:45 +0100
Interleaved posting style for text discussion forums (was: Python 3 is killing Python) Ben Finney <ben@benfinney.id.au> - 2014-07-17 14:02 +1000
Re: Python 3 is killing Python Mark Lawrence <breamoreboy@yahoo.co.uk> - 2014-07-15 23:38 +0100
Re: Python 3 is killing Python Kevin Walzer <kw@codebykevin.com> - 2014-07-15 20:43 -0400
Re: Python 3 is killing Python Dennis Lee Bieber <wlfraed@ix.netcom.com> - 2014-07-15 23:05 -0400
Re: Python 3 is killing Python Grant Edwards <invalid@invalid.invalid> - 2014-07-16 13:59 +0000
Re: Python 3 is killing Python Rick Johnson <rantingrickjohnson@gmail.com> - 2014-07-15 11:01 -0700
Re: Python 3 is killing Python Marko Rauhamaa <marko@pacujo.net> - 2014-07-15 21:08 +0300
Re: Python 3 is killing Python Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2014-07-15 18:57 +0000
Re: Python 3 is killing Python Marko Rauhamaa <marko@pacujo.net> - 2014-07-15 22:49 +0300
Re: Python 3 is killing Python Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2014-07-15 18:53 +0000
Re: Python 3 is killing Python Rick Johnson <rantingrickjohnson@gmail.com> - 2014-07-15 13:20 -0700
Re: Python 3 is killing Python Ian Kelly <ian.g.kelly@gmail.com> - 2014-07-15 14:46 -0600
Re: Python 3 is killing Python Ian Kelly <ian.g.kelly@gmail.com> - 2014-07-15 12:53 -0600
Re: Python 3 is killing Python Anders Wegge Keller <wegge@wegge.dk> - 2014-07-15 17:02 +0200
Re: Python 3 is killing Python Grant Edwards <invalid@invalid.invalid> - 2014-07-15 15:43 +0000
Re: Python 3 is killing Python Mark Lawrence <breamoreboy@yahoo.co.uk> - 2014-07-15 16:44 +0100
Re: Python 3 is killing Python Chris Angelico <rosuav@gmail.com> - 2014-07-16 01:48 +1000
Re: Python 3 is killing Python alex23 <wuwei23@gmail.com> - 2014-07-17 15:48 +1000
Re: Python 3 is killing Python Steven D'Aprano <steve@pearwood.info> - 2014-07-17 07:03 +0000
Re: Python 3 is killing Python Rick Johnson <rantingrickjohnson@gmail.com> - 2014-07-17 10:36 -0700
Re: Python 3 is killing Python Chris Angelico <rosuav@gmail.com> - 2014-07-18 03:52 +1000
Re: Python 3 is killing Python Rick Johnson <rantingrickjohnson@gmail.com> - 2014-07-17 11:38 -0700
Re: Python 3 is killing Python Chris Angelico <rosuav@gmail.com> - 2014-07-18 04:48 +1000
Re: Python 3 is killing Python Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2014-07-18 18:01 +0000
Re: Python 3 is killing Python wxjmfauth@gmail.com - 2014-07-15 06:33 -0700
Re: Python 3 is killing Python Steve Hayes <hayesstw@telkomsa.net> - 2014-06-01 05:00 +0200
Re: Python 3 is killing Python Marko Rauhamaa <marko@pacujo.net> - 2014-05-31 15:44 +0300
Re: Python 3 is killing Python Steve Hayes <hayesstw@telkomsa.net> - 2014-06-01 05:05 +0200
Re: Python 3 is killing Python pyotr filipivich <phamp@mindspring.com> - 2014-07-12 10:50 -0700
Re: Python 3 is killing Python Deb Wyatt <codemonkey@inbox.com> - 2014-05-31 09:28 -0800
Page 9 of 17 — ← Prev page 1 … 7 8 [9] 10 11 … 17 Next page →
| From | Mark Lawrence <breamoreboy@yahoo.co.uk> |
|---|---|
| Date | 2014-07-18 16:50 +0100 |
| Message-ID | <mailman.12006.1405698905.18130.python-list@python.org> |
| In reply to | #74721 |
On 18/07/2014 09:27, Chris Angelico wrote: > On Fri, Jul 18, 2014 at 6:21 PM, Ian Kelly <ian.g.kelly@gmail.com> wrote: >>> Yes Chris, i also think that the IDLE shell is "spectacular" >>> when i'm using it, especially when i press >>> "CONTROL+LEFT_ARROW" and the insertion cursor lands *BEHIND* >>> the start of the interactive command marker " >>>", an >>> area where key presses are not allowed, so *NOW* I must press >>> "CONTROL+RIGHT_ARROW" three times to get to my destination! >> >> I just tried to reproduce this using IDLE 3.4 on Windows and was not able to. > > Actually, now you mention it, I do recall experiencing a bug like this > in previous versions. It's not the case in either my 2.7 (point > something, but I don't remember what) nor 3.4, so I'm guessing it's > been fixed. > > ChrisA > Fixed by whom, Terry Reedy & Co or rr? -- My fellow Pythonistas, ask not what our language can do for you, ask what you can do for our language. Mark Lawrence --- This email is free from viruses and malware because avast! Antivirus protection is active. http://www.avast.com
[toc] | [prev] | [next] | [standalone]
| From | Mark Lawrence <breamoreboy@yahoo.co.uk> |
|---|---|
| Date | 2014-07-18 17:22 +0100 |
| Message-ID | <mailman.12007.1405700539.18130.python-list@python.org> |
| In reply to | #74721 |
On 18/07/2014 16:46, MRAB wrote: > On 2014-07-18 04:37, Rick Johnson wrote: >> On Thursday, July 17, 2014 9:15:15 PM UTC-5, Chris Angelico wrote: >>> For myself, though, I completely do not use the editor half of >>> [IDLE]; but >>> it's spectacularly useful (with limitations) as my primary interactive >>> interpreter. >> >> Yes Chris, i also think that the IDLE shell is "spectacular" >> when i'm using it, especially when i press >> "CONTROL+LEFT_ARROW" and the insertion cursor lands *BEHIND* >> the start of the interactive command marker " >>>", an >> area where key presses are not allowed, so *NOW* I must press >> "CONTROL+RIGHT_ARROW" three times to get to my destination! >> >> I'm also just "gushing with exuberance" when i open a new >> block and i get *EIGHT SPACE INDENTION*! >> >> And I get a raging semi each time IDLE hangs between run >> sessions when i'm editing Tkinter code, yes Chris, I GET A >> BIG FAT ERECTION! Sometimes, when it does not go away >> after four hours, i have to visit the local emergency room >> and take some pills. >> >> THAT'S HOW MUCH I JUST *LOVE* THIS CRAPPY SOFTWARE CHRIS! >> >> I'M SO GLAD WE CAN SHARE THESE "WONDERFUL" EXPERIENCES TOGETHER! >> >> MAYBE NEXT WE CAN RE-INACT THE LAST SCENE OF ROMEO AND JULIETTE? >> >>> [...] The only problem I have with it is that blatting >>> ridiculous amounts of text to the console can take a very >>> long time, esp on Windows. If I accidentally display a >>> large object when I thought I was displaying a small one, >>> it'll hang for quite a while, churning through something, >>> and it's not easy to see why or to halt it. But I suspect >>> that's more of a Windows and/or Tk issue than an Idle one. >> >> The *PROBLEM* is that user has no method of "undo-ing" an >> accidental display of huge amounts of data , forcing the >> user to close and then re-open the entire software -- can >> you understand now *WHY* i complain about this software? >> >> This is *EMBARRASSING*, and you should *ALL* be ashamed >> that, not only does Python include such an amateurish piece >> of crap software, but it has been there for years! >> >> UNCHANGED FOR YEARS!!! >> > I'm sorry to hear that you've been suffering all these years. If only > there were a way to fix it. > > Here's a suggestion for the Python community: how about opening up the > source code and letting people contribute fixes? We could call this > "open source". > > We could even open the source for CPython itself! Could that work? > > What do you think? > That plan is so cunning it makes Baldrick's cunning plans look good :) http://en.wikipedia.org/wiki/Baldrick Actually I believe we should just leave things alone, if it ain't broke, don't fix it. -- My fellow Pythonistas, ask not what our language can do for you, ask what you can do for our language. Mark Lawrence --- This email is free from viruses and malware because avast! Antivirus protection is active. http://www.avast.com
[toc] | [prev] | [next] | [standalone]
| From | Terry Reedy <tjreedy@udel.edu> |
|---|---|
| Date | 2014-07-18 21:27 -0400 |
| Message-ID | <mailman.12027.1405733311.18130.python-list@python.org> |
| In reply to | #74721 |
On 7/18/2014 11:50 AM, Mark Lawrence wrote: > On 18/07/2014 09:27, Chris Angelico wrote: >> On Fri, Jul 18, 2014 at 6:21 PM, Ian Kelly <ian.g.kelly@gmail.com> wrote: >>>> Yes Chris, i also think that the IDLE shell is "spectacular" >>>> when i'm using it, especially when i press >>>> "CONTROL+LEFT_ARROW" and the insertion cursor lands *BEHIND* >>>> the start of the interactive command marker " >>>", an >>>> area where key presses are not allowed, so *NOW* I must press >>>> "CONTROL+RIGHT_ARROW" three times to get to my destination! >>> >>> I just tried to reproduce this using IDLE 3.4 on Windows and was not >>> able to. >> >> Actually, now you mention it, I do recall experiencing a bug like this >> in previous versions. It's not the case in either my 2.7 (point >> something, but I don't remember what) nor 3.4, so I'm guessing it's >> been fixed. I know there was an issue and fix for <Home> in the shell. I suspect Control+LeftArrow was looked at and fixed at the same time, if not before. > Fixed by whom, Terry Reedy & Co or rr? Other people. -- Terry Jan Reedy
[toc] | [prev] | [next] | [standalone]
| From | Terry Reedy <tjreedy@udel.edu> |
|---|---|
| Date | 2014-07-18 21:21 -0400 |
| Message-ID | <mailman.12026.1405732945.18130.python-list@python.org> |
| In reply to | #74721 |
On 7/17/2014 11:37 PM, Rick Johnson wrote: > On Thursday, July 17, 2014 9:15:15 PM UTC-5, Chris Angelico wrote: >> For myself, though, I completely do not use the editor half of [IDLE]; but >> it's spectacularly useful (with limitations) as my primary interactive >> interpreter. > > Yes Chris, i also think that the IDLE shell is "spectacular" > when i'm using it, especially when i press > "CONTROL+LEFT_ARROW" and the insertion cursor lands *BEHIND* > the start of the interactive command marker " >>>", What ancient version, or oddball system are you using? For me, Win 7, both 2.7.8 and 3.4.1 >>> abc "CONTROL+LEFT_ARROW" and the cursor is before the 'a'. The HOME key goes to the same place first, and they before >>> on the second press (and before 'a' on the third). > an > area where key presses are not allowed, so *NOW* I must press > "CONTROL+RIGHT_ARROW" three times to get to my destination! If see different behavior with *current* Python+Idle, please give details. Let's try to find out why and fix it. Check .idlerc/config-keys.cfg in your home directory. > I'm also just "gushing with exuberance" when i open a new > block and i get *EIGHT SPACE INDENTION*! http://bugs.python.org/issue7676 "IDLE shell shouldn't use TABs" is a high-priority for me. The problem is agreeing on an *exact* specification for new behavior, that takes into account both the limitations and flexibility of tk. Maybe I should start a thread here or python-ideas, where people are willing to discuss details. > IDLE hangs between run > sessions when i'm editing Tkinter code I cannot connect this description to behavior I have seen. >> [...] The only problem I have with it is that blatting >> ridiculous amounts of text to the console can take a very >> long time, esp on Windows. If I accidentally display a >> large object when I thought I was displaying a small one, >> it'll hang for quite a while, churning through something, >> and it's not easy to see why or to halt it. But I suspect >> that's more of a Windows and/or Tk issue than an Idle one. ^C 'should' stop output 'eventually'. Sometimes does, sometimes not. > The *PROBLEM* is that user has no method of "undo-ing" an > accidental display of huge amounts of data , forcing the > user to close and then re-open the entire software I believe there is a proposal to be able to clear the shell window. We just need to add "Clear and restart shell". There is also an idea to put help output in an output window. Undo-ing the result of hitting <enter> seems like a sensible extension of undoing the result of hitting a key in the editor. I opened "Idle: better management of Shell window output" http://bugs.python.org/issue22010 for all three ideas, and gave you credit for part of the undo idea. > UNCHANGED FOR YEARS!!! So sign the contributor agreement and volunteer to write and review patches. -- Terry Jan Reedy
[toc] | [prev] | [next] | [standalone]
| From | Rick Johnson <rantingrickjohnson@gmail.com> |
|---|---|
| Date | 2014-07-19 09:29 -0700 |
| Message-ID | <9b5557e3-45ea-4d3b-81cd-90d69322c556@googlegroups.com> |
| In reply to | #74788 |
On Friday, July 18, 2014 8:21:36 PM UTC-5, Terry Reedy wrote:
> What ancient version, or oddball system are you using? For
> me, Win 7, both 2.7.8 and 3.4.1 "CONTROL+LEFT_ARROW" and
> the cursor is before the 'a' of [>>> abc]. The HOME key
> goes to the same place first, and they before >>> on the
> second press (and before 'a' on the third).
On versions 2.7.2 and 3.2.2 CONTROL+LEFT_ARROW is landing
*properly* in front of the prompt, so apparently that bug was
fixed since last i checked, my apologies for being ignorant
of the situation, but you should understand that i had given
up after years of no improvements.
However, a *bare* HOME_KEY press is placing the insertion
cursor *BEHIND* the prompt of the current line. In a shell
environment, you never want to be *BEHIND* the command
prompt.
Now, in the case of CONTROL+HOME (which places the insertion
cursor at the very *first* position of the entire text
buffer) and CONTROL+END (which places the insertion cursor
at the very *last* position of the text buffer), we should
leave the default behaviors alone. I don't see any benefit
of changing them.
> "IDLE shell shouldn't use TABs" is a high-priority for me.
> The problem is agreeing on an *exact* specification for
> new behavior, that takes into account both the limitations
> and flexibility of tk. Maybe I should start a thread here
> or python-ideas, where people are willing to discuss
> details.
First, i need to admit that i was wrong when i said: "eight
space indention", since the IDLE shell is using *tabs* for
indention, not spaces! However, a single tab is just as
annoying as 8 spaces
Now, even as much as i dislike tabs, i must admit there is a
benefit to using tabs over spaces, since tabs require only
*ONE* backspace key-press per "pseudo 4 spaces" as compared
to spaces which require a 1:1 ratio of key-presses. Of
course, even this problem can be abstracted away by
"backspace automation code", which the IDLE editor window
already employs!
But my point is: We *MUST* remove this *excessive*
indentation width from the IDLE shell!
> I cannot connect [your complaint about IDLE hanging] to
> behavior I have seen.
IDLE will hang when editing Tkinter code. It seems to happen
most often in two cases:
1. When running code that results in a Tkinter error.
This can happen when mixing the "grid" and "pack" geometry
managers within the same "container" widget, which is a
Tkinter NO-NO, but it can also happen during other Tkinter
errors!
2. During "quickly successive" back-to-back "run sessions"
of Tkinter GUI apps.
It seems that sometimes, if you don't give IDLE enough
time to release resources from the *LAST* run session, it
will freeze and then throw a "sub-process connection
failure" message, which, sometimes you can remedy by just
"trying again", but all to often you are forced to kill
the entire IDLE (and related sub-) processes.
THIS IS EXTREMELY ANNOYING!
However, *EVEN* in the instances where a problem is a direct
result of a "Tkinter NO-NO" (being witting or unwitting),
the user of IDLE should *NEVER* be forced to kill processes
because:
THERE MUST BE A BETTER SOLUTION!
And this bug is making the whole Python community look like
a bunch of amateurs!
> I believe there is a proposal to be able to clear the
> shell window. We just need to add "Clear and restart
> shell". There is also an idea to put help output in an
> output window. Undo-ing the result of hitting <enter>
> seems like a sensible extension of undoing the
> So sign the contributor agreement and volunteer to write
> and review patches.
I would be willing to help *IF* i received more thoughtful and
engaging replies like the type you always provide. Thank you
Terry for continuing to be a valuable and welcoming resource
for this community! If not for you and a handful of others,
i would have given up on this community a long time ago.
NOBODY IS GOING TO HELP WHEN THEY GET RESISTANCE!
I will visit the bug tracker again and see if i can provide
some assistance there. Although, the last time i visited, i
remember being annoyed by the tracker interface -- which i
feel is overly noisy and far too complicated. All we need is
a flat list of issues. Is there some method to export
something more "readable"? Or, some sort of documentation?
I must admit, my excitement to help is usually depleted by
the tracker interface before i even have a chance to offer
anything substantial.
If this bug tracker does not improve, i will be forced to
continue posting my grievances here.
[toc] | [prev] | [next] | [standalone]
| From | Chris Angelico <rosuav@gmail.com> |
|---|---|
| Date | 2014-07-20 02:41 +1000 |
| Message-ID | <mailman.12048.1405788095.18130.python-list@python.org> |
| In reply to | #74819 |
On Sun, Jul 20, 2014 at 2:29 AM, Rick Johnson <rantingrickjohnson@gmail.com> wrote: > On versions 2.7.2 and 3.2.2 CONTROL+LEFT_ARROW is landing > *properly* in front of the prompt, so apparently that bug was > fixed since last i checked, my apologies for being ignorant > of the situation, but you should understand that i had given > up after years of no improvements. Standard rule: Before complaining about something, upgrade to the latest version - at least the latest bugfix version of that branch. That would be 2.7.8 and either 3.2.5 or 3.4.1. Complaining about a bug in an old release is quite pointless if that bug has already been fixed. > However, a *bare* HOME_KEY press is placing the insertion > cursor *BEHIND* the prompt of the current line. In a shell > environment, you never want to be *BEHIND* the command > prompt. I don't know about the old versions, but in 3.4, it seems to be set so the Home key toggles between the beginning of the code and the beginning of the line. Seems a useful feature, although I can understand if you'd want to disable it and set the Home key to only ever go to the beginning of code. But that's a configuration question; this does not appear to be a bug. > But my point is: We *MUST* remove this *excessive* > indentation width from the IDLE shell! Why *must*? Is it really that big a problem? > THERE MUST BE A BETTER SOLUTION! > > And this bug is making the whole Python community look like > a bunch of amateurs! Frankly, I doubt it. It's pretty obscure. Yes, all bugs should be fixed where possible, but something of the nature you're describing does NOT make Python look bad. (Side point: There's nothing bad about being an amateur. I don't know why so many people think it's an insulting term.) ChrisA
[toc] | [prev] | [next] | [standalone]
| From | Ian Kelly <ian.g.kelly@gmail.com> |
|---|---|
| Date | 2014-07-19 12:00 -0600 |
| Message-ID | <mailman.12052.1405792879.18130.python-list@python.org> |
| In reply to | #74819 |
On Sat, Jul 19, 2014 at 10:41 AM, Chris Angelico <rosuav@gmail.com> wrote: >> However, a *bare* HOME_KEY press is placing the insertion >> cursor *BEHIND* the prompt of the current line. In a shell >> environment, you never want to be *BEHIND* the command >> prompt. > > I don't know about the old versions, but in 3.4, it seems to be set so > the Home key toggles between the beginning of the code and the > beginning of the line. Seems a useful feature, although I can > understand if you'd want to disable it and set the Home key to only > ever go to the beginning of code. But that's a configuration question; > this does not appear to be a bug. I'd say that moving the cursor to a position where you can't type is a bug. In that case, "beginning of the line" should be understood to be after the prompt. I see the use for it in an editing environment (I have an Emacs macro that does the same thing), but I don't really see the point of having the same feature in the shell other than for harmless consistency.
[toc] | [prev] | [next] | [standalone]
| From | Rick Johnson <rantingrickjohnson@gmail.com> |
|---|---|
| Date | 2014-07-19 13:39 -0700 |
| Message-ID | <abd0d54d-ee8f-4483-9def-4f08492db2ec@googlegroups.com> |
| In reply to | #74819 |
[A missed point from my last reply...] Terry Reedy said: > I believe there is a proposal to be able to clear the > shell window. We just need to add "Clear and restart > shell". A command that allows clearing the *entire* shell display and also resets the global and local symbol tables, *WITHOUT* requiring a re- start of the entire IDLE application, would be a great addition! However, sometimes you just want to remove the displayed result of the *LAST* command executed --for instance, in the case of accidentally printing a *very large* data structure-- and i believe this "output undo action" should be clearly *DISTINCT* from your normal "edit undo" actions via: "CONTROL+Z" To solve this dilemma in *MY* command shell, i use the "ALT+UP_ARROW" to delete everything from the "last command prompt" to the "end of the text buffer". I think IDLE needs both functionality! > There is also an idea to put help output in an > output window. I believe more windows just creates more confusion for the user. Sometimes you have no choice but add additional "views", however, in this case at least, i believe a menu command (coupled with a keyboard event) is the only solution that can keep the interface "manageable".
[toc] | [prev] | [next] | [standalone]
| From | Chris Angelico <rosuav@gmail.com> |
|---|---|
| Date | 2014-07-20 09:13 +1000 |
| Message-ID | <mailman.12068.1405811645.18130.python-list@python.org> |
| In reply to | #74835 |
On Sun, Jul 20, 2014 at 6:39 AM, Rick Johnson <rantingrickjohnson@gmail.com> wrote: > To solve this dilemma in *MY* command shell, i use the > "ALT+UP_ARROW" to delete everything from the "last command > prompt" to the "end of the text buffer". I think IDLE needs > both functionality! Okay, now I understand Rick's attitude. So long as Idle has one single bug of which he is aware, or lacks one single feature which he can think of, it is an utter and total embarrassment to the entire Python community - not just those who work to make Idle what it is, but also everyone who uses Idle... and everyone who doesn't use Idle, too. Rick, start writing patches, and stop moaning like this just because someone hasn't thought of something you've thought of. It may or may not even be worth implementing this, but definitely you have the wrong attitude toward feature requests. ChrisA
[toc] | [prev] | [next] | [standalone]
| From | Terry Reedy <tjreedy@udel.edu> |
|---|---|
| Date | 2014-07-19 16:45 -0400 |
| Subject | Improving Idle (was Re: Python 3 ...) |
| Message-ID | <mailman.12062.1405802752.18130.python-list@python.org> |
| In reply to | #74819 |
On 7/19/2014 12:29 PM, Rick Johnson wrote: > On Friday, July 18, 2014 8:21:36 PM UTC-5, Terry Reedy wrote: > >> What ancient version, or oddball system are you using? For >> me, Win 7, both 2.7.8 and 3.4.1 "CONTROL+LEFT_ARROW" and >> the cursor is before the 'a' of [>>> abc]. The HOME key >> goes to the same place first, and they before >>> on the >> second press (and before 'a' on the third). > > On versions 2.7.2 and 3.2.2 These are ancient versions from years ago that no one should be running Idle on now. Before you say another word about Idle, and I mean this literally, update to current versions. There have been about 80 issues fixed since 2.7.2 and well more than 100 patches pushed. > CONTROL+LEFT_ARROW is landing *properly* in front of the prompt, Re-read my comment that you quoted. This has been fixed. > But my point is: We *MUST* remove this *excessive* > indentation width from the IDLE shell! To repeat: I agree, Raymond Hettigner agrees, everyone seems to agree, and we all have for years. http://bugs.python.org/issue7676 is over 4 years old. But a patch can only implement a specific new behavior, not just 'stop the old'. >> I cannot connect [your complaint about IDLE hanging] to >> behavior I have seen. > > IDLE will hang when editing Tkinter code. It seems to happen > most often in two cases: If you are running your tkinter code in the same process with Idle's tkinter code, either with ancient Idle or the '-n' startup option (possibly buried in a script), the situation is hopeless. If you are running your code in a separate process (now the default), then, most likely, Idle is not hanging. It is just waiting for your hung process. If so, Shell / Restart shell (^F6) will end the user process and start a new one. > 1. When running code that results in a Tkinter error. > > This can happen when mixing the "grid" and "pack" geometry > managers within the same "container" widget, which is a > Tkinter NO-NO, but it can also happen during other Tkinter > errors! The user process might hang trying to display a message from *tk*, as oppose to Python code, including tkinter. If you start Idle in a console window with 'python -m idlelib' or in the console interpreter with 'import idlelib.idle', you might see messages from tk, as I sometimes do (especially with a repository debug build). > 2. During "quickly successive" back-to-back "run sessions" > of Tkinter GUI apps. > > It seems that sometimes, if you don't give IDLE enough > time to release resources from the *LAST* run session, it > will freeze and then throw a "sub-process connection > failure" message, which, sometimes you can remedy by just > "trying again", but all to often you are forced to kill > the entire IDLE (and related sub-) processes. Use one of the startup options directly above to see if you can get more information. A repeatable or at least semi-repeatable failure case is needed to do anything. > However, *EVEN* in the instances where a problem is a direct > result of a "Tkinter NO-NO" (being witting or unwitting), > the user of IDLE should *NEVER* be forced to kill processes If you are talking about user processes, and we are talking about patching Idle, as opposed to Python or the OS (such as Windows), I disagree. If you are talking about the Idle process, then yes, I would prefer that once Idle starts, it run forever, and recover from any problems caused by users. Roger Serwy fixed many Idle shutdowns before being swallowed by a PhD program a year ago, but there is more to do. >> I believe there is a proposal to be able to clear the >> shell window. We just need to add "Clear and restart >> shell". There is also an idea to put help output in an >> output window. Undo-ing the result of hitting <enter> >> seems like a sensible extension of undoing the > >> So sign the contributor agreement and volunteer to write >> and review patches. In particular, go to https://www.python.org/psf/contrib to read *about* the contributor agreement and then go to https://www.python.org/psf/contrib-form/ (when the page is working -- it is not at the moment) with Javascript turned on to submit on-line (or submit by old-fashioned s-mail). When the form is processed, the Contributor Form Received field of your user profile at http://bugs.python.org/user12501 will be updated. Also, please update the email on that page to your current one. We are much stricter about getting Contributor Agreements than we used to be. I will usually not look as non-trivial patches until the author has at least signed the agreement and will not commit until it is recorded. > I would be willing to help *IF* i received more thoughtful and > engaging replies like the type you always provide. On the tracker at least, be polite and ignore impolite posts. I get them occasionally. > NOBODY IS GOING TO HELP WHEN THEY GET RESISTANCE! PEP 434 negated some forms of Idle resistance. However, it did not stop resistance in the form of criticism based on how Idle was (or might have been) years ago. > I will visit the bug tracker again and see if i can provide > some assistance there. Although, the last time i visited, i > remember being annoyed by the tracker interface -- which i > feel is overly noisy and far too complicated. The tracker could stand improvement, and there is a meta-tracker for that, though not many devs work on it. There is an infrastructure committee working on overhauling the entire workflow process, not just the tracker. In the meanwhile, the tracker serves to keep track of issue and patches well enough to get some work done. > All we need is > a flat list of issues. Is there some method to export > something more "readable"? If you do a search, such as for open issues with component 'Idle', the results page has a button to download *all* the results, not just those displayed, as a .csv file. Do whatever you want with that. > Or, some sort of documentation? The Tracker Documentation link at the bottom of the left margin now goes to https://docs.python.org/devguide/triaging.html. Most of the page is only relevant when opening an issue or editing the headers. The last section is relevant for posting messages. How to upload a patch (the Browse button) is not described. > I must admit, my excitement to help is usually depleted by > the tracker interface before i even have a chance to offer > anything substantial. Buck up ;-) > If this bug tracker does not improve, i will be forced to > continue posting my grievances here. As long as you base them on current Idle and are specific, that's fine. Patches you must upload yourself, for the responsibility trail. -- Terry Jan Reedy
[toc] | [prev] | [next] | [standalone]
| From | Rick Johnson <rantingrickjohnson@gmail.com> |
|---|---|
| Date | 2014-07-19 18:31 -0700 |
| Subject | Re: Improving Idle (was Re: Python 3 ...) |
| Message-ID | <64e2ac85-5c95-4834-b140-2189b884fb02@googlegroups.com> |
| In reply to | #74836 |
On Saturday, July 19, 2014 3:45:07 PM UTC-5, Terry Reedy wrote:
> On 7/19/2014 12:29 PM, Rick Johnson wrote:
> [2.7.2 and 3.2.2] are ancient versions from years ago that
> no one should be running Idle on now.
I have just downloaded and installed versions 2.7.8 and
3.4.1, and i am happy to report that both the "HOME_KEY"
*AND* the "CONTROL+LEFT_ARROW" events are working properly
and intuitively. I also would like to give my deepest
gratitude and thanks to those who corrected these
abnormalities!
KEEP UP THE GOOD WORK GUYS!
> To repeat: I agree [that tab indention is bad], Raymond
> Hettigner agrees, everyone seems to agree, and we all have
> for years. http://bugs.python.org/issue7676 is over 4
> years old. But a patch can only implement a specific new
> behavior, not just 'stop the old'.
Just checked 3.4.1, and it is still using a tab for
indention. I know this issue is going to be a bit more
trouble to solve than the previous two "event" issues that i
mentioned, however, i feel it is an important issue to
solve.
To understand *HOW* we might resolve this issue, *FIRST* we
must understand the origins of the issue -- and as such, a
few basic "rules" of how the IDLE shell "interacts" with a
user is prerequisite.
1. The shell presents a prompt (in the case of the IDLE
shell the prompt is ">>> "), as a "starting" point for
interactive commands.
2. The user begins typing his command at the prompt...
2a. In the process of typing his command, each time the
user presses the "ENTER" or "RETURN" keys (which i shall
from now on refer to them *singularly* as the: "ER-
KEYS"), the shell "intuits" whether the user intended to
complete his command "at-the-current-line" *OR* that the
user intends to "continue-writing-more-code", on
subsequent lines.
Note: As you can see the actions taken by pressing the
"ER-KEYS" depend on the context in which they where
pressed! If the command is "believed" to be *COMPLETE*,
then the action will be: "evaluate the users command now
and display a result", however, if the command is
"believed" to be *INCOMPLETE*, the action will be:
"allow the user to continue entering his command".
2b. If the "shell" believes that the user is finished
writing his command, the shell will evaluate the
*ENTIRETY* of the command (which could span one or more
lines!) and then display the result of that evaluation
*BENEATH* the command, however, if the shell "believes"
that the user intends to "continue-writing-more-code",
then the shell will allow the user to continue writing
more code.
STEP[N:]. There is much more to the interaction between
"shells" and "users", however, these first two steps, and
their subsequent "sub-steps", are all we need to concern
ourselves with at this time, in order to solve *THIS*
particular problem.
Now, between the "shell" and its "user" exists a contract,
and the preceding steps i outlined describe most of thast
contract, however, i realized that i can describe the full
contract more clearly by conflating the "shell" with "god"
and the "user" as some poor disciple. If we view the
contract through "the eyes of a *GODLIKE* shell" it might
read something like:
And the "shell" so-eth declared:
Ye shall be presented with a prompt, and from that prompt
thou shalt humbly enter requests. When i find thouest
requests pleasing, i shall reward thou with my vast
knowledge by displaying to you the result utilizing an
esthetically pleasing shade of blue, HOWEVER, shall i find
thou request to be illogical or malformed, i shall punish
thou with furious displays of my rebukes, utilizing the
"fear color" of *BLOOD* red! And thou shalt know my name
is the SHELL!
Furthermore, ye shall not be allowed to edit previous
request, no matter how blasphemous they may be! No, they
shall live as a testimate to thouest ignorance, a *PUBLIC*
testiment for all to see -- until which time thou decideth
to terminate our contract.
Now that we understand the contract between "shells" and
"users" we can focus in on the problem. The problem
manifests itself when the user wants to write commands that
span *MORE* than one line. For instance, when i write the
first line of a "multi-line source code" like this:
>>> for x in range(10):
And then i press the "enter key", the current IDLE shell is
going to insert a tab char (not good!), when it *SHOULD*
have inserted a "buffer prompt" of some kind, and then
calculated the correct "extrapolation-indentation" (by
adding four to the indent of line #1, which is four!) for
this new line of code.
>>> for x in range(10):
... do_something
Notice the "buffer prompt" of "... ", after which follows
the "extrapolation indent" of " ", after which defines
the *BEGINNING* of my next command of "do_something"? Seems
simple enough huh? Oh but, my friend, *NOTHING* is simple in
this damn community is it!
============================================================
Summary of the attempts to solve "INDENTION ISSUE" (at IDLE Bugs)
============================================================
The comments on how to solve this problem read like a book
titled: "devils advocate for dummies".
IDEA_1: Hey, lets just use 8 space indention for the
*FIRST* level of indentation, and 4 space indention for
any *SUBSEQUENT* levels of indentation, that would not
solve the copy-paste problem *DIRECTLY*, however, it would
RESPONSE_1: Shhhhh! Are you nuts! Be quiet! We cannot
allow such easy remedies, because if we did, we would not
need a bug tracker! No sir, this software dev team takes
the protestant approach to problems -- we will suffer and
we will like it!!!
IDEA_2: Hey, lets just insert a "buffer prompt" for every
line that is *NOT* the *FIRST LINE* of the command, and
then use 4 spaces for indention... problem solved!
RESPONSE_2: Hardly! Can't do that because people cannot be
denied their "adolescent accessorizing" via font choice.
How can you expect people to use *ONLY* mono-spaced fonts,
i mean, geez, that's fascism! Besides, web-dings is vital
for the those of us who need to encrypt our code so
"peeping toms" cannot steal our snippets -- you never know
who might be watching!
>_>
<_<
IDEA_3: Hey, let's remove the embedded prompt from the
main shell window altogether and display it in a separate
"thin" area to the left -- sort of like how line numbers
are displayed in other IDEs. This would solve the copy
paste issue *AND* the indention issue. Plus, we can take
credit for Ricks idea from circa 2005, nobody listens to
him anyway!
RESPONSE_2: You fool! That would require *ACTUAL* skills
that we *DON'T* have. Only rr knows how to "lock" the
scrolling events of two Tkinter widgets, plus, he'd have
to change the underlying design of the entire shell
contract in such a *DRAMATIC* fashion that he'd be better
off just starting from scratch -- the IDLE source is a
discombobulated mess!
Does the IDLE bug-tracker exist to *SOLVE* problems or to
*PERPETUATE* them?
> If you are running your tkinter code in the same process
> with Idle's tkinter code, either with ancient Idle or the
> '-n' startup option (possibly buried in a script), the
> situation is hopeless. If you are running your code in a
> separate process (now the default), then, most likely,
> Idle is not hanging. It is just waiting for your hung
> process. If so, Shell / Restart shell (^F6) will end the
> user process and start a new one.
Now that i have the most current releases of both Python2
and Python3, i will use IDLE exclusively to determine if
this "hanging issue" has been resolved, and if it has, i
will go from IDLEs loudest dissenter, to it's most exuberant
supporter.
Granted, this "hanging" issue is not the *ONLY* remaining
issue, however, it is the *SOLE* issue that has motivated me
to stop using the software and write my own. I will only
change my position once i have not experienced this nuance
for a reasonable time... and only time will tell.
> Use one of the startup options directly above to see if
> you can get more information. A repeatable or at least
> semi-repeatable failure case is needed to do anything.
Yes. The very next time i get a hang, i'm going to post a
test case for all to see, so we might figure this out.
> > However, *EVEN* in the instances where a problem is a
> > direct result of a "Tkinter NO-NO" (being witting or
> > unwitting), the user of IDLE should *NEVER* be forced to
> > kill processes
> If you are talking about user processes, and we are
> talking about patching Idle, as opposed to Python or the
> OS (such as Windows), I disagree. If you are talking about
> the Idle process, then yes, I would prefer that once Idle
> starts, it run forever, and recover from any problems
> caused by users. Roger Serwy fixed many Idle shutdowns
> before being swallowed by a PhD program a year ago, but
> there is more to do.
My point is, that, when i run a Python program using
"IDLE->Run->Run Program", i expect that IDLE is going to
execute my program, catch any errors, and then report them
to me. What i don't expect, is that IDLE is going to hang,
freeze, churn, or totally go bonkers.
If IDLE, which is written in Python, cannot understand when
a Python program has failed, and take necessary actions to
exit cleanly *OR* allow the user to *MANUALLY* exit cleanly
at *ANY* time, then it is useless as an IDE, and should be
"repackaged" and "sold" as a "texteditor(with aspirations of
being an IDE one day)".
IF YOU CAN'T RUN WITH THE BIG DOGS, STAY ON THE PORCH!
PS: I do promise though to hold an optimistic view until
proven otherwise.
[toc] | [prev] | [next] | [standalone]
| From | Chris Angelico <rosuav@gmail.com> |
|---|---|
| Date | 2014-07-20 11:42 +1000 |
| Subject | Re: Improving Idle (was Re: Python 3 ...) |
| Message-ID | <mailman.12078.1405820558.18130.python-list@python.org> |
| In reply to | #74853 |
On Sun, Jul 20, 2014 at 11:31 AM, Rick Johnson <rantingrickjohnson@gmail.com> wrote: > Does the IDLE bug-tracker exist to *SOLVE* problems or to > *PERPETUATE* them? Definitely the latter. If it weren't for that tracker, bugs would just quietly die on their own. The PSU has a roster for feeding the bugs, changing their litter, and all other bug-related duties, and when someone goes on holidays and forgets to schedule a replacement, heaps of bugs just inexplicably die. (The PSU generally conceals this faux pas under the name of a "release".) ChrisA
[toc] | [prev] | [next] | [standalone]
| From | Mark Lawrence <breamoreboy@yahoo.co.uk> |
|---|---|
| Date | 2014-07-20 12:40 +0100 |
| Subject | Re: Improving Idle (was Re: Python 3 ...) |
| Message-ID | <mailman.12094.1405856412.18130.python-list@python.org> |
| In reply to | #74853 |
On 20/07/2014 02:42, Chris Angelico wrote: > On Sun, Jul 20, 2014 at 11:31 AM, Rick Johnson > <rantingrickjohnson@gmail.com> wrote: >> Does the IDLE bug-tracker exist to *SOLVE* problems or to >> *PERPETUATE* them? > > Definitely the latter. If it weren't for that tracker, bugs would just > quietly die on their own. The PSU has a roster for feeding the bugs, > changing their litter, and all other bug-related duties, and when > someone goes on holidays and forgets to schedule a replacement, heaps > of bugs just inexplicably die. (The PSU generally conceals this faux > pas under the name of a "release".) > > ChrisA > An alternative is that the PSU wait until some raving lunatic, sado-masochistic nutter who actually likes triaging comes only and bumps some of the sillier, lonely bugs, e.g a three year old failing test case on a buildbot. Result, bug is closed as out of date. Click on the stats link at bugs.python.org and observe the result of this crazy type of behaviour. -- My fellow Pythonistas, ask not what our language can do for you, ask what you can do for our language. Mark Lawrence --- This email is free from viruses and malware because avast! Antivirus protection is active. http://www.avast.com
[toc] | [prev] | [next] | [standalone]
| From | Terry Reedy <tjreedy@udel.edu> |
|---|---|
| Date | 2014-07-20 17:52 -0400 |
| Subject | Idle's Shell: prompts and indents (was ...) Idle users please read |
| Message-ID | <mailman.12099.1405893170.18130.python-list@python.org> |
| In reply to | #74853 |
On 7/19/2014 9:31 PM, Rick Johnson wrote:
> On Saturday, July 19, 2014 3:45:07 PM UTC-5, Terry Reedy wrote:
Idle's Shell currently uses a primary prompt ('>>> '), no secondary
prompt*, and tabs for indents. This is a compromise between conflicting
goals. It works but perhaps we can do better.
* The third paragraph below explains that Shell's prompt is a statement
prompt rather than line prompt, so that a secondary line prompt would
not be appropriate.
The problem with tabs is that tk displays them as a jump to the next
'tab stop'. For fixed pitch fonts, the virtual tab stops are set at 8
space intervals. For proportional fonts, I suspect the spacing is 8 em
quads, where an em quad is the height of the font, which is also about
the width of the widest character. An em quad is much larger than the
width of a space character, perhaps 4x larger and perhaps 1.5 times the
average width. Because of no secondary prompt, the first fixed-pitch
indent looks like an indent of 4 spaces after a 'secondary prompt' of '
', while subsequent indents are really 8 spaces. The indents appear
are uneven and the subsequent indents chew up screen width too quickly.
For proportional fonts, the problem is worst as the indents are about
12 characters.
>> http://bugs.python.org/issue7676
> indention. I know this issue is going to be a bit more
> trouble to solve than the previous two "event" issues
>
> To understand *HOW* we might resolve this issue, *FIRST* we
> must understand the origins of the issue
The problem originates in differences between the console - interactive
python interaction and Idle Shell - execution server interaction.
Interactive python prints prompts to and reads lines from the console.
Once the user submits a line by hitting return, it cannot be edited.
(This is true on Widows. Could any linux and mac user confirm for their
systems?)
The Idle Shell is much more active than at least the Windows console,
and it is statement rather than line oriented. This is the important
point. The Shell '>>> ' prompt is prompting for a complete statement,
not a single line. This difference of meaning should be documented if it
is not now.
Until a user indicates that a statement is completed, the user can edit
*any* part of the statement, not just the last line. While Shell
monitors keystrokes and modifies the text accordingly with color and
indents, it does not send the statement to the execution server, which
is running idle code in batch-mode python, until the statment is
complete. The execution server then exec()s the statement inside the
Executive.run_code method and sends and response back.
Being able to enter, edit, and recall complete statements is an valuable
Shell feature.
> The problem manifests itself when the user wants to write
> commands that span *MORE* than one line.
Right. Multiline statement issues go away when a statement is a single
line. Now to the ideas on the tracker.
> IDEA_1: Hey, lets just use 8 space indention for the
Or a tab for the first indent (this works if consistent)
> *FIRST* level of indentation, and 4 space indention for
> any *SUBSEQUENT* levels of indentation,
I am considering this as an option when the font is fixed pitch.
> that would not solve the copy-paste problem *DIRECTLY*,
The advantage of a single tab is that it is easy to turn it into 4
spaces either in a custom copy or after pasting.
> IDEA_2: Hey, lets just insert a "buffer prompt" for every
> line that is *NOT* the *FIRST LINE* of the command, and
> then use 4 spaces for indention... problem solved!
>
> RESPONSE_2: Hardly! Can't do that because people cannot be
> denied their "adolescent accessorizing" via font choice.
This idea, and your response, ignores the fact that Shell is *statement*
oriented. Inserting a secondary prompts inside statement text would mean
that they would have to first be protected from user editing and then
deleted by Idle before the statement is sent to the Executive.
> IDEA_3: Hey, let's remove the embedded prompt from the
> main shell window altogether and display it in a separate
> "thin" area to the left -- sort of like how line numbers
> are displayed in other IDEs. This would solve the copy paste
> issue *AND* the indention issue.
http://bugs.python.org/issue17535
GSOC Idle student Saimadhav Heblekar has worked on adding *optional*
line numbers to Idle editor windows. I plan to adapt the final patch to
the shell with, for instance '>>> ' and 'out:' labels.
As I said on the tracker, I think that output that is no longer dedented
with respect to input will then need some more to distinguish it. For my
copy of Idle, I have added blue and red background tint to standard and
error output and I think that works well.
> we can take credit for Ricks idea from circa 2005,
Ideas don't count until recorded on the tracker.
> RESPONSE_2: You fool! That would require *ACTUAL* skills
> that we *DON'T* have. Only rr knows how to "lock" the
> scrolling events of two Tkinter widgets,
Saimadhav has locked together a thin canvas with the text for line
numbers. It works in all my texts. I am just waiting for him to try it
with a thin text instead.
If you know some secret you think he missed. please describe it here.
Idea 4 (which I already suggested on the tracker). Put statement input
prompts and output separators on lines by themselves. As with 3. above,
use standard 4 space indents, as with
>>>:
def f(x):
if x:
print('got it')
return 'something'
>>>:
f(3)
---
got it
>>>:
Idle users other than Rick, any comments on the possible improvements?
--
Terry Jan Reedy
[toc] | [prev] | [next] | [standalone]
| From | Rick Johnson <rantingrickjohnson@gmail.com> |
|---|---|
| Date | 2014-07-20 18:22 -0700 |
| Subject | Re: Idle's Shell: prompts and indents (was ...) Idle users please read |
| Message-ID | <f3ff88de-7c72-436f-811a-ffe47b129267@googlegroups.com> |
| In reply to | #74884 |
On Sunday, July 20, 2014 4:52:36 PM UTC-5, Terry Reedy wrote:
> On 7/19/2014 9:31 PM, Rick Johnson wrote:
> > On Saturday, July 19, 2014 3:45:07 PM UTC-5, Terry Reedy wrote:
> * The third paragraph below explains that Shell's prompt
> is a statement prompt rather than line prompt, so that a
> secondary line prompt would not be appropriate.
Speaking strictly from the point of view of the *current*
IDLE implementation, yes.
> > To understand *HOW* we might resolve this issue, *FIRST* we
> > must understand the origins of the issue
> The problem originates in differences between the console
> - interactive python interaction and Idle Shell -
> execution server interaction
Actually, the "problem" you are describing is fundamentally
different from what i was talking about, but you *are* getting
closer to the *real* source of the design flaws that prevent
*easy* evolution of the IDLE software.
The *real* problem is that the "interactive events" of the
"editor window" and the "interactive events" of the "shell
window" are far too tightly integrated with one another.
I myself appreciate the finger saving principles of "DRY",
however, sometimes, two distinct functionalities just
cannot be implemented *IN A CLEAR MANNER* without repeating
*some* of the code.
We need to understand that IDLE is split into two distinct
"modes", if you will -- the "interactive shell" and the
"editor window". Attempting to use the same code to handle
keystrokes for the shell *AND* the editor is a stumbling
block to extending this mess.
Instead, IDLE needs two distinct "pipelines" for which
events for each *SIDE* of this "split personality" can be
*written* and later, easily *COMPREHENDED* by the
maintenance programmer.
Our "real problem" is discombobulation, and until we wrangle
the beast of discombobulation, we will never improve this
software in a meaningful or clear manner. Instead, we will
only render the software exponentially less readable.
YOU CANNOT IMPROVE ANY SOFTWARE UNTIL YOU CAN GROK IT'S SOURCE
> This idea, and your response, ignores the fact that Shell
> is *statement* oriented. Inserting a secondary prompts
> inside statement text would mean that they would have to
> first be protected from user editing and then deleted by
> Idle before the statement is sent to the Executive.
Yes and no. ;-)
Hiding the "secondary prompts" from the "execution server"
is as simple as running the "command" through a "cleaner
function" *BEFORE* it gets evaluated.
As for the other issue of protecting the user from editing
the "secondary prompts", all you need to do is add a few
bits of extra logic to the backspace and clipboard events. But
you *could* even just let the user be responsible for his
own mistakes and allow documentation handle that issue.
But either way, both can be achieved without a complete re-
write *OR* fundamental architecture re-design.
> Saimadhav Heblekar has worked on adding *optional* line
> numbers to Idle editor windows. I plan to adapt the final
> patch to the shell with, for instance '>>> ' and 'out:'
> labels. As I said on the tracker, I think that output that
> is no longer de-dented with respect to input will then need
> some more to distinguish it. For my copy of Idle, I have
> added blue and red background tint to standard and error
> output and I think that works well.
That sounds fine to me. There are many methods one can
utilize to differentiate input from output. And i like your
idea of input being black(with colorizer modification of
course), valid output as *ALL* blue, and error output as
*ALL* red.
> Ideas don't count until recorded on the tracker.
Hmm, okay.
> Saimadhav has locked together a thin canvas with the text
> for line numbers. It works in all my texts. I am just
> waiting for him to try it with a thin text instead. If you
> know some secret you think he missed. please describe it
> here.
How can i offer improvements if i don't know where to find
the code? And besides, if my comments here "don't count" i
will levy the punishment of Eric Theodore Cartman upon you:
SCREW YOU GUYS, I'M GOING HOME!
[toc] | [prev] | [next] | [standalone]
| From | Chris Angelico <rosuav@gmail.com> |
|---|---|
| Date | 2014-07-21 11:32 +1000 |
| Subject | Re: Idle's Shell: prompts and indents (was ...) Idle users please read |
| Message-ID | <mailman.12104.1405906336.18130.python-list@python.org> |
| In reply to | #74890 |
On Mon, Jul 21, 2014 at 11:22 AM, Rick Johnson <rantingrickjohnson@gmail.com> wrote: > How can i offer improvements if i don't know where to find > the code? Look in hg.python.org/cpython and see what you find. You never know, it might even be there! ChrisA
[toc] | [prev] | [next] | [standalone]
| From | Terry Reedy <tjreedy@udel.edu> |
|---|---|
| Date | 2014-07-20 23:49 -0400 |
| Subject | Re: Idle's Shell: prompts and indents (was ...) Idle users please read |
| Message-ID | <mailman.12115.1405914592.18130.python-list@python.org> |
| In reply to | #74890 |
On 7/20/2014 9:22 PM, Rick Johnson wrote: > On Sunday, July 20, 2014 4:52:36 PM UTC-5, Terry Reedy wrote: > The *real* problem is that the "interactive events" of the > "editor window" and the "interactive events" of the "shell > window" are far too tightly integrated with one another. > > I myself appreciate the finger saving principles of "DRY", > however, sometimes, two distinct functionalities just > cannot be implemented *IN A CLEAR MANNER* without repeating > *some* of the code. > > We need to understand that IDLE is split into two distinct > "modes", if you will -- the "interactive shell" and the > "editor window". Attempting to use the same code to handle > keystrokes for the shell *AND* the editor is a stumbling > block to extending this mess. Slightly simplifying, the shell window and output windows are subclasses of the current editor window. I have thought about making all three inherit from a base interactive window. This would be a bit cleaner than the current design. I am not convinced of the need for more drastic change. >> Ideas don't count until recorded on the tracker. Which, as I reported back here, is why I promptly included both your OutputUndo idea and suggestion for a separate event and shortcut key in a new issue on the tracker. > Hmm, okay. >> Saimadhav has locked together a thin canvas with the text >> for line numbers. It works in all my texts. I am just >> waiting for him to try it with a thin text instead. If you >> know some secret you think he missed. please describe it >> here. > > How can i offer improvements if i don't know where to find > the code? http://bugs.python.org/issue17535 > And besides, if my comments here "don't count" The ideas that I think are worth preserving and that I think are appropriate for the tracker I will put on the tracker. You can comment directly on the tracker yourself, but you would have to moderate your style. -- Terry Jan Reedy
[toc] | [prev] | [next] | [standalone]
| From | Chris Angelico <rosuav@gmail.com> |
|---|---|
| Date | 2014-07-21 10:55 +1000 |
| Subject | Re: Idle's Shell: prompts and indents (was ...) Idle users please read |
| Message-ID | <mailman.12100.1405904111.18130.python-list@python.org> |
| In reply to | #74853 |
On Mon, Jul 21, 2014 at 7:52 AM, Terry Reedy <tjreedy@udel.edu> wrote:
> On 7/19/2014 9:31 PM, Rick Johnson wrote:
> The problem originates in differences between the console - interactive
> python interaction and Idle Shell - execution server interaction.
> Interactive python prints prompts to and reads lines from the console. Once
> the user submits a line by hitting return, it cannot be edited. (This is
> true on Widows. Could any linux and mac user confirm for their systems?)
If you mean that individual lines are separately edited, then yes,
that's the same on Linux.
> The Idle Shell is much more active than at least the Windows console, and it
> is statement rather than line oriented. This is the important point. The
> Shell '>>> ' prompt is prompting for a complete statement, not a single
> line. This difference of meaning should be documented if it is not now.
This is, in fact, Idle's greatest feature IMO. The ability to recall,
edit, and resubmit an entire function/class definition as a single
unit.
> The advantage of a single tab is that it is easy to turn it into 4 spaces
> either in a custom copy or after pasting.
If you're weighing up those two options specifically, I would tip the
balance toward a custom copy. If you paste into some other
application, it would be more consistent to work with four spaces for
every indentation level, rather than having every line begin with a
tab and then some spaces.
> This idea, and your response, ignores the fact that Shell is *statement*
> oriented. Inserting a secondary prompts inside statement text would mean
> that they would have to first be protected from user editing and then
> deleted by Idle before the statement is sent to the Executive.
The secondary prompts are actually quite annoying in copy/paste.
Anything that suppresses them is a distinct advantage IMO.
> As I said on the tracker, I think that output that is no longer dedented
> with respect to input will then need some more to distinguish it. For my
> copy of Idle, I have added blue and red background tint to standard and
> error output and I think that works well.
I'd have to have a look and see how that feels before I can judge
properly, but the notion of output not being indented by a prompt is
one that's found on... well, pretty much everything. Most command-line
interfaces work that way. Good MUD clients work hard to make sure that
the user's input is correctly indented by the prompt, even if the two
are quite separate in chronology; if you use input("........") and
print(), you'll end up with the same kind of interface. Explaining the
difference in color will be different, so it'll have to work extra
well to make up for that. Also, you can copy and paste into an email,
which will lose color. Count me dubious but reserving judgment.
>> RESPONSE_2: You fool! That would require *ACTUAL* skills
>> that we *DON'T* have. Only rr knows how to "lock" the
>> scrolling events of two Tkinter widgets,
>
> Saimadhav has locked together a thin canvas with the text for line numbers.
> It works in all my texts. I am just waiting for him to try it with a thin
> text instead.
>
> If you know some secret you think he missed. please describe it here.
Huh, is combined scrolling really such an amazing thing? Only one
person in the whole world knows how to do it? So.... like this:
http://www.phdcomics.com/comics/archive.php?comicid=1723
http://catb.org/esr/writings/unix-koans/mcse.html
Considering that some GUI toolkits have that functionality as a core
feature (GTK scrolling is a bit more complex to support this exact
concept), I would be very much surprised if exactly one person knows
how to do it in Tk.
> Idea 4 (which I already suggested on the tracker). Put statement input
> prompts and output separators on lines by themselves. As with 3. above, use
> standard 4 space indents, as with
>
>>>>:
> def f(x):
> if x:
> print('got it')
> return 'something'
>
>>>>:
> f(3)
> ---
> got it
>>>>:
>
> Idle users other than Rick, any comments on the possible improvements?
I can't comment on how it interacts with the editor half of Idle, but
for the shell as a stand-alone app, and for copying and pasting into
other programs, this last idea is rather interesting. I'm broadly
happy with the current system (>>> def f(x):), and the prompt is a
little weird (">>>:"? but maybe "Python:" would be less weird; I don't
advise "Idle:" as it implies that something is idle that might be
busy), but this would make copy/paste that bit easier. It would tend
to de-emphasize the difference between input and output, though, which
may or may not be an issue. But definitely interesting.
ChrisA
[toc] | [prev] | [next] | [standalone]
| From | Terry Reedy <tjreedy@udel.edu> |
|---|---|
| Date | 2014-07-20 23:28 -0400 |
| Subject | Re: Idle's Shell: prompts and indents (was ...) Idle users please read |
| Message-ID | <mailman.12113.1405913319.18130.python-list@python.org> |
| In reply to | #74853 |
On 7/20/2014 8:55 PM, Chris Angelico wrote:
>> Idea 4 (which I already suggested on the tracker). Put statement input
>> prompts and output separators on lines by themselves. As with 3. above, use
>> standard 4 space indents, as with
>>
>>>>> :
>> def f(x):
>> if x:
>> print('got it')
>> return 'something'
>>
>>>>> :
>> f(3)
>> ---
>> got it
>>>>> :
>>
>> Idle users other than Rick, any comments on the possible improvements?
Note that single multiline statements can be directly copied for pasting
by the normal method.
> I can't comment on how it interacts with the editor half of Idle, but
> for the shell as a stand-alone app, and for copying and pasting into
> other programs, this last idea is rather interesting. I'm broadly
> happy with the current system (>>> def f(x):), and the prompt is a
> little weird (">>>:"? but maybe "Python:" would be less weird; I don't
> advise "Idle:" as it implies that something is idle that might be
> busy), but this would make copy/paste that bit easier. It would tend
> to de-emphasize the difference between input and output, though, which
> may or may not be an issue. But definitely interesting.
The prompt and separator could be configurable.
A few users have noticed (and complained) that setting sys.ps1 and
sys.ps2 *in the batch mode user process* has no effect. The Idle doc
should better explain why this is and should be. User code should not
affect the operation of Idle. Idle is separately configured through dialogs.
--
Terry Jan Reedy
[toc] | [prev] | [next] | [standalone]
| From | Chris Angelico <rosuav@gmail.com> |
|---|---|
| Date | 2014-07-21 13:34 +1000 |
| Subject | Re: Idle's Shell: prompts and indents (was ...) Idle users please read |
| Message-ID | <mailman.12114.1405913649.18130.python-list@python.org> |
| In reply to | #74853 |
On Mon, Jul 21, 2014 at 1:28 PM, Terry Reedy <tjreedy@udel.edu> wrote: > A few users have noticed (and complained) that setting sys.ps1 and sys.ps2 > *in the batch mode user process* has no effect. The Idle doc should better > explain why this is and should be. User code should not affect the > operation of Idle. Idle is separately configured through dialogs. As I understand it, setting them has *absolutely* no effect, currently, right? There's no situation in which it would be useful to set them? In that case, it might be useful to put some magic in there (although I'm not sure it's possible; can't use @property at top level in a module) that gives a notification - pointing users to the dialog. No idea how you'd go about it, but telling someone when what s/he does is useless can be helpful. ChrisA
[toc] | [prev] | [next] | [standalone]
Page 9 of 17 — ← Prev page 1 … 7 8 [9] 10 11 … 17 Next page →
Back to top | Article view | comp.lang.python
csiph-web