Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.python > #107077 > unrolled thread
| Started by | Steven D'Aprano <steve@pearwood.info> |
|---|---|
| First post | 2016-04-16 14:38 +1000 |
| Last post | 2016-04-18 05:45 +1000 |
| Articles | 20 on this page of 142 — 36 participants |
Back to article view | Back to comp.lang.python
Guido sees the light: PEP 8 updated Steven D'Aprano <steve@pearwood.info> - 2016-04-16 14:38 +1000
Re: Guido sees the light: PEP 8 updated Bob Martin <bob.martin@excite.com> - 2016-04-16 08:05 +0100
Re: Guido sees the light: PEP 8 updated Marko Rauhamaa <marko@pacujo.net> - 2016-04-16 11:06 +0300
Re: Guido sees the light: PEP 8 updated Chris Angelico <rosuav@gmail.com> - 2016-04-16 18:32 +1000
Re: Guido sees the light: PEP 8 updated Marko Rauhamaa <marko@pacujo.net> - 2016-04-16 11:51 +0300
Re: Guido sees the light: PEP 8 updated Chris Angelico <rosuav@gmail.com> - 2016-04-16 19:30 +1000
Re: Guido sees the light: PEP 8 updated Michael Selik <michael.selik@gmail.com> - 2016-04-16 09:34 +0000
Re: Guido sees the light: PEP 8 updated Steven D'Aprano <steve@pearwood.info> - 2016-04-16 22:03 +1000
Re: Guido sees the light: PEP 8 updated Stephen Hansen <me+python@ixokai.io> - 2016-04-16 05:32 -0700
Re: Guido sees the light: PEP 8 updated Larry Martell <larry.martell@gmail.com> - 2016-04-16 10:53 -0400
Re: Guido sees the light: PEP 8 updated Marko Rauhamaa <marko@pacujo.net> - 2016-04-16 19:51 +0300
Re: Guido sees the light: PEP 8 updated Larry Martell <larry.martell@gmail.com> - 2016-04-16 12:58 -0400
Re: Guido sees the light: PEP 8 updated BartC <bc@freeuk.com> - 2016-04-16 19:18 +0100
Re: Guido sees the light: PEP 8 updated Larry Martell <larry.martell@gmail.com> - 2016-04-16 14:53 -0400
Re: Guido sees the light: PEP 8 updated alex wright <wrightalexw@gmail.com> - 2016-04-16 15:21 -0400
Re: Guido sees the light: PEP 8 updated Dennis Lee Bieber <wlfraed@ix.netcom.com> - 2016-04-16 19:08 -0400
Re: Guido sees the light: PEP 8 updated Terry Reedy <tjreedy@udel.edu> - 2016-04-16 13:25 -0400
Re: Guido sees the light: PEP 8 updated Marko Rauhamaa <marko@pacujo.net> - 2016-04-16 21:33 +0300
Re: Guido sees the light: PEP 8 updated Ethan Furman <ethan@stoneleaf.us> - 2016-04-16 12:07 -0700
Re: Guido sees the light: PEP 8 updated Ben Finney <ben+python@benfinney.id.au> - 2016-04-17 06:08 +1000
Re: Guido sees the light: PEP 8 updated Tim Chase <python.list@tim.thechases.com> - 2016-04-16 16:50 -0500
Re: Guido sees the light: PEP 8 updated Tim Delaney <timothy.c.delaney@gmail.com> - 2016-04-17 08:15 +1000
Re: Guido sees the light: PEP 8 updated Marko Rauhamaa <marko@pacujo.net> - 2016-04-17 01:30 +0300
Re: Guido sees the light: PEP 8 updated Ian Kelly <ian.g.kelly@gmail.com> - 2016-04-17 07:38 -0600
Re: Guido sees the light: PEP 8 updated Dennis Lee Bieber <wlfraed@ix.netcom.com> - 2016-04-16 19:02 -0400
Re: Guido sees the light: PEP 8 updated Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-04-17 00:25 +0100
Re: Guido sees the light: PEP 8 updated Chris Angelico <rosuav@gmail.com> - 2016-04-17 09:33 +1000
Re: Guido sees the light: PEP 8 updated Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-04-17 01:29 +0100
Re: Guido sees the light: PEP 8 updated alex wright <wrightalexw@gmail.com> - 2016-04-16 19:43 -0400
Re: Guido sees the light: PEP 8 updated Chris Angelico <rosuav@gmail.com> - 2016-04-17 09:11 +1000
Re: Guido sees the light: PEP 8 updated Grant Edwards <grant.b.edwards@gmail.com> - 2016-04-16 23:19 +0000
Re: Guido sees the light: PEP 8 updated Tim Chase <python.list@tim.thechases.com> - 2016-04-16 19:12 -0500
Re: Guido sees the light: PEP 8 updated MRAB <python@mrabarnett.plus.com> - 2016-04-17 01:24 +0100
Re: Guido sees the light: PEP 8 updated Tim Chase <python.list@tim.thechases.com> - 2016-04-16 20:30 -0500
Re: Guido sees the light: PEP 8 updated Coos Haak <chforth@hccnet.nl> - 2016-04-17 16:35 +0200
Re: Guido sees the light: PEP 8 updated Tim Chase <python.list@tim.thechases.com> - 2016-04-17 13:11 -0500
Re: Guido sees the light: PEP 8 updated Random832 <random832@fastmail.com> - 2016-04-16 21:59 -0400
Re: Guido sees the light: PEP 8 updated Rustom Mody <rustompmody@gmail.com> - 2016-04-16 20:44 -0700
Re: Guido sees the light: PEP 8 updated Chris Angelico <rosuav@gmail.com> - 2016-04-17 13:49 +1000
Re: Guido sees the light: PEP 8 updated Rustom Mody <rustompmody@gmail.com> - 2016-04-17 18:39 -0700
Re: Guido sees the light: PEP 8 updated Steven D'Aprano <steve@pearwood.info> - 2016-04-18 13:19 +1000
Re: Guido sees the light: PEP 8 updated Rustom Mody <rustompmody@gmail.com> - 2016-04-17 20:48 -0700
Re: Guido sees the light: PEP 8 updated David Palao <dpalao.python@gmail.com> - 2016-04-18 13:35 +0200
Re: Guido sees the light: PEP 8 updated BartC <bc@freeuk.com> - 2016-04-17 11:04 +0100
Re: Guido sees the light: PEP 8 updated Rustom Mody <rustompmody@gmail.com> - 2016-04-17 21:06 -0700
Re: Guido sees the light: PEP 8 updated Gregory Ewing <greg.ewing@canterbury.ac.nz> - 2016-04-18 21:03 +1200
Re: Guido sees the light: PEP 8 updated Rustom Mody <rustompmody@gmail.com> - 2016-04-18 04:07 -0700
Re: Guido sees the light: PEP 8 updated Marko Rauhamaa <marko@pacujo.net> - 2016-04-17 14:01 +0300
Re: Guido sees the light: PEP 8 updated Chris Angelico <rosuav@gmail.com> - 2016-04-17 21:14 +1000
Re: Guido sees the light: PEP 8 updated BartC <bc@freeuk.com> - 2016-04-17 13:04 +0100
Re: Guido sees the light: PEP 8 updated Marko Rauhamaa <marko@pacujo.net> - 2016-04-17 15:10 +0300
Re: Guido sees the light: PEP 8 updated Ben Finney <ben+python@benfinney.id.au> - 2016-04-18 08:13 +1000
Re: Guido sees the light: PEP 8 updated Steven D'Aprano <steve@pearwood.info> - 2016-04-18 11:57 +1000
Re: Guido sees the light: PEP 8 updated Marko Rauhamaa <marko@pacujo.net> - 2016-04-18 11:02 +0300
Re: Guido sees the light: PEP 8 updated Gregory Ewing <greg.ewing@canterbury.ac.nz> - 2016-04-18 20:43 +1200
Re: Guido sees the light: PEP 8 updated Marko Rauhamaa <marko@pacujo.net> - 2016-04-18 12:17 +0300
Re: Guido sees the light: PEP 8 updated eryk sun <eryksun@gmail.com> - 2016-04-17 00:01 -0500
Re: Guido sees the light: PEP 8 updated Random832 <random832@fastmail.com> - 2016-04-17 01:10 -0400
Re: Guido sees the light: PEP 8 updated eryk sun <eryksun@gmail.com> - 2016-04-17 03:14 -0500
Re: Guido sees the light: PEP 8 updated Dennis Lee Bieber <wlfraed@ix.netcom.com> - 2016-04-17 12:13 -0400
Re: Guido sees the light: PEP 8 updated eryk sun <eryksun@gmail.com> - 2016-04-17 15:24 -0500
Re: Guido sees the light: PEP 8 updated Michael Torrie <torriem@gmail.com> - 2016-04-17 14:41 -0600
Re: Guido sees the light: PEP 8 updated Gregory Ewing <greg.ewing@canterbury.ac.nz> - 2016-04-18 11:56 +1200
Re: Guido sees the light: PEP 8 updated Random832 <random832@fastmail.com> - 2016-04-17 20:29 -0400
Re: Guido sees the light: PEP 8 updated Sivan Greenberg <sivan@vitakka.co> - 2016-04-18 16:35 +0300
Re: Guido sees the light: PEP 8 updated Pete Forman <petef4+usenet@gmail.com> - 2016-04-18 22:14 +0100
Re: Guido sees the light: PEP 8 updated Ian Kelly <ian.g.kelly@gmail.com> - 2016-04-18 15:29 -0600
Re: Guido sees the light: PEP 8 updated Pete Forman <petef4+usenet@gmail.com> - 2016-04-18 23:20 +0100
Re: Guido sees the light: PEP 8 updated Gregory Ewing <greg.ewing@canterbury.ac.nz> - 2016-04-19 17:39 +1200
Re: Guido sees the light: PEP 8 updated Ben Finney <ben+python@benfinney.id.au> - 2016-04-19 08:58 +1000
Re: Guido sees the light: PEP 8 updated sohcahtoa82@gmail.com - 2016-04-18 18:19 -0700
Re: Guido sees the light: PEP 8 updated Rustom Mody <rustompmody@gmail.com> - 2016-04-18 20:04 -0700
Re: Guido sees the light: PEP 8 updated Random832 <random832@fastmail.com> - 2016-04-18 23:29 -0400
Re: Guido sees the light: PEP 8 updated Rustom Mody <rustompmody@gmail.com> - 2016-04-18 20:54 -0700
Re: Guido sees the light: PEP 8 updated Random832 <random832@fastmail.com> - 2016-04-19 00:11 -0400
Re: Guido sees the light: PEP 8 updated Rustom Mody <rustompmody@gmail.com> - 2016-04-19 05:55 -0700
Re: Guido sees the light: PEP 8 updated Random832 <random832@fastmail.com> - 2016-04-19 10:05 -0400
Re: Guido sees the light: PEP 8 updated Chris Angelico <rosuav@gmail.com> - 2016-04-20 00:13 +1000
Re: Guido sees the light: PEP 8 updated Pete Forman <petef4+usenet@gmail.com> - 2016-04-19 08:34 +0100
Re: Guido sees the light: PEP 8 updated Ben Finney <ben+python@benfinney.id.au> - 2016-04-19 18:04 +1000
Re: Guido sees the light: PEP 8 updated Marko Rauhamaa <marko@pacujo.net> - 2016-04-19 11:09 +0300
Re: Guido sees the light: PEP 8 updated Chris Angelico <rosuav@gmail.com> - 2016-04-19 18:17 +1000
Re: Guido sees the light: PEP 8 updated Rustom Mody <rustompmody@gmail.com> - 2016-04-19 04:37 -0700
Re: Guido sees the light: PEP 8 updated Tim Chase <python.list@tim.thechases.com> - 2016-04-19 08:17 -0500
Re: Guido sees the light: PEP 8 updated Rustom Mody <rustompmody@gmail.com> - 2016-04-19 07:10 -0700
Re: Guido sees the light: PEP 8 updated Grant Edwards <grant.b.edwards@gmail.com> - 2016-04-19 14:15 +0000
Re: Guido sees the light: PEP 8 updated Rustom Mody <rustompmody@gmail.com> - 2016-04-19 07:54 -0700
Re: Guido sees the light: PEP 8 updated Steven D'Aprano <steve@pearwood.info> - 2016-04-20 01:50 +1000
Re: Guido sees the light: PEP 8 updated Steven D'Aprano <steve@pearwood.info> - 2016-04-20 01:58 +1000
Re: Guido sees the light: PEP 8 updated Larry Martell <larry.martell@gmail.com> - 2016-04-19 13:06 -0400
Re: Guido sees the light: PEP 8 updated alister <alister.ware@ntlworld.com> - 2016-04-19 17:13 +0000
Re: Guido sees the light: PEP 8 updated Chris Angelico <rosuav@gmail.com> - 2016-04-20 00:24 +1000
Re: Guido sees the light: PEP 8 updated Steven D'Aprano <steve@pearwood.info> - 2016-04-20 02:14 +1000
Re: Guido sees the light: PEP 8 updated Rustom Mody <rustompmody@gmail.com> - 2016-04-19 09:46 -0700
Re: Guido sees the light: PEP 8 updated Tim Chase <python.list@tim.thechases.com> - 2016-04-19 12:43 -0500
Re: Guido sees the light: PEP 8 updated Rustom Mody <rustompmody@gmail.com> - 2016-04-19 11:05 -0700
Re: Guido sees the light: PEP 8 updated Random832 <random832@fastmail.com> - 2016-04-19 14:54 -0400
Re: Guido sees the light: PEP 8 updated Steven D'Aprano <steve@pearwood.info> - 2016-04-20 10:34 +1000
Re: Guido sees the light: PEP 8 updated Random832 <random832@fastmail.com> - 2016-04-19 22:02 -0400
Re: Guido sees the light: PEP 8 updated Steven D'Aprano <steve@pearwood.info> - 2016-04-20 11:38 +1000
Re: Guido sees the light: PEP 8 updated Chris Angelico <rosuav@gmail.com> - 2016-04-20 12:21 +1000
Re: Guido sees the light: PEP 8 updated Terry Reedy <tjreedy@udel.edu> - 2016-04-19 23:23 -0400
Re: Guido sees the light: PEP 8 updated Chris Angelico <rosuav@gmail.com> - 2016-04-20 13:41 +1000
Re: Guido sees the light: PEP 8 updated Terry Reedy <tjreedy@udel.edu> - 2016-04-20 02:08 -0400
Re: Guido sees the light: PEP 8 updated wxjmfauth@gmail.com - 2016-04-20 00:48 -0700
Re: Guido sees the light: PEP 8 updated Oscar Benjamin <oscar.j.benjamin@gmail.com> - 2016-04-20 10:24 +0100
Re: Guido sees the light: PEP 8 updated Oscar Benjamin <oscar.j.benjamin@gmail.com> - 2016-04-20 10:26 +0100
Re: Guido sees the light: PEP 8 updated Dennis Lee Bieber <wlfraed@ix.netcom.com> - 2016-04-20 07:51 -0400
Re: Guido sees the light: PEP 8 updated Rustom Mody <rustompmody@gmail.com> - 2016-04-19 21:04 -0700
Re: Guido sees the light: PEP 8 updated Ben Finney <ben+python@benfinney.id.au> - 2016-04-20 06:50 +1000
Re: Guido sees the light: PEP 8 updated Chris Angelico <rosuav@gmail.com> - 2016-04-20 06:59 +1000
Re: Guido sees the light: PEP 8 updated Marko Rauhamaa <marko@pacujo.net> - 2016-04-20 00:35 +0300
Re: Guido sees the light: PEP 8 updated Steven D'Aprano <steve@pearwood.info> - 2016-04-20 11:03 +1000
Re: Guido sees the light: PEP 8 updated Rustom Mody <rustompmody@gmail.com> - 2016-04-19 21:13 -0700
Re: Guido sees the light: PEP 8 updated Gregory Ewing <greg.ewing@canterbury.ac.nz> - 2016-04-20 18:39 +1200
Re: Guido sees the light: PEP 8 updated sohcahtoa82@gmail.com - 2016-04-19 14:43 -0700
Re: Guido sees the light: PEP 8 updated Dennis Lee Bieber <wlfraed@ix.netcom.com> - 2016-04-19 19:20 -0400
Re: Guido sees the light: PEP 8 updated Grant Edwards <grant.b.edwards@gmail.com> - 2016-04-19 23:22 +0000
Re: Guido sees the light: PEP 8 updated Chris Angelico <rosuav@gmail.com> - 2016-04-20 09:33 +1000
Re: Guido sees the light: PEP 8 updated Tim Chase <python.list@tim.thechases.com> - 2016-04-19 19:02 -0500
Re: Guido sees the light: PEP 8 updated Steven D'Aprano <steve@pearwood.info> - 2016-04-20 10:32 +1000
Re: Guido sees the light: PEP 8 updated Random832 <random832@fastmail.com> - 2016-04-19 21:57 -0400
Re: Guido sees the light: PEP 8 updated wxjmfauth@gmail.com - 2016-04-19 01:49 -0700
Re: Guido sees the light: PEP 8 updated Paul Rudin <paul.nospam@rudin.co.uk> - 2016-04-19 11:49 +0100
Re: Guido sees the light: PEP 8 updated Marko Rauhamaa <marko@pacujo.net> - 2016-04-19 14:47 +0300
Re: Guido sees the light: PEP 8 updated Rustom Mody <rustompmody@gmail.com> - 2016-04-19 05:06 -0700
Re: Guido sees the light: PEP 8 updated Marko Rauhamaa <marko@pacujo.net> - 2016-04-19 15:14 +0300
Re: Guido sees the light: PEP 8 updated Antoon Pardon <antoon.pardon@rece.vub.ac.be> - 2016-04-19 15:07 +0200
Re: Guido sees the light: PEP 8 updated Tim Chase <python.list@tim.thechases.com> - 2016-04-19 08:31 -0500
Re: Guido sees the light: PEP 8 updated Chris Angelico <rosuav@gmail.com> - 2016-04-19 23:41 +1000
Re: Guido sees the light: PEP 8 updated Tim Chase <python.list@tim.thechases.com> - 2016-04-19 08:50 -0500
Re: Guido sees the light: PEP 8 updated Alice Bevan–McGregor <alice@gothcandy.com> - 2016-04-19 10:45 -0400
Falsehoods People Believe about PEP 8 (was: Guido sees the light: PEP 8 updated) Ben Finney <ben+python@benfinney.id.au> - 2016-04-17 06:21 +1000
Re: Falsehoods People Believe about PEP 8 (was: Guido sees the light: PEP 8 updated) Chris Angelico <rosuav@gmail.com> - 2016-04-17 06:31 +1000
Re: Falsehoods People Believe about PEP 8 (was: Guido sees the light: PEP 8 updated) Random832 <random832@fastmail.com> - 2016-04-16 16:44 -0400
Re: Falsehoods People Believe about PEP 8 (was: Guido sees the light: PEP 8 updated) Dan Sommers <dan@tombstonezero.net> - 2016-04-16 21:22 +0000
Re: Falsehoods People Believe about PEP 8 (was: Guido sees the light: PEP 8 updated) Chris Angelico <rosuav@gmail.com> - 2016-04-17 07:34 +1000
Re: Falsehoods People Believe about PEP 8 (was: Guido sees the light: PEP 8 updated) Dan Sommers <dan@tombstonezero.net> - 2016-04-16 23:35 +0000
Re: Falsehoods People Believe about PEP 8 (was: Guido sees the light: PEP 8 updated) Steven D'Aprano <steve@pearwood.info> - 2016-04-17 11:48 +1000
Re: Falsehoods People Believe about PEP 8 (was: Guido sees the light: PEP 8 updated) Dan Sommers <dan@tombstonezero.net> - 2016-04-17 03:52 +0000
Re: Falsehoods People Believe about PEP 8 (was: Guido sees the light: PEP 8 updated) Steven D'Aprano <steve@pearwood.info> - 2016-04-17 11:38 +1000
Re: Falsehoods People Believe about PEP 8 (was: Guido sees the light: PEP 8 updated) Chris Angelico <rosuav@gmail.com> - 2016-04-18 05:45 +1000
Page 7 of 8 — ← Prev page 1 2 3 4 5 6 [7] 8 Next page →
| From | Steven D'Aprano <steve@pearwood.info> |
|---|---|
| Date | 2016-04-20 10:32 +1000 |
| Message-ID | <5716ce1b$0$1618$c3e8da3$5496439d@news.astraweb.com> |
| In reply to | #107346 |
On Wed, 20 Apr 2016 02:46 am, Rustom Mody wrote: > On Tuesday, April 19, 2016 at 9:44:39 PM UTC+5:30, Steven D'Aprano wrote: >> On Tue, 19 Apr 2016 01:04 pm, Rustom Mody wrote: >> >> > And more generally that programmers sticking to text when rest of world >> > has moved on is rather backward: >> >> I'm pretty sure that the rest of the world has not moved on from text. > > Run your popular search engine on "popular linux apps" or some such When you did that, did you do so by pointing and clicking on a menu of symbolic icons, or by typing the text "popular linux apps"? When the search engine provides the search results for you, does it fetch up a bunch of little pictures, or a list of text URLs with an extract of the text from the site? When I try it: https://duckduckgo.com/html/?q=popular%20linux%20apps I get text: What Are The Best 10 Linux Desktop Apps? This weekend, I'm going to be spending some time at the Southeast Linux Expo (SCALE) and presenting at the Linux Beginner Training. I'm doing the Desktops and ... linux.com/learn/what-are-best-10-linux-desktop-apps Lifehacker Pack for Linux: Our List of the Best Linux Apps NOTE: This post is outdated. Check out the most recent Lifehacker Pack for a more up-to-date list of essential Linux apps. Note that, unlike Windows and OS X, Linux ... lifehacker.com/5924951/lifehacker-pack-for-linux-our-lis... 20 Popular Ubuntu Linux Apps to Try Now | PCWorld As Ubuntu Linux continues to grow in popularity, most discussions of it tend to focus on the basics of the operating system itself, including especially ... pcworld.com/article/249663/20_popular_ubuntu_linux_ap... and so forth. The death of text as a communication medium is greatly exaggerated. > and > you will get for example: > > inkscape [...] How ironic that you are using a text-based medium to claim that people have "moved on" from text. Why didn't you draw us a picture to make your argument? > Do these look like text-based apps to you? Depends on what you mean by text-based. I don't doubt that some popular applications are used for manipulating media other than text, e.g. Gimp. But others are all about text: the two most popular parts of the LibreOffice application suite are used for word processing and spreadsheets, both text-based media. Perhaps the most common use of photo editing software like Photoshop and Gimp is to add text to images. Even for applications that are used to generate non-text media, their UIs are filled with text: menus and buttons display words, help screens filled with text, status bars that display the current coordinates of the mouse as text, dialog boxes filled with text boxes that you type into. When the UI has controls which can be controlled by the mouse (e.g. sliders), the control's value is usually displayed as text. Even colour wheels invariably display their results as text, as RGB triples or HTML codes. You list Firefox (but neglect Thunderbird) but browsing the web is still primarily a text-based medium. Not only is the fundamental file format of the web (HTML) text, but the information displayed is more often than not text. Even when the site displays non-text media, the pages usually include a way for people to comment, which they do by clicking from a menu of pre-defined emotions and messages displayed as icons. Nah, just kidding. They comment by writing text. I think that your assertion that the "rest of world has moved on" from text to be nonsense on stilts, but *even if you were right* that doesn't imply that programmers should do the same. Programmers operate under particular constraints which the average podcaster or film-maker does not have to deal with. Just because some people communicate through the medium of interpretative dance doesn't mean that programmers can or should. -- Steven
[toc] | [prev] | [next] | [standalone]
| From | Random832 <random832@fastmail.com> |
|---|---|
| Date | 2016-04-19 21:57 -0400 |
| Message-ID | <mailman.6.1461117428.12923.python-list@python.org> |
| In reply to | #107346 |
On Tue, Apr 19, 2016, at 20:02, Tim Chase wrote: > Well, my preferred method of "viewing" python code is /usr/bin/python > > Authoring, editing, and consuming are all distinct actions. Viewing and executing are also distinct. > > You could, for example, design a programming language that uses XML > > markup > > [shudders at remembering using a DSL "programming language" that was > XML] But I'm not proposing directly programming in XML markup. You'd use a GUI.
[toc] | [prev] | [next] | [standalone]
| From | wxjmfauth@gmail.com |
|---|---|
| Date | 2016-04-19 01:49 -0700 |
| Message-ID | <23185e0e-0986-484e-be76-4121f4e21323@googlegroups.com> |
| In reply to | #107277 |
Le lundi 18 avril 2016 23:14:17 UTC+2, Pete Forman a écrit : > Why is it that Python continues to use a fixed width font and therefore > specifies the maximum line width as a character count? > Because these brave and talented python devs are very naive ascii narrow minded people. There are not even able to make their product *crash* with an "é" (or showing it to students at academic level). But, why discuss?
[toc] | [prev] | [next] | [standalone]
| From | Paul Rudin <paul.nospam@rudin.co.uk> |
|---|---|
| Date | 2016-04-19 11:49 +0100 |
| Message-ID | <86twix3mc5.fsf@rudin.co.uk> |
| In reply to | #107277 |
Pete Forman <petef4+usenet@gmail.com> writes: > Why is it that Python continues to use a fixed width font and therefore > specifies the maximum line width as a character count? Python doesn't require the use of any particular font for editing your code. However programmers tend to use fixed width fonts when editing code because then the visual representation of indentation works consistently. But that's not a python specific thing.
[toc] | [prev] | [next] | [standalone]
| From | Marko Rauhamaa <marko@pacujo.net> |
|---|---|
| Date | 2016-04-19 14:47 +0300 |
| Message-ID | <87potlrfa1.fsf@elektro.pacujo.net> |
| In reply to | #107311 |
Paul Rudin <paul.nospam@rudin.co.uk>: > Pete Forman <petef4+usenet@gmail.com> writes: >> Why is it that Python continues to use a fixed width font and >> therefore specifies the maximum line width as a character count? > > Python doesn't require the use of any particular font for editing your > code. > > However programmers tend to use fixed width fonts when editing code > because then the visual representation of indentation works > consistently. But that's not a python specific thing. Prehistoric programming languages considered uppercase/lowercase differences insignificant variations. Most modern languages preserve the distinction and in fact invite us to make a difference between: BLACK Black black Why stop there? We need a PEP to distinguish also between: - typefaces (Times New Roman vs Garamond) - weights (bold vs thin) - serifs (with or without) - sizes (8pt vs 11pt) - colors (goldenrod vs maroon) Think of all the lesser programming languages that would seem so 20th-century when Python takes this step -- which virtually every self-respecting web site has already taken in their style sheets! Marko
[toc] | [prev] | [next] | [standalone]
| From | Rustom Mody <rustompmody@gmail.com> |
|---|---|
| Date | 2016-04-19 05:06 -0700 |
| Message-ID | <899a2469-3627-468f-8591-9cf95f17e1e8@googlegroups.com> |
| In reply to | #107313 |
On Tuesday, April 19, 2016 at 5:18:07 PM UTC+5:30, Marko Rauhamaa wrote: > Paul Rudin : > > > Pete Forman writes: > >> Why is it that Python continues to use a fixed width font and > >> therefore specifies the maximum line width as a character count? > > > > Python doesn't require the use of any particular font for editing your > > code. > > > > However programmers tend to use fixed width fonts when editing code > > because then the visual representation of indentation works > > consistently. But that's not a python specific thing. > > Prehistoric programming languages considered uppercase/lowercase > differences insignificant variations. Most modern languages preserve the > distinction and in fact invite us to make a difference between: > > BLACK > Black > black > > Why stop there? > > We need a PEP to distinguish also between: > > - typefaces (Times New Roman vs Garamond) > > - weights (bold vs thin) > > - serifs (with or without) > > - sizes (8pt vs 11pt) > > - colors (goldenrod vs maroon) > > > Think of all the lesser programming languages that would seem so > 20th-century when Python takes this step -- which virtually every > self-respecting web site has already taken in their style sheets! You are of course being facetious but Forth already beat you to it in Color Forth: https://blogs.msdn.microsoft.com/ashleyf/2013/11/02/the-beautiful-simplicity-of-colorforth/ More seriously the problem is that when we go from 100 of ASCII to 1 million of Unicode its like a digital to analogue jump. In http://blog.languager.org/2014/04/unicoded-python.html Ive described that it would be nice if for instance we could write x ≤ y in place of the clunky x <= y Likewise x ≠ y would obviate all useless arguments between x <>y or x != y etc But then there are a slew of lookalikes like x ≲ y x ≦ y If someone seriously starts embracing unicode in program source, these kinds of questions/issues need corresponding serious consideration. In the same way and like colorforth, it would be better to distinguish <font-size=huge>identifier</font> from <font-size=normal>identifier</font> rather than the current status of distinguishing identifier from Identifier But then we have a slippery slope: Should <font-size=12> be same/distinct from <font-size=13> ?
[toc] | [prev] | [next] | [standalone]
| From | Marko Rauhamaa <marko@pacujo.net> |
|---|---|
| Date | 2016-04-19 15:14 +0300 |
| Message-ID | <87lh49re1x.fsf@elektro.pacujo.net> |
| In reply to | #107314 |
Rustom Mody <rustompmody@gmail.com>: > In the same way and like colorforth, it would be better to distinguish > <font-size=huge>identifier</font> from > <font-size=normal>identifier</font> rather than the current status of > distinguishing identifier from Identifier But then we have a slippery > slope: Should <font-size=12> be same/distinct from <font-size=13> ? In a past life of mine, a development team proudly presented their new reporting tool that produced beautiful graphs with dozens of crisscrossing, jagged lines. I proposed they needed to make each line a different color and add a legend for each color. The developers thought that was a great idea. Marko
[toc] | [prev] | [next] | [standalone]
| From | Antoon Pardon <antoon.pardon@rece.vub.ac.be> |
|---|---|
| Date | 2016-04-19 15:07 +0200 |
| Message-ID | <mailman.10.1461071288.30862.python-list@python.org> |
| In reply to | #107313 |
Op 19-04-16 om 13:47 schreef Marko Rauhamaa: > Prehistoric programming languages considered uppercase/lowercase > differences insignificant variations. Most modern languages preserve the > distinction and in fact invite us to make a difference between: > > BLACK > Black > black > > Why stop there? > > We need a PEP to distinguish also between: > > - typefaces (Times New Roman vs Garamond) > > - weights (bold vs thin) > > - serifs (with or without) > > - sizes (8pt vs 11pt) > > - colors (goldenrod vs maroon) Well personnaly I would like the introduction of weights. So that reserved keywords are in bold and identifiers are thin. With unicode we could use the mathematical bold letters for reserved words. -- Antoon Pardon
[toc] | [prev] | [next] | [standalone]
| From | Tim Chase <python.list@tim.thechases.com> |
|---|---|
| Date | 2016-04-19 08:31 -0500 |
| Message-ID | <mailman.12.1461072887.30862.python-list@python.org> |
| In reply to | #107313 |
On 2016-04-19 14:47, Marko Rauhamaa wrote:
> We need a PEP to distinguish also between:
> - typefaces (Times New Roman vs Garamond)
> - weights (bold vs thin)
> - serifs (with or without)
> - sizes (8pt vs 11pt)
> - colors (goldenrod vs maroon)
Like HTML & CSS, the goal should be to separate the code (HTML) from
its presentation (how it appears in your editor).
It's why I've taken to using formulaic indenting (one or two
indents depending on whether the continued line starts an
indented block) rather than trying to align with something in a prior
line. It drives me nuts when I globally change the spelling of
something (and thus the length of some variable name) and then feel
obligated to re-indent my continuations to get them to line back up
with some arbitrary paren. Compare
def do_something(param1,
param2,
param3,
):
implementation()
with just using
def do_something(param1,
param2,
param3,
):
implementation()
(or, if you want your params to line up
def do_something(
param1,
param2,
param3,
):
implementation()
which is usually how I end up splitting them)
When "do_something" changes to "frobify", I don't feel the need to go
play with indentation with my scheme.
Likewise, I detest aligning comments and almost always prefer to put
them in a neighboring line if there's continuation:
foo = bar * 3 + 2 # we have 3 bars
# plus one for margin on either side
changing the length of the code portion (say, s/bar/inner_width/) will
require re-indenting (and possibly re-flowing) the comments.
It's even worse if the comment flows to an unrelated line
foo = bar * 3 + 2 # we have 3 bars
result = apply(bar) # plus one for margin on either side
Now, if either line of *code* changes, it requires rejiggering the
comment indentation.
If the comment gets moved above, it's no longer an issue:
# we have 3 bars plus one for margin on either side
foo = bar * 3 + 2
result = apply(bar)
I strongly advocate from keeping the content (the code and its AST)
separate from its presentation.
-tkc
[toc] | [prev] | [next] | [standalone]
| From | Chris Angelico <rosuav@gmail.com> |
|---|---|
| Date | 2016-04-19 23:41 +1000 |
| Message-ID | <mailman.13.1461073269.30862.python-list@python.org> |
| In reply to | #107313 |
On Tue, Apr 19, 2016 at 11:31 PM, Tim Chase <python.list@tim.thechases.com> wrote: > Likewise, I detest aligning comments and almost always prefer to put > them in a neighboring line if there's continuation: > > foo = bar * 3 + 2 # we have 3 bars > # plus one for margin on either side > > changing the length of the code portion (say, s/bar/inner_width/) will > require re-indenting (and possibly re-flowing) the comments. > > It's even worse if the comment flows to an unrelated line > > foo = bar * 3 + 2 # we have 3 bars > result = apply(bar) # plus one for margin on either side > > Now, if either line of *code* changes, it requires rejiggering the > comment indentation. > > If the comment gets moved above, it's no longer an issue: > > # we have 3 bars plus one for margin on either side > foo = bar * 3 + 2 > result = apply(bar) Oh, absolutely! If the right-hand comment can't fit in the right-hand-side, it needs to move above the code. The only time I'll "wrap" that kind of comment is when it actually applies to both lines of code: width = bar * 3 + 2 # we have 3x2 bars, plus one... height = bar * 2 + 2 # ... pixel of margin on all sides ChrisA
[toc] | [prev] | [next] | [standalone]
| From | Tim Chase <python.list@tim.thechases.com> |
|---|---|
| Date | 2016-04-19 08:50 -0500 |
| Message-ID | <mailman.23.1461078826.30862.python-list@python.org> |
| In reply to | #107313 |
On 2016-04-19 23:41, Chris Angelico wrote: > The only time I'll "wrap" that kind of comment is when it actually > applies to both lines of code: > > width = bar * 3 + 2 # we have 3x2 bars, plus one... > height = bar * 2 + 2 # ... pixel of margin on all sides And even then in that exceptional case, I see that you do the same thing I do: just append <space>, hash, space, comment. No fancy aligning. -tkc
[toc] | [prev] | [next] | [standalone]
| From | Alice Bevan–McGregor <alice@gothcandy.com> |
|---|---|
| Date | 2016-04-19 10:45 -0400 |
| Message-ID | <mailman.22.1461077123.30862.python-list@python.org> |
| In reply to | #107277 |
On 2016-04-18 21:14:02 +0000, Pete Forman said: > Why is it that Python continues to use a fixed width font and therefore > specifies the maximum line width as a character count? > > An essential part of the language is indentation which ought to continue > to mandate that lines start with a multiple of 4 em worth of space (or > some other size or encode with hard tabs, that is not germane to my > question). The content of the line need not be bound by the rules needed > to position its start. I wrote a semi-serious, somewhat tongue-in-cheek article entitled "Your code style guide is crap, but still better than nothing." a number of years ago, and reposted it towards the end of last year. It would seem to apply here, as the fundamental disconnect isn't just "use of N space characters", but "use of space characters at all". >From the article: > Do you use spaces in a word processor to line up bullet points? If you > do you’ll be first against the wall when the revolution comes! http://s.webcore.io/2K0W0m2T2e2f It also touches on points raised by others, such as Elastic Tabstops. — Alice.
[toc] | [prev] | [next] | [standalone]
| From | Ben Finney <ben+python@benfinney.id.au> |
|---|---|
| Date | 2016-04-17 06:21 +1000 |
| Subject | Falsehoods People Believe about PEP 8 (was: Guido sees the light: PEP 8 updated) |
| Message-ID | <mailman.61.1460838131.6324.python-list@python.org> |
| In reply to | #107089 |
Chris Angelico <rosuav@gmail.com> writes: > Maybe we need a blog post "Falsehoods Programmers Believe About PEP > 8", along the lines of the ones about time and names. Great suggestion. (Do you have a blog on which you could post an article like this?) > Remember, every one of these is false. > > * All Python code should follow PEP 8. > > * If you use a tool named pep8, your code will be PEP 8 compliant. > > * If your code is PEP 8 compliant, a tool named pep8 will accept it. > > * The Python Standard Library is PEP 8 compliant. > > * Okay, at least the new parts of the standard library are PEP 8 > compliant. > > * PEP 8 compliant code is inherently better than non-compliant code. > > * PEP8-ing existing code will improve it. > > * Once code is PEP 8 compliant, it can easily be kept that way through > subsequent edits. > > * PEP 8 never changes. > > * Well, it never materially changes. > > * I mean, new advice, sure, but it'll never actually go back on a > rule. * The line length limit is obsolete in an age of high-resolution displays. * Okay, but if you disregard side-by-side windows, lines of code can be arbitrarily long without hurting readability. * Well, maybe not several hundred characters, but surely 120 characters of code on a line is easy enough to read. * The only valid white space is line breaks and U+0020 SPACE. * Okay, U+0009 TAB when lining up columns, but no other white space. * Oh, come on, no-one would use U+000C FORM FEED in source code. -- \ “The apparent lesson of the Inquisition is that insistence on | `\ uniformity of belief is fatal to intellectual, moral, and | _o__) spiritual health.” —_The Uses Of The Past_, Herbert J. Muller | Ben Finney
[toc] | [prev] | [next] | [standalone]
| From | Chris Angelico <rosuav@gmail.com> |
|---|---|
| Date | 2016-04-17 06:31 +1000 |
| Subject | Re: Falsehoods People Believe about PEP 8 (was: Guido sees the light: PEP 8 updated) |
| Message-ID | <mailman.63.1460838716.6324.python-list@python.org> |
| In reply to | #107089 |
On Sun, Apr 17, 2016 at 6:21 AM, Ben Finney <ben+python@benfinney.id.au> wrote: > Great suggestion. (Do you have a blog on which you could post an article > like this?) I do. I'll let people contribute for a while, and then I'll post it on rosuav.blogspot.com. Thanks for the additions! ChrisA
[toc] | [prev] | [next] | [standalone]
| From | Random832 <random832@fastmail.com> |
|---|---|
| Date | 2016-04-16 16:44 -0400 |
| Subject | Re: Falsehoods People Believe about PEP 8 (was: Guido sees the light: PEP 8 updated) |
| Message-ID | <mailman.65.1460839473.6324.python-list@python.org> |
| In reply to | #107089 |
On Sat, Apr 16, 2016, at 16:21, Ben Finney wrote: > * Oh, come on, no-one would use U+000C FORM FEED in source code. Some text editors have shortcuts to navigate to the previous/next line that begins with a form feed.
[toc] | [prev] | [next] | [standalone]
| From | Dan Sommers <dan@tombstonezero.net> |
|---|---|
| Date | 2016-04-16 21:22 +0000 |
| Subject | Re: Falsehoods People Believe about PEP 8 (was: Guido sees the light: PEP 8 updated) |
| Message-ID | <neuaf8$j00$1@dont-email.me> |
| In reply to | #107115 |
On Sat, 16 Apr 2016 16:44:30 -0400, Random832 wrote: > On Sat, Apr 16, 2016, at 16:21, Ben Finney wrote: >> * Oh, come on, no-one would use U+000C FORM FEED in source code. > > Some text editors have shortcuts to navigate to the previous/next line > that begins with a form feed. Add these to the list of myths: * All producers use the same tools to produce code. * All consumers use the same tools to consume code. * All entities that produce and consume code use the same tools. * All entities use the same tools to consume code that they do to produce it.
[toc] | [prev] | [next] | [standalone]
| From | Chris Angelico <rosuav@gmail.com> |
|---|---|
| Date | 2016-04-17 07:34 +1000 |
| Subject | Re: Falsehoods People Believe about PEP 8 (was: Guido sees the light: PEP 8 updated) |
| Message-ID | <mailman.68.1460842470.6324.python-list@python.org> |
| In reply to | #107118 |
On Sun, Apr 17, 2016 at 7:22 AM, Dan Sommers <dan@tombstonezero.net> wrote: > On Sat, 16 Apr 2016 16:44:30 -0400, Random832 wrote: > >> On Sat, Apr 16, 2016, at 16:21, Ben Finney wrote: >>> * Oh, come on, no-one would use U+000C FORM FEED in source code. >> >> Some text editors have shortcuts to navigate to the previous/next line >> that begins with a form feed. > > Add these to the list of myths: > > * All producers use the same tools to produce code. > * All consumers use the same tools to consume code. > * All entities that produce and consume code use the same tools. > * All entities use the same tools to consume code that they do to produce it. Those are definitely myths, but are they sufficiently connected to PEP 8? ChrisA
[toc] | [prev] | [next] | [standalone]
| From | Dan Sommers <dan@tombstonezero.net> |
|---|---|
| Date | 2016-04-16 23:35 +0000 |
| Subject | Re: Falsehoods People Believe about PEP 8 (was: Guido sees the light: PEP 8 updated) |
| Message-ID | <neui7a$u2p$1@dont-email.me> |
| In reply to | #107119 |
On Sun, 17 Apr 2016 07:34:20 +1000, Chris Angelico wrote: > On Sun, Apr 17, 2016 at 7:22 AM, Dan Sommers <dan@tombstonezero.net> wrote: >> On Sat, 16 Apr 2016 16:44:30 -0400, Random832 wrote: >> >>> On Sat, Apr 16, 2016, at 16:21, Ben Finney wrote: >>>> * Oh, come on, no-one would use U+000C FORM FEED in source code. >>> >>> Some text editors have shortcuts to navigate to the previous/next line >>> that begins with a form feed. >> >> Add these to the list of myths: >> >> * All producers use the same tools to produce code. >> * All consumers use the same tools to consume code. >> * All entities that produce and consume code use the same tools. >> * All entities use the same tools to consume code that they do to produce it. > > Those are definitely myths, but are they sufficiently connected to PEP 8? > > ChrisA PEP8 is all about readability, and we all read source code through one tool and/or another. Anecdotally, a lot of readability arguments (including that one about some text editors treating U+000C as a special case) end up being as much about the tools we use as they are about the source code itself. We (this mailing list, or maybe it was the python-ideas mailing list) just had a thread about non-ASCII characters in identifiers. One of the main argument against is the confusables (A vs Α vs А). Sufficient tooling, however, could render (pun intended) that argument moot. Not too long ago, one of the main arguments against was that not everyone's tools could even render Α or А.
[toc] | [prev] | [next] | [standalone]
| From | Steven D'Aprano <steve@pearwood.info> |
|---|---|
| Date | 2016-04-17 11:48 +1000 |
| Subject | Re: Falsehoods People Believe about PEP 8 (was: Guido sees the light: PEP 8 updated) |
| Message-ID | <5712eb5c$0$1604$c3e8da3$5496439d@news.astraweb.com> |
| In reply to | #107138 |
On Sun, 17 Apr 2016 09:35 am, Dan Sommers wrote: > We (this mailing list, or maybe it was the python-ideas mailing list) > just had a thread about non-ASCII characters in identifiers. One of the > main argument against is the confusables (A vs Α vs А). Sufficient > tooling, however, could render (pun intended) that argument moot. Not > too long ago, one of the main arguments against was that not everyone's > tools could even render Α or А. Technically speaking, they still might not. My editor can render both Cyrillic and Greek characters, but does a terrible job at Chinese and Korean because I don't have the font support. So all I see is a series of "missing character" boxes. There may be folks who don't have installed fonts that support Cyrillic or Greek. -- Steven
[toc] | [prev] | [next] | [standalone]
| From | Dan Sommers <dan@tombstonezero.net> |
|---|---|
| Date | 2016-04-17 03:52 +0000 |
| Subject | Re: Falsehoods People Believe about PEP 8 (was: Guido sees the light: PEP 8 updated) |
| Message-ID | <nev1a2$u2p$2@dont-email.me> |
| In reply to | #107151 |
On Sun, 17 Apr 2016 11:48:11 +1000, Steven D'Aprano wrote: > On Sun, 17 Apr 2016 09:35 am, Dan Sommers wrote: > >> We (this mailing list, or maybe it was the python-ideas mailing list) >> just had a thread about non-ASCII characters in identifiers. One of >> the main argument against is the confusables (A vs Α vs А). >> Sufficient tooling, however, could render (pun intended) that >> argument moot. Not too long ago, one of the main arguments against >> was that not everyone's tools could even render Α or А. > > Technically speaking, they still might not. My editor can render both > Cyrillic and Greek characters, but does a terrible job at Chinese and > Korean because I don't have the font support. So all I see is a series > of "missing character" boxes. There may be folks who don't have > installed fonts that support Cyrillic or Greek. I think we're agreeing. Not everyone's tools render the same source code the same way, which means that at least some part of readability depends on the tools people use. People who use screen readers rather than visual displays probably wonder why the rest of us can't tell our "l"s from our "1"s and our "O"s from our "0"s. If PEP8 is about readability, then it should dispell the myth that everyone perceives source code the same way through the same tools.
[toc] | [prev] | [next] | [standalone]
Page 7 of 8 — ← Prev page 1 2 3 4 5 6 [7] 8 Next page →
Back to top | Article view | comp.lang.python
csiph-web