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 5 of 17 — ← Prev page 1 … 3 4 [5] 6 7 … 17 Next page →
| From | Marko Rauhamaa <marko@pacujo.net> |
|---|---|
| Date | 2014-07-15 20:38 +0300 |
| Message-ID | <87zjga4j4v.fsf@elektro.pacujo.net> |
| In reply to | #74486 |
Chris Angelico <rosuav@gmail.com>: > Fine. Tell me how you would go about adding true Unicode support to > Python 2.7, while still having it able to import an unchanged program. > Trick question - it's fundamentally impossible, because an unchanged > program will not distinguish between bytes and text, but true Unicode > support requires that they be distinguished. Python 2 has always had unicode strings and [byte] strings. They were always clearly distinguished. You really didn't have to change anything for "true Unicode support". > you may as well go straight to Py3 and take advantage of its features. The first real new feature in Python 3 is asyncio. I've been perfectly happy with select.epoll myself and written my own 50-line asyncio equivalents so it remains to be seen how much traction asyncio will have. Marko
[toc] | [prev] | [next] | [standalone]
| From | Steven D'Aprano <steve+comp.lang.python@pearwood.info> |
|---|---|
| Date | 2014-07-15 19:06 +0000 |
| Message-ID | <53c57bae$0$9505$c3e8da3$5496439d@news.astraweb.com> |
| In reply to | #74494 |
On Tue, 15 Jul 2014 20:38:40 +0300, Marko Rauhamaa wrote:
> Python 2 has always had unicode strings and [byte] strings. They were
> always clearly distinguished. You really didn't have to change anything
> for "true Unicode support".
If that were true, then migrating from Python 2 to 3 would be much
simpler than it is.
Unicode strings in Python 2 are second class entities. It's not just that
people will, in general, take the lazy way and write "foo" instead of
u"foo" for their strings. But it is that the whole Python virtual machine
is based on byte-strings, not Unicode strings, and u"" strings are bolted
on top.
[steve@ando ~]$ python3.3 -c "π = 3.14; print(π+1)"
4.140000000000001
[steve@ando ~]$ python2.7 -c "π = 3.14; print(π+1)"
File "<string>", line 1
π = 3.14; print(π+1)
^
SyntaxError: invalid syntax
Python 2 "helpfully" tries to guess what you want when you work with
bytes-pretending-to-be-strings, and when it guesses right, it's nice, but
when it guesses wrongly, you'll left with mysterious encoding and
decoding errors from code that don't appear to involve either. The whole
thing is a mess.
--
Steven
[toc] | [prev] | [next] | [standalone]
| From | Marko Rauhamaa <marko@pacujo.net> |
|---|---|
| Date | 2014-07-15 23:01 +0300 |
| Message-ID | <87iomy4ciy.fsf@elektro.pacujo.net> |
| In reply to | #74502 |
Steven D'Aprano <steve+comp.lang.python@pearwood.info>: > Unicode strings in Python 2 are second class entities. I don't see that. They form a type just like, say, complex. > It's not just that people will, in general, take the lazy way and > write "foo" instead of u"foo" for their strings. People live with their choices, and I don't see the consequences of that lazy way as very bad. In fact, I find the lazy use of Unicode strings at least as scary as the lazy use of byte strings, especially since Python 3 sneaks Unicode to the outer interfaces of the program (files, IPC). > But it is that the whole Python virtual machine is based on > byte-strings, not Unicode strings, and u"" strings are bolted on top. The internal implementation of the VM is free to change as long as the external semantics stay the same. > [steve@ando ~]$ python3.3 -c "π = 3.14; print(π+1)" > 4.140000000000001 > [steve@ando ~]$ python2.7 -c "π = 3.14; print(π+1)" > File "<string>", line 1 > π = 3.14; print(π+1) > ^ > SyntaxError: invalid syntax My native language uses ä and ö, but I don't see any pressing need to embed those characters in identifiers. > Python 2 "helpfully" tries to guess what you want when you work with > bytes-pretending-to-be-strings, and when it guesses right, it's nice, but > when it guesses wrongly, you'll left with mysterious encoding and > decoding errors from code that don't appear to involve either. The whole > thing is a mess. I can't think of a matching example. Marko
[toc] | [prev] | [next] | [standalone]
| From | Steven D'Aprano <steve+comp.lang.python@pearwood.info> |
|---|---|
| Date | 2014-07-16 03:51 +0000 |
| Message-ID | <53c5f6dc$0$9505$c3e8da3$5496439d@news.astraweb.com> |
| In reply to | #74504 |
On Tue, 15 Jul 2014 23:01:25 +0300, Marko Rauhamaa wrote:
> Steven D'Aprano <steve+comp.lang.python@pearwood.info>:
>
>> Unicode strings in Python 2 are second class entities.
>
> I don't see that. They form a type just like, say, complex.
I didn't say they were a second class type. I choose my words carefully,
although I guess what I was trying to get across may have been a bit
subtle, sorry about that. But if you read on, where I explain some of the
consequences, it should be clear: Python 2.x has the assumption that
strings are 8-bit deeply embedded in the compiler.
>> It's not just that people will, in general, take the lazy way and write
>> "foo" instead of u"foo" for their strings.
>
> People live with their choices, and I don't see the consequences of that
> lazy way as very bad.
The consequences are that it is too hard to write correct text handling
code in Python 2, and too many programs which assume that text=ASCII as
if it were 1965.
In the same way that a language like Python is supposed to make it hard
for programmers (good, lazy or careless programmers) to write code with
(say) buffer overflow bugs, so a language like Python is supposed to make
it hard for programmers to write code that assumes that text is 8-bit. It
is disgraceful that in 2014 there are still languages like PHP that don't
know how to handle text, and Python fortunately is not one of them.
> In fact, I find the lazy use of Unicode strings at least as scary as the
> lazy use of byte strings, especially since Python 3 sneaks Unicode to
> the outer interfaces of the program (files, IPC).
I'm not entirely sure I understand what you mean by "lazy use of Unicode
strings". And I especially don't understand what you mean by "sneak". The
fact that strings are Unicode is *the* biggest and most obvious new
feature of Python 3.
>> But it is that the whole Python virtual machine is based on
>> byte-strings, not Unicode strings, and u"" strings are bolted on top.
>
> The internal implementation of the VM is free to change as long as the
> external semantics stay the same.
Which is the whole point. *They cannot*, or at least not without a level
of effort far beyond what is reasonable for an all-volunteer effort. And
even if they could, why bother when most developers will then ignore that
and use "" byte strings because it saves one character typing?
The Python devs aren't slaves, they get to choose what features they work
on and which they don't. They don't owe *anybody* any feature they don't
want to build, or care to support, and that includes continuing the 2.x
series. That leaves you with choices:
- You can follow the lead of the core developers and migrate to 3.x in
your own time, when it works for you.
- You can get enough people on the PSF board, and enough trusted, core
developers, that the old guard get pushed out and you can take over and
set the direction of Python development.
- You can hunker down and stick with Python 2 forever, and do without
free support after 2020.
- You can stick with Python 2 until 2020, or pay for support until 2023,
then reconsider the decision not to migrate.
- You can fork Python and take over support of MyPython 2.7.
- Or you can port your code to another language.
Perhaps the *stupidest* thing the author of the "Python 3 is killing
Python" blog post wrote was that it's easier to port Python code to a
*completely different language*. I cannot fathom the idiocy of somebody
who bitches and moans that having to re-write or redesign, oh, let's
conservatively say 5% of your Python 2 code is harder than writing your
code *completely from scratch* in a completely different language, with
completely different third party libraries.
And you can make that choice on a project-by-project basis.
As of right now, *new* projects ought to be written in Python 3.3 or
better, unless you have a compelling reason not to. You don't have to
port old projects in order to take advantage of Python 3 for new projects.
>> [steve@ando ~]$ python3.3 -c "π = 3.14; print(π+1)" 4.140000000000001
>> [steve@ando ~]$ python2.7 -c "π = 3.14; print(π+1)"
>> File "<string>", line 1
>> π = 3.14; print(π+1)
>> ^
>> SyntaxError: invalid syntax
>
> My native language uses ä and ö, but I don't see any pressing need to
> embed those characters in identifiers.
And good for you that you don't. I mean it. But there are 7 billion
people in the world, and they're not all Python programmers, but most
people are keen to program in their native tongues rather than English.
>> Python 2 "helpfully" tries to guess what you want when you work with
>> bytes-pretending-to-be-strings, and when it guesses right, it's nice,
>> but when it guesses wrongly, you'll left with mysterious encoding and
>> decoding errors from code that don't appear to involve either. The
>> whole thing is a mess.
>
> I can't think of a matching example.
[steve@ando ~]$ python2.7 -c "print u'π' + 'p'"
Ïp
Where did the Ï come from?
[steve@ando ~]$ python3.3 -c "print('π' + 'p')"
πp
--
Steven
[toc] | [prev] | [next] | [standalone]
| From | Chris Angelico <rosuav@gmail.com> |
|---|---|
| Date | 2014-07-16 14:20 +1000 |
| Message-ID | <mailman.11861.1405484445.18130.python-list@python.org> |
| In reply to | #74528 |
On Wed, Jul 16, 2014 at 1:51 PM, Steven D'Aprano <steve+comp.lang.python@pearwood.info> wrote: > Perhaps the *stupidest* thing the author of the "Python 3 is killing > Python" blog post wrote was that it's easier to port Python code to a > *completely different language*. I cannot fathom the idiocy of somebody > who bitches and moans that having to re-write or redesign, oh, let's > conservatively say 5% of your Python 2 code is harder than writing your > code *completely from scratch* in a completely different language, with > completely different third party libraries. There's only one way that it's easier to port to a completely new language. Pick another language where string handling is as naive as my last boss (who told me to make sure that my code was "eight-bit clean, that is to say, Unicode safe", and used the words "Unicode" and "UTF-8" as synonymous), and then you can continue to stick your head in the sand and pretend that ASCII is what matters, that "special characters" work because of the magic of UTF-8, and that oh, yeah, I guess we'd better occasionally test our code with a few of those annoyingly different characters, but ehh, it doesn't really matter much. Having been guilty of something like that (actually, in one program I assumed all the incoming text was CP-1252, so it really *was* byte==char), I am extremely aware of the problems that it causes. But it does make initial coding a lot easier - at the expense of debugging later, when you discover that some things don't work. The Py3 approach forces you to fix things up-front, and that's hard! But then there are no bugs. I know which one I'd rather. ChrisA
[toc] | [prev] | [next] | [standalone]
| From | Steven D'Aprano <steve@pearwood.info> |
|---|---|
| Date | 2014-07-16 07:33 +0000 |
| Message-ID | <53c62aaf$0$29897$c3e8da3$5496439d@news.astraweb.com> |
| In reply to | #74530 |
On Wed, 16 Jul 2014 14:20:37 +1000, Chris Angelico wrote: > On Wed, Jul 16, 2014 at 1:51 PM, Steven D'Aprano > <steve+comp.lang.python@pearwood.info> wrote: >> Perhaps the *stupidest* thing the author of the "Python 3 is killing >> Python" blog post wrote was that it's easier to port Python code to a >> *completely different language*. I cannot fathom the idiocy of somebody >> who bitches and moans that having to re-write or redesign, oh, let's >> conservatively say 5% of your Python 2 code is harder than writing your >> code *completely from scratch* in a completely different language, with >> completely different third party libraries. > > There's only one way that it's easier to port to a completely new > language. Pick another language where string handling is as naive as my > last boss But even then, you still have to re-write all your code in the new language. Using different libraries. All your unit tests are obsolete (although your integration tests may not be). End-user documentation will probably be re-usable, but documentation aimed at your developers will need to be re-written. -- Steven
[toc] | [prev] | [next] | [standalone]
| From | Marko Rauhamaa <marko@pacujo.net> |
|---|---|
| Date | 2014-07-16 08:52 +0300 |
| Message-ID | <87egxl4zq8.fsf@elektro.pacujo.net> |
| In reply to | #74528 |
Steven D'Aprano <steve+comp.lang.python@pearwood.info>: > On Tue, 15 Jul 2014 23:01:25 +0300, Marko Rauhamaa wrote: >> In fact, I find the lazy use of Unicode strings at least as scary as >> the lazy use of byte strings, especially since Python 3 sneaks >> Unicode to the outer interfaces of the program (files, IPC). > > I'm not entirely sure I understand what you mean by "lazy use of > Unicode strings". And I especially don't understand what you mean by > "sneak". The fact that strings are Unicode is *the* biggest and most > obvious new feature of Python 3. I mean that sys.stdin and sys.stdout should deal with byte strings. I mean that open(path) should open a file in binary mode. Thankfully, the subprocess methods exchange bytes by default. To me, the main difference between Python 2 and Python 3 is that in the former, I use "..." everywhere, and in the latter, I use b"..." everywhere. If I should need advanced text processing features, I'll go through a decode() and encode(). > The Python devs aren't slaves, they get to choose what features they > work on and which they don't. They don't owe *anybody* any feature > they don't want to build, or care to support, and that includes > continuing the 2.x series. No need to erect straw men. Of course, the Python gods do whatever they want. And you asked me to clarify my opinion, which I did. The breakage of backward compatibility wasn't worth the new features. But as I said, what is done is done. We'll live with the reality. > As of right now, *new* projects ought to be written in Python 3.3 or > better, unless you have a compelling reason not to. You don't have to > port old projects in order to take advantage of Python 3 for new > projects. But my distro only provides Python 3.2. What's wrong with Python 3.2? Why didn't anybody tell me to put off the migration? Marko
[toc] | [prev] | [next] | [standalone]
| From | Chris Angelico <rosuav@gmail.com> |
|---|---|
| Date | 2014-07-16 16:26 +1000 |
| Message-ID | <mailman.11864.1405491966.18130.python-list@python.org> |
| In reply to | #74533 |
On Wed, Jul 16, 2014 at 3:52 PM, Marko Rauhamaa <marko@pacujo.net> wrote: > Steven D'Aprano <steve+comp.lang.python@pearwood.info>: > >> On Tue, 15 Jul 2014 23:01:25 +0300, Marko Rauhamaa wrote: >>> In fact, I find the lazy use of Unicode strings at least as scary as >>> the lazy use of byte strings, especially since Python 3 sneaks >>> Unicode to the outer interfaces of the program (files, IPC). >> >> I'm not entirely sure I understand what you mean by "lazy use of >> Unicode strings". And I especially don't understand what you mean by >> "sneak". The fact that strings are Unicode is *the* biggest and most >> obvious new feature of Python 3. > > I mean that sys.stdin and sys.stdout should deal with byte strings. I > mean that open(path) should open a file in binary mode. Thankfully, the > subprocess methods exchange bytes by default. Let's take a step back from the standard I/O streams and look at this one concept: Asking the user to enter his/her name. The user will have a name which consists of characters (at least, we hope so; cases where this is not true do exist, but are outside the scope of this discussion), not bytes. The program wants to use those characters, not bytes. If I create a window with tkinter and ask the user to enter a name, I'll get back a Unicode string: http://www.python-course.eu/tkinter_entry_widgets.php (By the way, this suffers from the common flaw of asking for separate first and last names. That's not reliable in terms of people's names, but it's no different in terms of bytes and strings.) (Also by the way, why is a Python course advertising that its web site is written in PHP?) Whether I use Python 2 (changing the import to Tkinter) or Python 3 (running the code unchanged), I get back a Unicode string (easily proven by looking at its repr() in show_entry_fields()), because the user typed *text* into the widget. This is what everyone will expect. Now, the standard I/O streams might be connected to a console, or might be reading from a pipe. This does add a level of complexity, as it's possible to read either text or bytes from them; but Python defaults to the most common case, where they're connected to a console, and does its best to allow print() to write Unicode to any console. (With limited success on some consoles; Windows' cmd.exe has problems. That's not Python's fault.) If you want binary, you can easily switch to binary mode. Maybe it would be better to have a simple function "change standard stream(s) to binary", but the default is still correct: most of the time, you want to work with text. > To me, the main difference between Python 2 and Python 3 is that in the > former, I use "..." everywhere, and in the latter, I use b"..." > everywhere. If I should need advanced text processing features, I'll go > through a decode() and encode(). Why do you work with the underlying representation (bytes) instead of the abstraction (strings)? To be consistent, you should probably eschew Python dictionaries in favour of a manually-implemented hashtable, and studiously avoid Python source code by hand-writing CPython bytecode. >> As of right now, *new* projects ought to be written in Python 3.3 or >> better, unless you have a compelling reason not to. You don't have to >> port old projects in order to take advantage of Python 3 for new >> projects. > > But my distro only provides Python 3.2. What's wrong with Python 3.2? > Why didn't anybody tell me to put off the migration? It's pretty easy to spin up a CPython 3.4 for Debian Wheezy. Or you might be able to just grab a package from Jessie, where CPython 3.4 is standard. Debian, like Red Hat, values stability over currency, so once Wheezy went into freeze on 2012-06-30 [1], the current-at-the-time Python was locked in (Python 3.3 wasn't released until 2012-09-29 [2]), in order to allow packages to depend on it and be able to trust it. (It's possible you're not on Debian Wheezy, but on some other distro that also ships 3.2 with its current release. The policies are likely to be similar.) ChrisA [1] https://wiki.debian.org/DebianWheezy [2] https://www.python.org/download/releases/3.3.0/
[toc] | [prev] | [next] | [standalone]
| From | Marko Rauhamaa <marko@pacujo.net> |
|---|---|
| Date | 2014-07-16 09:44 +0300 |
| Message-ID | <87a9894xbc.fsf@elektro.pacujo.net> |
| In reply to | #74534 |
Chris Angelico <rosuav@gmail.com>: > Python defaults to the most common case, where they're connected to a > console, and does its best to allow print() to write Unicode to any > console. I don't know where you pull your statistics. Be that as it may, the main purpose of sys.stdin is to receive the workload and sys.stdout to deliver the goods. Marko
[toc] | [prev] | [next] | [standalone]
| From | Chris Angelico <rosuav@gmail.com> |
|---|---|
| Date | 2014-07-16 16:50 +1000 |
| Message-ID | <mailman.11865.1405493435.18130.python-list@python.org> |
| In reply to | #74535 |
On Wed, Jul 16, 2014 at 4:44 PM, Marko Rauhamaa <marko@pacujo.net> wrote: > Chris Angelico <rosuav@gmail.com>: > >> Python defaults to the most common case, where they're connected to a >> console, and does its best to allow print() to write Unicode to any >> console. > > I don't know where you pull your statistics. Heaps and HEAPS of personal experience, of myself and many other people. I frequently run programs that manipulate text and work with a console that displays text, which means that a consistent encoding (usually UTF-8) can be hidden away as an implementation detail. As long as the console correctly announces the encoding it expects and the program correctly writes in that encoding, all is well, and the program can simply "write text to the console". > Be that as it may, the main purpose of sys.stdin is to receive the > workload and sys.stdout to deliver the goods. Yes, but is that workload text or bytes? To be sure, there are programs whose stdin is usually or always bytes, but most use text. The default should be the most common and most useful option, and the alternative should be available when you want it. ChrisA
[toc] | [prev] | [next] | [standalone]
| From | wxjmfauth@gmail.com |
|---|---|
| Date | 2014-07-16 00:11 -0700 |
| Message-ID | <dd8a3260-3d07-40ea-8bc5-d8cd23d484e5@googlegroups.com> |
| In reply to | #74533 |
Le mercredi 16 juillet 2014 07:52:31 UTC+2, Marko Rauhamaa a écrit :
> Steven D'Aprano <steve+comp.lang.python@pearwood.info>:
>
>
>
> > On Tue, 15 Jul 2014 23:01:25 +0300, Marko Rauhamaa wrote:
>
> >> In fact, I find the lazy use of Unicode strings at least as scary as
>
> >> the lazy use of byte strings, especially since Python 3 sneaks
>
> >> Unicode to the outer interfaces of the program (files, IPC).
>
> >
>
> > I'm not entirely sure I understand what you mean by "lazy use of
>
> > Unicode strings". And I especially don't understand what you mean by
>
> > "sneak". The fact that strings are Unicode is *the* biggest and most
>
> > obvious new feature of Python 3.
>
>
>
> I mean that sys.stdin and sys.stdout should deal with byte strings. I
>
> mean that open(path) should open a file in binary mode. Thankfully, the
>
> subprocess methods exchange bytes by default.
>
>
>
> To me, the main difference between Python 2 and Python 3 is that in the
>
> former, I use "..." everywhere, and in the latter, I use b"..."
>
> everywhere. If I should need advanced text processing features, I'll go
>
> through a decode() and encode().
>
>
>
> > The Python devs aren't slaves, they get to choose what features they
>
> > work on and which they don't. They don't owe *anybody* any feature
>
> > they don't want to build, or care to support, and that includes
>
> > continuing the 2.x series.
>
>
>
> No need to erect straw men. Of course, the Python gods do whatever they
>
> want. And you asked me to clarify my opinion, which I did. The breakage
>
> of backward compatibility wasn't worth the new features.
>
>
>
> But as I said, what is done is done. We'll live with the reality.
>
>
>
> > As of right now, *new* projects ought to be written in Python 3.3 or
>
> > better, unless you have a compelling reason not to. You don't have to
>
> > port old projects in order to take advantage of Python 3 for new
>
> > projects.
>
>
>
> But my distro only provides Python 3.2. What's wrong with Python 3.2?
>
> Why didn't anybody tell me to put off the migration?
>
>
>
>
>
> Marko
-----------
From a unicode perspective, Py32 is the best
Python. (Yes it's ucs2).
(From a BDFL example)
>>> sys.version_info
sys.version_info(major=3, minor=2, micro=5, releaselevel='final', serial=0)
>>> timeit.repeat("a = 'hundred'; 'x' in a")
[0.09090468709446498, 0.07743860966057525, 0.07695655307486504]
>>> timeit.repeat("a = 'hundre EURO'; 'x' in a")
[0.09373873872100091, 0.07633783502242864, 0.0762649751626725]
sys.version_info
sys.version_info(major=3, minor=4, micro=0, releaselevel='final', serial=0)
timeit.repeat("a = 'hundred'; 'x' in a")
[0.1174619090622306, 0.09338822371994088, 0.09350361798433393]
timeit.repeat("a = 'hundre EURO'; 'x' in a")
[0.2306057883810979, 0.21599837108983877, 0.2168407886036121]
>>> sys.version_info
sys.version_info(major=3, minor=4, micro=0, releaselevel='final', serial=0)
>>> sys.getsizeof('hundred')
32
>>> sys.getsizeof('hundre EURO')
52
>>> sys.getsizeof('hundred')
44
>>> sys.getsizeof('hundre EURO')
44
Just an illustration of a systematical behaviour.
Not only Py32 works much better than Py33+,
it works much better for non ascii users!
The Py devs succeeded to transform Python into
a ascii product!
In my mind, it would be nicer to spend time in
solving bugs, instead of reinventing "unicode".
And before reinventing "unicode", it would be
good to undersand it (I fell by chance on
a video: "The Guts of Unicode in Python").
Hobbyist tools will alway stay hobbyist tools.
------
Something different, "micropython". Luckily
they are people who are understanding "unicode"
as whole very correctly and are not following
py devs advices. I'm thinking about this
UEFI stuff. It is beyond my knowledge. it seems to me
that it is a similar situation.
jmf
[toc] | [prev] | [next] | [standalone]
| From | Steven D'Aprano <steve@pearwood.info> |
|---|---|
| Date | 2014-07-16 07:49 +0000 |
| Message-ID | <53c62e7f$0$29897$c3e8da3$5496439d@news.astraweb.com> |
| In reply to | #74533 |
On Wed, 16 Jul 2014 08:52:31 +0300, Marko Rauhamaa wrote:
> Steven D'Aprano <steve+comp.lang.python@pearwood.info>:
>
>> On Tue, 15 Jul 2014 23:01:25 +0300, Marko Rauhamaa wrote:
>>> In fact, I find the lazy use of Unicode strings at least as scary as
>>> the lazy use of byte strings, especially since Python 3 sneaks Unicode
>>> to the outer interfaces of the program (files, IPC).
>>
>> I'm not entirely sure I understand what you mean by "lazy use of
>> Unicode strings". And I especially don't understand what you mean by
>> "sneak". The fact that strings are Unicode is *the* biggest and most
>> obvious new feature of Python 3.
>
> I mean that sys.stdin and sys.stdout should deal with byte strings.
There are certainly use-cases for stdin and stdout to use bytes, but
there are also use-cases for them to deal with strings. I'll certainly
grant you that there ought to be an easy way to get access to the binary
streams, but I think for a high-level language like Python, the default
should be text, not bytes.
> I mean that open(path) should open a file in binary mode. Thankfully,
> the subprocess methods exchange bytes by default.
Likewise for files: by default, I should be able to do this:
open("foo.txt", "w").write("foo bar baz")
and have something sensible happen. Although I'm open to the suggestion
that maybe the Pythonic way to do that should be:
print("foo bar baz", file="foo.txt")
Most programming languages I know of default to opening files in text
mode, not binary mode, and I don't see any strong reason for Python to go
against the tide there.
And I don't have an opinion on the subprocess module.
> To me, the main difference between Python 2 and Python 3 is that in the
> former, I use "..." everywhere, and in the latter, I use b"..."
> everywhere. If I should need advanced text processing features, I'll go
> through a decode() and encode().
Having len('λ') == 1 is not an advanced text processing feature.
[...]
>> As of right now, *new* projects ought to be written in Python 3.3 or
>> better, unless you have a compelling reason not to. You don't have to
>> port old projects in order to take advantage of Python 3 for new
>> projects.
>
> But my distro only provides Python 3.2. What's wrong with Python 3.2?
> Why didn't anybody tell me to put off the migration?
Nothing is "wrong" with Python 3.2, except in the sense that it's now
about 3 years old there are better versions (3.3 and 3.4) to choose from.
If you're wedded to the idea of only using the version of Python that
your distro supports, you may find yourself a version or four behind the
latest release. (Red Hat only recently stopped supporting a distro where
the system python was 2.3. Yay.)
--
Steven
[toc] | [prev] | [next] | [standalone]
| From | Chris Angelico <rosuav@gmail.com> |
|---|---|
| Date | 2014-07-16 18:44 +1000 |
| Message-ID | <mailman.11871.1405500282.18130.python-list@python.org> |
| In reply to | #74542 |
On Wed, Jul 16, 2014 at 5:49 PM, Steven D'Aprano <steve@pearwood.info> wrote:
> ... Although I'm open to the suggestion
> that maybe the Pythonic way to do that should be:
>
> print("foo bar baz", file="foo.txt")
>
And I would argue against that suggestion, having worked with a
language where that's the case. In REXX, you write to files using the
LINEOUT and CHAROUT functions (the former adds end-of-line after its
written content, the latter doesn't):
call lineout "foo.txt","foo bar baz"
/* or */
call charout "foo.txt","foo bar "
call lineout "foo.txt","baz"
And correspondingly, CHARIN and LINEIN to read from files. This is
nice and convenient, but it has a number of problems:
1) Hidden global state. Somewhere there's a mapping of file names to
open file handles, and it's not obvious.
2) Corollary: Surprising behaviour if you try to use a file twice in
one program.
3) Closing a file is sometimes unobvious. If you terminate the program
with open files, there's no problem, but if the program keeps running,
its files stay open.
4) Very VERY occasionally, you might run into a problem with too many
open files. (It should be noted that I learned REXX back in the 90s.
It's entirely possible that "too many open files" would be at some
insanely ridiculous number now.) At that point, you need to close
something... but how can you know?
Here's a REXX-style set of functions, implemented in Python:
# files.py
_filemap = {}
def _open(fn, mode): _filemap[fn] = open(fn, mode)
def charout(fn, s):
if fn not in _filemap: _open(fn, "w")
_filemap[fn].write(s)
def lineout(fn, s): charout(fn, s+"\n")
def charin(fn, n=1):
if fn not in _filemap: _open(fn, "r")
return _filemap[fn].read(n)
# Okay, the stream() function does a *lot* more than
# closing files, but that's all I'm implementing.
def stream(fn, *args):
if args != ["c","close"]: raise NotImplemented
del _filemap[fn]
That's more-or-less how REXX does things. There are a lot more
complications (I didn't implement LINEIN, which requires buffering -
more global state), but that's the basic layout. Now, that's already
scaring you a bit (all that global state!), but it gets worse: you
either have heaps of duplication all through your code (repeating the
file name in every output statement), or you have a variable with the
file name that functions as a cookie - it's the same as a file handle
integer, or a FILE *fp with the C stdio library, or a file object in
Python, or anything like that. Usage would be like this:
fn = "foo.txt"
print("foo bar baz", file=fn)
print("hello, world", file=fn)
close_file(fn)
Which has no significant improvement over the current:
f = open("foo.txt", "w")
print("foo bar baz", file=f)
print("hello, world", file=f)
f.close()
And it's worse, because if you put this into a function and return
early from it, the second form will garbage-collect f and close the
file, but the first form won't. That's a recipe for surprises down the
track.
There is a use-case where this is an improvement: you can have a
function that writes to a log file or something, and it doesn't need
to monitor state:
def some_func(...)
do_stuff()
if condition: print(some_state, file="some.log")
do_more_stuff()
With Python's normal style, this would need to either keep on opening
and closing the file (slow and inefficient), or keep track of an open
file object somewhere (global state). If you're going to have global
state anyway, then it's easier to push it to someone else. But I'd
much rather NOT have that state... not to mention the potential
problems from having aliases to the file. I've never tried, for
instance, opening a file using two equivalent names, but it'd probably
open the file twice. Even more confusion.
It's great to be open to suggestions. It's great to be able to discuss
them and figure out which ones are actually worth pursuing :)
ChrisA
[toc] | [prev] | [next] | [standalone]
| From | Steven D'Aprano <steve+comp.lang.python@pearwood.info> |
|---|---|
| Date | 2014-07-16 11:35 +0000 |
| Message-ID | <53c6638b$0$9505$c3e8da3$5496439d@news.astraweb.com> |
| In reply to | #74544 |
On Wed, 16 Jul 2014 18:44:38 +1000, Chris Angelico wrote:
> On Wed, Jul 16, 2014 at 5:49 PM, Steven D'Aprano <steve@pearwood.info>
> wrote:
>> ... Although I'm open to the suggestion that maybe the Pythonic way to
>> do that should be:
>>
>> print("foo bar baz", file="foo.txt")
>>
>>
> And I would argue against that suggestion, having worked with a language
> where that's the case.
[...]
> 1) Hidden global state. Somewhere there's a mapping of file names to
> open file handles, and it's not obvious.
Absolutely not! What do you take me for, the designer of REXX???
:-P
What I had in mind was for print to open the file in append mode, write,
then close the file. Something like this:
def print(*values, sep=' ', end='\n', file=sys.stdout, flush=False):
def write(f):
for value in values:
f.write(str(value) + sep)
f.write(end)
if flush:
f.flush()
if isinstance(file, (str, bytes)):
with open(file, 'a') as f:
write(f)
else:
write(f)
The downside of this is that it doesn't handle encodings and error
handlers, or any of the other, more obscure, arguments to open(). But
since print is intended as a convenience function, I'm okay with that. If
you need more than the default settings, you should open the file
yourself:
f = open('something.txt', 'w', encoding='UTF=32')
print("fe fi fo fum", file=f)
> 2) Corollary: Surprising
> behaviour if you try to use a file twice in one program.
Not with my idea. The only surprises are if you try to use it with the
filename from different threads, but that's a relatively advanced thing
to do. If you're using print from two threads at once, don't pass a file
name.
> 3) Closing a file is sometimes unobvious. If you terminate the program
> with open files, there's no problem, but if the program keeps running,
> its files stay open.
> 4) Very VERY occasionally, you might run into a problem with too many
> open files. (It should be noted that I learned REXX back in the 90s.
> It's entirely possible that "too many open files" would be at some
> insanely ridiculous number now.) At that point, you need to close
> something... but how can you know?
Neither of these will be a problem.
Well, technically, if you opened like a million threads, and had every
thread try to print to a different file name at the same time, that could
be a problem. But if you're doing that, you deserve whatever happens.
;-)
--
Steven
[toc] | [prev] | [next] | [standalone]
| From | Chris Angelico <rosuav@gmail.com> |
|---|---|
| Date | 2014-07-16 21:54 +1000 |
| Message-ID | <mailman.11875.1405511663.18130.python-list@python.org> |
| In reply to | #74547 |
On Wed, Jul 16, 2014 at 9:35 PM, Steven D'Aprano
<steve+comp.lang.python@pearwood.info> wrote:
> What I had in mind was for print to open the file in append mode, write,
> then close the file.
Ahh, okay. Very different from what I thought you were talking about,
and distinctly different in behaviour from REXX :)
In that case, it avoids the problems that I described, at the expense
of being potentially an attractive nuisance - imagine code like this:
for line in open("input.txt"):
print(transform(line), file="output.txt")
Looks like a really nice clean way to process a file, right? But it's
going to be horrendously slow.
Actually, this could be quite reasonably added as a feature of
print(). Could be monkey-patched in fairly easily
_origprint = print
def print(*a, **kw):
if isinstance(kw.get("file"), (str, bytes)):
with open(kw["file"], 'a') as f:
kw["file"] = f
_origprint(*a, **kw)
else:
_origprint(*a, **kw)
And it'd have its uses. The only risk would be if there's a file-like
object that's a subclass of either str or bytes, which admittedly *is*
theoretically possible...
ChrisA
[toc] | [prev] | [next] | [standalone]
| From | Marko Rauhamaa <marko@pacujo.net> |
|---|---|
| Date | 2014-07-16 13:46 +0300 |
| Message-ID | <871ttlfune.fsf@elektro.pacujo.net> |
| In reply to | #74542 |
Steven D'Aprano <steve@pearwood.info>:
> Likewise for files: by default, I should be able to do this:
>
> open("foo.txt", "w").write("foo bar baz")
>
> and have something sensible happen.
I'd prefer:
open("foo.txt", "wt").write("foo bar baz")
or:
open("foo.txt", "w", encoding="utf-8").write("foo bar baz")
or:
open("foo.txt", "w").write("foo bar baz".encode())
Python 3 really is on a mission to elevate text into the mainstream at
the expense of bytes. I'm guessing this is done primarily to promote the
cross-platform transparency of Python code.
For me, a linux system and network programmer, that layer of frosting
only gets in my way and I need to wash it off.
> Most programming languages I know of default to opening files in text
> mode, not binary mode, and I don't see any strong reason for Python to
> go against the tide there.
In unix and linux, there never was a separate text mode for files. When
you open a file, you open a file -- and stuff bytes in it. There is no
commonly accepted text file encoding. UTF-8 comes close to being a
standard, but I know somebody who sticks to an ISO-8859-1 locale.
> Having len('λ') == 1 is not an advanced text processing feature.
There are (relative rare) occasions where you'd like to treat text as
text. Then, it's nice to be able to move the data on the operating table
with .decode() and when the patient has been sewn back together, you can
release them with .encode().
More often, len(b'λ') is what I want.
Marko
[toc] | [prev] | [next] | [standalone]
| From | Steven D'Aprano <steve+comp.lang.python@pearwood.info> |
|---|---|
| Date | 2014-07-16 12:10 +0000 |
| Message-ID | <53c66ba8$0$9505$c3e8da3$5496439d@news.astraweb.com> |
| In reply to | #74546 |
On Wed, 16 Jul 2014 13:46:45 +0300, Marko Rauhamaa wrote:
> Python 3 really is on a mission to elevate text into the mainstream at
> the expense of bytes. I'm guessing this is done primarily to promote the
> cross-platform transparency of Python code.
Ahead of bytes? Possibly. At the expense of bytes? Certainly not. If
there is anything that you cannot conveniently do with bytes, that you
could do in Python 2, it's likely a bug, or at least an obviously missing
feature. The core devs recognise that they missed some use-cases (e.g.
mixed bytes and text) which is now harder than it should be, and are on a
mission to rectify that as much as possible within the constraints of
backward compatibility.
E.g. having b"abc"[0] return 97 instead of b"a" was probably a mistake,
but there are four versions of Python 3.x that do it that way and it's
too late to change until Python 5000. (Python 4 is unlikely to break
backwards compatibility in a big way.)
> For me, a linux system and network programmer, that layer of frosting
> only gets in my way and I need to wash it off.
Linux, like all Unixes, is primarily a text-based platform. With a few
exceptions, /etc is filled with text files, not binary files, and half
the executables on the system are text (Python, Perl, bash, sh, awk,
etc.).
www.catb.org/esr/writings/taoup/html/ch05s01.html
To say that *dealing with text* gets in your way on a Linux system is
rather like saying that you love Mac OS X except for its gosh-awful GUI
and APIs.
Of course, as a network programmer, you have to deal with bytes, so I'll
give you a bit of leeway.
>> Most programming languages I know of default to opening files in text
>> mode, not binary mode, and I don't see any strong reason for Python to
>> go against the tide there.
>
> In unix and linux, there never was a separate text mode for files. When
> you open a file, you open a file -- and stuff bytes in it. There is no
> commonly accepted text file encoding. UTF-8 comes close to being a
> standard, but I know somebody who sticks to an ISO-8859-1 locale.
And they should be dragged out into the street and beaten with a Clue
Stick. They're the sort of people who are holding us back from the
shining utopia of UTF-8 everywhere!
(only half joking)
But seriously, I cannot imagine any *rational* reason for using a legacy
encoding, but I'm willing to give this person the benefit of the doubt
that he's not a raving lunatic or old West European-centric curmudgeon
trying to deny the existence of the rest of the world.
http://i.imgur.com/UeZan.jpg
That being the case, then good luck to him. As far as everyone else:
http://www.utf8everywhere.org/
>> Having len('λ') == 1 is not an advanced text processing feature.
>
> There are (relative rare) occasions where you'd like to treat text as
> text.
o_O
Relatively rare. Like, um, email, news, html, Unix config files, Windows
ini files, source code in just about every language ever, SMSes, XML,
JSON, YAML, instant messenger apps, word processors... even *graphic*
applications invariably have a text tool. Now, it may be true that some
of those things may not use text under the hood, but even so, text is
ubiquitous.
Even binary protocols often include chunks of recognisable human-readable
text in them:
[steve@ando Pictures]$ hexdump -n 64 -C picture.jpg
00000000 ff d8 ff e0 00 10 4a 46 49 46 00 01 01 00 00 01 |......JFIF......|
00000010 00 01 00 00 ff e2 0f 38 49 43 43 5f 50 52 4f 46 |.......8ICC_PROF|
00000020 49 4c 45 00 01 01 00 00 0f 28 61 70 70 6c 02 10 |ILE......(appl..|
00000030 00 00 6d 6e 74 72 52 47 42 20 58 59 5a 20 07 de |..mntrRGB XYZ ..|
00000040
> Then, it's nice to be able to move the data on the operating table
> with .decode() and when the patient has been sewn back together, you can
> release them with .encode().
>
> More often, len(b'λ') is what I want.
Oh really? Are you sure? What exactly is b'λ'?
I couldn't have made up a better example of the confusion between bytes
and text if I had tried. Thank you.
--
Steven
[toc] | [prev] | [next] | [standalone]
| From | Chris Angelico <rosuav@gmail.com> |
|---|---|
| Date | 2014-07-16 22:55 +1000 |
| Message-ID | <mailman.11876.1405515780.18130.python-list@python.org> |
| In reply to | #74549 |
On Wed, Jul 16, 2014 at 10:10 PM, Steven D'Aprano
<steve+comp.lang.python@pearwood.info> wrote:
> Linux, like all Unixes, is primarily a text-based platform. With a few
> exceptions, /etc is filled with text files, not binary files, and half
> the executables on the system are text (Python, Perl, bash, sh, awk,
> etc.).
An interesting assertion. I know "half" is not meant to be an actual
estimate, but out of curiosity, I whipped up a quick script to figure
out just how many of my executables are text and how many aren't.
#!/usr/bin/env python3
import os, subprocess
text = binary = unknown = unreadable = 0
for path in os.environ["PATH"].split(":"):
for file in os.listdir(path):
fn = os.path.join(path, file)
try:
t = subprocess.check_output(["file", "-L", fn])
except subprocess.CalledProcessError:
print("Unreadable: %s" % fn)
unreadable += 1
continue
if isinstance(t, bytes): t = t.decode("ascii")
# Now to try to figure out what's text and what's binary.
if "text" in t:
# Most Unixes follow the convention of having "text" in
# the output of all files that can be safely blatted to
# a terminal - for instance, "ASCII text executable" is
# used to describe most shell scripts etc; this file is
# a "Python script, ASCII text executable". If I put in
# a non-ASCII char, the 'file' descr becomes changes to
# "Python script, UTF-8 Unicode text executable".
text += 1
elif "directory" in t:
# Ignore directories.
pass
elif "LSB executable" in t or "LSB shared object" in t:
binary += 1
else:
print(t.strip())
unknown += 1
print("%d text, %d binary" % (text, binary))
if unknown: print("Also %d unknowns, which are probably binary." % unknown)
if unreadable: print("Plus %d files that couldn't be read." % unreadable)
On my system, it says:
rosuav@sikorsky:~$ python3 exectypes.py
/usr/local/bin/youtube-dl: data
Unreadable: /usr/bin/wine-safe
/usr/bin/mptopdf: LaTeX auxiliary file,
/usr/bin/gvfs-less: Palm OS dynamic library data "#!/bin/sh"
Unreadable: /usr/bin/gserialver
1140 text, 2060 binary
Also 3 unknowns, which are probably binary.
Plus 2 files that couldn't be read.
So a bit more than a third of my executables are text. That's a pretty
high proportion, and not very far off the rough guesstimate of half.
(And I tried this on three other Linuxes I have around the house,
getting broadly the same proportion, although the numbers are quite
different.)
ChrisA
[toc] | [prev] | [next] | [standalone]
| From | wxjmfauth@gmail.com |
|---|---|
| Date | 2014-07-16 06:10 -0700 |
| Message-ID | <900505a4-dd65-473f-a092-2973e5d6d56e@googlegroups.com> |
| In reply to | #74549 |
Le mercredi 16 juillet 2014 14:10:16 UTC+2, Steven D'Aprano a écrit :
> ...
You are right iso-8859-1 is a plague.
py340
>>> timeit.repeat("'abc'.find('z')")
[0.3915996913892741, 0.3671049942086313, 0.3669506100733315]
>>> timeit.repeat("'abc'.find('oe')")
[0.5678031885837811, 0.5447948325424363, 0.5424782828388004]
note py325
>>> timeit.repeat("'abc'.find('z')")
[0.34638522543825445, 0.32732154158861704, 0.3253417225882629]
>>> timeit.repeat("'abc'.find('oe')")
[0.3162405415102256, 0.3027008165424263, 0.30290324880145647]
py340
>>> sys.getsizeof('z'*123 + 'z')
149
>>> sys.getsizeof('z'*123 + 'oe')
286
py325
>>> sys.getsizeof('z'*123 + 'z')
278
>>> sys.getsizeof('z'*123 + 'oe')
278
Brillant no?
jmf
[toc] | [prev] | [next] | [standalone]
| From | Marko Rauhamaa <marko@pacujo.net> |
|---|---|
| Date | 2014-07-16 16:11 +0300 |
| Message-ID | <87sim1e9dt.fsf@elektro.pacujo.net> |
| In reply to | #74549 |
Steven D'Aprano <steve+comp.lang.python@pearwood.info>:
> With a few exceptions, /etc is filled with text files, not binary
> files, and half the executables on the system are text (Python, Perl,
> bash, sh, awk, etc.).
Our debate seems to stem from a different idea of what text is. To me,
text in the Python sense is a sequence of UCS-4 character code points.
The opposite of text is not necessarily binary.
Most of those "text" files under /etc expect ASCII. In many contexts,
they tolerate UTF-8 or Latin-3 or whatever, but it's a bit iffy (how are
extra-ASCII passwords encoded in the /etc/shadow?). Also, the files
under /etc, /var/log etc should not depend on the locale since they are
typically interpreted by daemons, which typically don't possess locales.
> Relatively rare. Like, um, email, news, html, Unix config files,
> Windows ini files, source code in just about every language ever,
> SMSes, XML, JSON, YAML, instant messenger apps,
I would be especially wary of letting Python 3 interpret those files for
me. Python's [text] strings could be a wonderful tool on the inside of
my program, but I definitely would like to micromanage the I/O. Do I
obey the locale or not? That's too big (and painful) a question for
Python to answer on its own (and pretend like everything's under
control).
> word processors... even *graphic* applications invariably have a text
> tool.
Thing is, the serious text utilities like word processors probably need
lots of ancillary information so Python's [text] strings might be too
naive to represent even a single character.
>> More often, len(b'λ') is what I want.
>
> Oh really? Are you sure? What exactly is b'λ'?
That's something that ought to work in the UTF-8 paradise.
Unfortunately, Python only allows ASCII in bytes. ASCII only! In this
day and age! Even C is not so picky:
#include <stdio.h>
int main()
{
printf("Hyvää yötä\n");
return 0;
}
Marko
[toc] | [prev] | [next] | [standalone]
Page 5 of 17 — ← Prev page 1 … 3 4 [5] 6 7 … 17 Next page →
Back to top | Article view | comp.lang.python
csiph-web