Re: Guido sees the light: PEP 8 updated
On 20 April 2016 at 02:38, Steven D'Aprano wrote: > > "Oh no! We're having trouble displaying this Scratch project. > > If you are on a mobile phone or tablet, try visiting this project on a > computer. > > If you're on a computer, your Flash player might be disabled, missing, or > out of date." > > Yeah, thanks guys. Really helpful. Having a flash-enabled browser is a lower barrier to entry for most people in the world than having a code editor and (being able to use) say a terminal to run your code. -- Oscar -- https://mail.python.org/mailman/listinfo/python-list
Re: Guido sees the light: PEP 8 updated
On 20 April 2016 at 07:08, Terry Reedy wrote: > On 4/19/2016 11:41 PM, Chris Angelico wrote: >> >> On Wed, Apr 20, 2016 at 1:23 PM, Terry Reedy wrote: It kinda looks like Hypertalk syntax, which some of you may remember I'm exceedingly fond of. There's no reason why a GUI editor couldn't display Python code using such "building block" structure. E.g. indented blocks could use colour and shape cues to reinforce the structure of the code, just as Scratch does. >>> >>> >>> >>> That is an interesting idea. Perhaps I have been stuck in either/or >>> thinking -- either graphical or textual. With tk Text (IDLE), it would be >>> possible to tag each (4-space) indent with a color for the compound >>> statememt keywork causing the indent. >>> >> >> Interesting indeed! Tell me if I've understood you correctly. You'd >> display this code: >> >> def func(x): >> for n in range(1, x): >> while n < x: >> if n % 2: >> n = (n + 1) * 3 / 2 >> else: >> n = n * 2 + 3 >> >> with stripes of colour, with the entire first column of spaces all >> tied to the "def", and then the next block of four tied to the "for", >> etc? > > > Exactly. Take a look at bluej which is for Java. It surrounds different constructs with different coloured rectangles. It also provides UML-ish views of the classes in a project. My students seemed to like it. -- Oscar -- https://mail.python.org/mailman/listinfo/python-list
Re: Guido sees the light: PEP 8 updated
Rustom Mody wrote: On Wednesday, April 20, 2016 at 6:33:33 AM UTC+5:30, Steven D'Aprano wrote: Anyone who thinks that we're heading back to hieroglyphics simply isn't paying attention. Which are just text in the range 13000-1342F: http://unicode.org/charts/PDF/U13000.pdf Moreover, the Egyptian heiroglyphs are *not* pictograms, they're a phonetic alphabet. It's a textual form of writing just as much as ours is. -- Greg -- https://mail.python.org/mailman/listinfo/python-list
Re: Guido sees the light: PEP 8 updated
On 4/19/2016 11:41 PM, Chris Angelico wrote: On Wed, Apr 20, 2016 at 1:23 PM, Terry Reedy wrote: It kinda looks like Hypertalk syntax, which some of you may remember I'm exceedingly fond of. There's no reason why a GUI editor couldn't display Python code using such "building block" structure. E.g. indented blocks could use colour and shape cues to reinforce the structure of the code, just as Scratch does. That is an interesting idea. Perhaps I have been stuck in either/or thinking -- either graphical or textual. With tk Text (IDLE), it would be possible to tag each (4-space) indent with a color for the compound statememt keywork causing the indent. Interesting indeed! Tell me if I've understood you correctly. You'd display this code: def func(x): for n in range(1, x): while n < x: if n % 2: n = (n + 1) * 3 / 2 else: n = n * 2 + 3 with stripes of colour, with the entire first column of spaces all tied to the "def", and then the next block of four tied to the "for", etc? Exactly. > That'd be pretty cool, and a neat way to help people transfer their skills from Scratch to Python. (Would "else" be in the same colour as "if"? What about "elif"?) To be determined ;-). Perhaps different shades. Scratch uses one color for all control: while, if, else, but that would not work for python with so much more nesting. Scratch needs different colors for much broader categories as many are not for syntax but for groups of functions that in Python would be in imported modules. I would like nested for loops to have slightly different shades, but I would not necessarily start with that, unless each compound statement got a new tag and color. What makes the idea not completely ridiculous is that IDLE already keeps track of indents for its smart indenting and code context features. -- Terry Jan Reedy -- https://mail.python.org/mailman/listinfo/python-list
Re: Guido sees the light: PEP 8 updated
On Wednesday, April 20, 2016 at 6:33:33 AM UTC+5:30, Steven D'Aprano wrote: > Anyone who thinks that we're heading back to hieroglyphics simply isn't > paying attention. Which are just text in the range 13000-1342F: http://unicode.org/charts/PDF/U13000.pdf -- https://mail.python.org/mailman/listinfo/python-list
Re: Guido sees the light: PEP 8 updated
On Wednesday, April 20, 2016 at 12:25:09 AM UTC+5:30, Random832 wrote: > On Tue, Apr 19, 2016, at 13:43, Tim Chase wrote: > > Well, let's take a look at their native file formats: > > > > Inkscape: SVG > > > > Libreoffice: compressed XML > > > > Firefox: HTML+CSS+JS > > > > Musescore: compressed text > > > > Dia: compressed XML > > None of those are "text" in the sense being discussed here, which is > "preferred method of viewing and editing is a text editor". O you are so pedestrian! Here let me show you how to enjoy beethoven9th.mp3 with emacs: $ python -m base64 beethoven9th.mp3 > beethoven9th.txt; emacs beethoven9th.txt Isnt it glorious? And did you note the çhiɕ, pànacɦe and eĺan with with I demonstrated it? [Yeah you guessed right: For me French consists of English ...um text.. with a squiggle on every 3rd letter] -- https://mail.python.org/mailman/listinfo/python-list
Re: Guido sees the light: PEP 8 updated
On Wed, Apr 20, 2016 at 1:23 PM, Terry Reedy wrote: >> It kinda looks like Hypertalk syntax, which some of you may remember I'm >> exceedingly fond of. There's no reason why a GUI editor couldn't display >> Python code using such "building block" structure. E.g. indented blocks >> could use colour and shape cues to reinforce the structure of the code, >> just as Scratch does. > > > That is an interesting idea. Perhaps I have been stuck in either/or > thinking -- either graphical or textual. With tk Text (IDLE), it would be > possible to tag each (4-space) indent with a color for the compound > statememt keywork causing the indent. > Interesting indeed! Tell me if I've understood you correctly. You'd display this code: def func(x): for n in range(1, x): while n < x: if n % 2: n = (n + 1) * 3 / 2 else: n = n * 2 + 3 with stripes of colour, with the entire first column of spaces all tied to the "def", and then the next block of four tied to the "for", etc? That'd be pretty cool, and a neat way to help people transfer their skills from Scratch to Python. (Would "else" be in the same colour as "if"? What about "elif"?) ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: Guido sees the light: PEP 8 updated
On 4/19/2016 9:38 PM, Steven D'Aprano wrote: So-called "visual programming environments" (think: Visual Basic) are well-suited to laying out the interface of GUI applications. They might even be useful for extremely limited mini-languages like regexes. I'm told that there are still people who think that UML diagrams are a good idea. They're probably good for dataflow programming. But ultimately, to be productive with one, you still need text. As for "visual programming languages" (languages with an inherent visual form which lacks any simple or obvious text equivalent), they've been a dead-end. Even languages like Scratch cannot do without text. Look at the "Hello World" program here: https://en.wikipedia.org/wiki/File:Scratch_Hello_World.png The graphical elements are pure presentation, to make it more palatable to children and beginners. I think it is at least as important that the output is pictorial or even aural, then having the input text (and you are right, it is text) colored. By comparison, factorial functions (and most calculation examples) are rather boring. Don't think that I'm opposed to such visual presentations. Look at the sample code shown at the top of the page here: https://scratch.mit.edu/ It kinda looks like Hypertalk syntax, which some of you may remember I'm exceedingly fond of. There's no reason why a GUI editor couldn't display Python code using such "building block" structure. E.g. indented blocks could use colour and shape cues to reinforce the structure of the code, just as Scratch does. That is an interesting idea. Perhaps I have been stuck in either/or thinking -- either graphical or textual. With tk Text (IDLE), it would be possible to tag each (4-space) indent with a color for the compound statememt keywork causing the indent. And if you want to see another reason why text rocks as the core for programming languages? "Oh no! We're having trouble displaying this Scratch project. If you are on a mobile phone or tablet, try visiting this project on a computer. If you're on a computer, your Flash player might be disabled, missing, or out of date." I had to enable Flash for this site. What are they going to do when Flash is dead rather than just dying? (Get with html5, perhaps?) Yeah, thanks guys. Really helpful. -- Terry Jan Reedy -- https://mail.python.org/mailman/listinfo/python-list
Re: Guido sees the light: PEP 8 updated
On Wed, Apr 20, 2016 at 11:38 AM, Steven D'Aprano wrote: > As for "visual programming languages" (languages with an inherent visual > form which lacks any simple or obvious text equivalent), they've been a > dead-end. Even languages like Scratch cannot do without text. Look at > the "Hello World" program here: > > https://en.wikipedia.org/wiki/File:Scratch_Hello_World.png > > The graphical elements are pure presentation, to make it more palatable to > children and beginners. > > Don't think that I'm opposed to such visual presentations. Scratch itself is aimed at children, but there's a very similar language (or maybe it's actually a Scratch derivative) used by the Unreal Engine to animate sprites - the "blueprint" system. I've seen it used by someone who doesn't consider herself a programmer in any way, yet she has a sufficiently logical mind to do the same kind of work as programming requires. Effectively, flow control has been turned into a two-dimensional graph, with nodes pointing to other nodes, but each node is still described primarily with text (using colour to add instant recognition). I think there's a lot of value in depicting flow control graphically. For anyone who's accustomed to working visually, seeing nice little tagged blocks of "stuff", linked by little lines to show how you get from one to another, is way easier to handle than a page of "while" and "if" and "else" statements. But even there, each piece of flow control is *defined* in text - there's a short message saying what the condition is, and then two or more pieces of text defining the potential results of the condition, from which you can link to destinations. https://www.twitch.tv/ellalune/v/59455498 - starts at about the 41 minute mark. Notably, around the 00:42:30 point, I say that this is code, and she says that, well, it sort of is code, but it doesn't *feel* like code. Probably the least text-y form of coding that I've ever seen is turtle graphics, where you depict something using (usually) two dimensional movement and rotation. But even there, it's normal to use text to define all the actual actions. Take this, for example: https://studio.code.org/s/frozen/reset A nice tutorial, a theme that'll appeal to a lot of people (including young children), and primarily point-and-click (or drag) to move components around - but you can *read* the meaning of each component, in *text*. Once again, it uses a visual representation of flow control to bury some of the complexity, but the basic actions (move, turn, etc) are text - and if you want to "capture" a series of actions to reuse, the way to do that is to give it a name, because names and words are how people think. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: Guido sees the light: PEP 8 updated
On Tue, Apr 19, 2016, at 20:34, Steven D'Aprano wrote: > That's not the sense of being discussed here. Yes it is - this started as a discussion of whether indentation and alignment should be based on fixed spaces (as text editors support) or dynamic tab stops (as any word processing format supports). > How absurd. Why should a > letter containing nothing but text be classified as "not text" because it > was written in Microsoft World or LibreOffice rather than vi or emacs? Because it's not _a text file_. It's not obligated to be devoid of formatting markup or other metadata, or to have a perfectly flat structure, or to be edited in programs whose design has not been updated since the early 1970s, which are _exactly_ the complaints leveled against python source code at the start of this discussion.. __ : Python :: MS Word : Plain Text -- https://mail.python.org/mailman/listinfo/python-list
Re: Guido sees the light: PEP 8 updated
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. -- https://mail.python.org/mailman/listinfo/python-list
Re: Guido sees the light: PEP 8 updated
On Wed, 20 Apr 2016 04:54 am, Random832 wrote: > You could, for example, design a programming language that uses XML > markup to associate comments with specific positions in the code and the > editor displays them in little callout boxes when you hover over them > with the mouse. That's not done because of the notion that code has to > be plain text. No, it's not done because the user interface of such a language would be absolute bollocks. The reason programmers use text for communicating with (1) other programmers and (2) the computer is that text is still, and probably always will be, so much better than any other media *for the purpose of programming* as to make it no contest. I'm sure that interpretive dance has its uses, but can you imagine the computer infrastructure needed to make that practical for programming? More seriously, there have been attempts to come up with "point and click" interfaces for programming. The idea makes a sort of sense, if you think of programming as a flow-chart (does anyone still use them?), but outside of a handful of specialist areas, they have been a total, utter dead-end. So-called "visual programming environments" (think: Visual Basic) are well-suited to laying out the interface of GUI applications. They might even be useful for extremely limited mini-languages like regexes. I'm told that there are still people who think that UML diagrams are a good idea. They're probably good for dataflow programming. But ultimately, to be productive with one, you still need text. As for "visual programming languages" (languages with an inherent visual form which lacks any simple or obvious text equivalent), they've been a dead-end. Even languages like Scratch cannot do without text. Look at the "Hello World" program here: https://en.wikipedia.org/wiki/File:Scratch_Hello_World.png The graphical elements are pure presentation, to make it more palatable to children and beginners. Don't think that I'm opposed to such visual presentations. Look at the sample code shown at the top of the page here: https://scratch.mit.edu/ It kinda looks like Hypertalk syntax, which some of you may remember I'm exceedingly fond of. There's no reason why a GUI editor couldn't display Python code using such "building block" structure. E.g. indented blocks could use colour and shape cues to reinforce the structure of the code, just as Scratch does. And if you want to see another reason why text rocks as the core for programming languages? "Oh no! We're having trouble displaying this Scratch project. If you are on a mobile phone or tablet, try visiting this project on a computer. If you're on a computer, your Flash player might be disabled, missing, or out of date." Yeah, thanks guys. Really helpful. -- Steven -- https://mail.python.org/mailman/listinfo/python-list
Re: Guido sees the light: PEP 8 updated
On Wed, 20 Apr 2016 07:35 am, Marko Rauhamaa wrote: > The "plain text" content type is used less and less. Really it is > reserved mostly to programmers. Even texters routinely field animated > emojies nowadays. Who cares about "plain text" content type? That is not the beginning or end of what counts as text. By that ridiculously limited definition, Python progammers have already "moved on from text", because the MIME type of .py source code is application/x-python. > Text, in general, might have started to decline. o_O People today, especially the young, probably send more text today than in any previous time in history. You might have heard of something called "SMSes"? Kids today spend half their day SMSing, twitting, posting comments on Facebook, etc. And the other half taking selfies. *wink* Anyone who thinks that we're heading back to hieroglyphics simply isn't paying attention. -- Steven -- https://mail.python.org/mailman/listinfo/python-list
Re: Guido sees the light: PEP 8 updated
On Wed, 20 Apr 2016 04:54 am, Random832 wrote: > None of those are "text" in the sense being discussed here, which is > "preferred method of viewing and editing is a text editor". That's not the sense of being discussed here. How absurd. Why should a letter containing nothing but text be classified as "not text" because it was written in Microsoft World or LibreOffice rather than vi or emacs? -- Steven -- https://mail.python.org/mailman/listinfo/python-list
Re: Guido sees the light: PEP 8 updated
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 -- https://mail.python.org/mailman/listinfo/python-list
Re: Guido sees the light: PEP 8 updated
On 2016-04-19 14:54, Random832 wrote: > On Tue, Apr 19, 2016, at 13:43, Tim Chase wrote: > > Well, let's take a look at their native file formats: > > Inkscape: SVG > > Libreoffice: compressed XML > > Firefox: HTML+CSS+JS > > Musescore: compressed text > > Dia: compressed XML > > None of those are "text" in the sense being discussed here, which is > "preferred method of viewing and editing is a text editor". Well, my preferred method of "viewing" python code is /usr/bin/python Authoring, editing, and consuming are all distinct actions. Yes, a lot of tools can use libpcap to interface with wireshark dumps, but if your tool doesn't talk pcap, you can dump to plain-text (as Dennis mentions doing...well, XML) which is the lingua franca of tool development. > You could, for example, design a programming language that uses XML > markup [shudders at remembering using a DSL "programming language" that was XML] -tkc -- https://mail.python.org/mailman/listinfo/python-list
Re: Guido sees the light: PEP 8 updated
On Wed, Apr 20, 2016 at 9:22 AM, Grant Edwards wrote: > On 2016-04-19, Chris Angelico wrote: >> On Wed, Apr 20, 2016 at 6:50 AM, Ben Finney >> 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: >>> >>> You haven't supported that claim at all, and I see endless text everyday >>> in ???the rest of the world???. So your claim is false. >> >> In this part of the world, I'm seeing a lot of emails/news posts that >> consist of text. How does the rest of the world discuss important >> topics? Is everything done with infographics and meme pics? > > Emojis, one would assume. > What, like characters in the U+1F300-U+1F64F codepoint range? ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: Guido sees the light: PEP 8 updated
On 2016-04-19, Chris Angelico wrote: > On Wed, Apr 20, 2016 at 6:50 AM, Ben Finney > 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: >> >> You haven't supported that claim at all, and I see endless text everyday >> in ???the rest of the world???. So your claim is false. > > In this part of the world, I'm seeing a lot of emails/news posts that > consist of text. How does the rest of the world discuss important > topics? Is everything done with infographics and meme pics? Emojis, one would assume. -- Grant -- https://mail.python.org/mailman/listinfo/python-list
Re: Guido sees the light: PEP 8 updated
On Tuesday, April 19, 2016 at 1:59:48 PM UTC-7, Chris Angelico wrote: > On Wed, Apr 20, 2016 at 6:50 AM, Ben Finney > 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: > > > > You haven't supported that claim at all, and I see endless text everyday > > in "the rest of the world". So your claim is false. > > In this part of the world, I'm seeing a lot of emails/news posts that > consist of text. How does the rest of the world discuss important > topics? Is everything done with infographics and meme pics? > > ChrisA > not that this is exactly an important topic, really... Personally, I prefer smoke signals. Range is decent, but the bandwidth is atrocious. -- https://mail.python.org/mailman/listinfo/python-list
Re: Guido sees the light: PEP 8 updated
Chris Angelico : > On Wed, Apr 20, 2016 at 6:50 AM, Ben Finney > 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: >> >> You haven't supported that claim at all, and I see endless text everyday >> in “the rest of the world”. So your claim is false. > > In this part of the world, I'm seeing a lot of emails/news posts that > consist of text. How does the rest of the world discuss important > topics? Is everything done with infographics and meme pics? The "plain text" content type is used less and less. Really it is reserved mostly to programmers. Even texters routinely field animated emojies nowadays. Text, in general, might have started to decline. I'm foreseeing a not-too-distant future where only a smallish group of trained scribes masters reading and writing. The remainder of the population will consume and interact with animated pictures, videos, music, games etc. Back to ancient Egypt. Just look at the US presidential primaries, where the political discourse seems to be centered on grunts, melees and simple slogans: “We won the evangelicals,” Trump said. “We won with young. We won with old. We won with highly educated. We won with poorly educated. I love the poorly educated.” https://www.yahoo.com/news/trump-i-love-the-poorly-educated-144 008662.html> My point is not political; I'm only talking about the communication media. The medieval populace regarded the Latin-spewing theologians with awe. Maybe one day, the same superstitious respect will be afforded to trained Python masters who can bend the machines to their will. Marko -- https://mail.python.org/mailman/listinfo/python-list
Re: Guido sees the light: PEP 8 updated
On Wed, Apr 20, 2016 at 6:50 AM, Ben Finney 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: > > You haven't supported that claim at all, and I see endless text everyday > in “the rest of the world”. So your claim is false. In this part of the world, I'm seeing a lot of emails/news posts that consist of text. How does the rest of the world discuss important topics? Is everything done with infographics and meme pics? ChrisA not that this is exactly an important topic, really... -- https://mail.python.org/mailman/listinfo/python-list
Re: Guido sees the light: PEP 8 updated
Rustom Mody writes: > 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 and > you will get for example: That supports a claim of “there are many programs available that primarily manipulate something other than text”. You didn't make that claim, so providing support for that is irrelevant. Your actual claim is that “the rest of the world has moved on from text”. You haven't supported that claim at all, and I see endless text everyday in “the rest of the world”. So your claim is false. -- \ “I do not believe in immortality of the individual, and I | `\consider ethics to be an exclusively human concern with no | _o__) superhuman authority behind it.” —Albert Einstein, letter, 1953 | Ben Finney -- https://mail.python.org/mailman/listinfo/python-list
Re: Guido sees the light: PEP 8 updated
On Tue, Apr 19, 2016, at 13:43, Tim Chase wrote: > Well, let's take a look at their native file formats: > > Inkscape: SVG > > Libreoffice: compressed XML > > Firefox: HTML+CSS+JS > > Musescore: compressed text > > Dia: compressed XML None of those are "text" in the sense being discussed here, which is "preferred method of viewing and editing is a text editor". You could, for example, design a programming language that uses XML markup to associate comments with specific positions in the code and the editor displays them in little callout boxes when you hover over them with the mouse. That's not done because of the notion that code has to be plain text. The fact that the resulting format would still be a text format that could theoretically be edited with a text editor isn't relevant to this discussion. -- https://mail.python.org/mailman/listinfo/python-list
Re: Guido sees the light: PEP 8 updated
On Tuesday, April 19, 2016 at 11:17:23 PM UTC+5:30, Tim Chase wrote: > On 2016-04-19 09:46, Rustom Mody wrote: > > inkscape > > gimp > > blender > > libreoffice writer/calc/prese > > wireshark > > skype > > firefox > > audacity > > musescore > > totem > > vlc > > dia > > > > Do these look like text-based apps to you? > > Well, let's take a look at their native file formats: > > Inkscape: SVG > > Libreoffice: compressed XML > > Firefox: HTML+CSS+JS > > Musescore: compressed text > > Dia: compressed XML > > While I haven't used Musescore, I have used the others and > hand-edited the files in each case. Using vi/vim, or even ed(1). > Because I can, and sometimes because I have to in order to do some > convoluted process that would be a pain to do in a GUI. If you think xml/html is ok as replacement for text then we have no significant disagreement. That is after all the main point of http://blog.languager.org/2012/10/html-is-why-mess-in-programming-syntax.html viz that program texts would be better off replacing text with hypertext. [that html = Hyper Text Markup Language adds to the snark; but does not change the message] The key difference between all the above and state of art in programming languages is that lexing, parsing is in principle and possibly in practice 'outsourced' to generic XML tools. With programming languages these are in silos in the innards of the language implementation. And so people typically studying compilers etc come to think of lexing and parsing as important/key activities except for a few outliers like Marvin Minsky: http://web.media.mit.edu/~minsky/papers/TuringLecture/TuringLecture.html -- https://mail.python.org/mailman/listinfo/python-list
Re: Guido sees the light: PEP 8 updated
On 2016-04-19 09:46, Rustom Mody wrote: > inkscape > gimp > blender > libreoffice writer/calc/prese > wireshark > skype > firefox > audacity > musescore > totem > vlc > dia > > Do these look like text-based apps to you? Well, let's take a look at their native file formats: Inkscape: SVG Libreoffice: compressed XML Firefox: HTML+CSS+JS Musescore: compressed text Dia: compressed XML While I haven't used Musescore, I have used the others and hand-edited the files in each case. Using vi/vim, or even ed(1). Because I can, and sometimes because I have to in order to do some convoluted process that would be a pain to do in a GUI. For Gimp, Blender, Audacity, Totem, and VLC, those all deal with binary streams of their content-type. Skype being proprietary, it doesn't interoperate with bupkis. So wireshark is the only outlier in my mind, though since it captures binary packets, I suspect the native format is optimized for streaming stuff from the NIC to the disk as fast as possible (though given CPU and disk speeds, I would have figured that a gzipped stream of text markup would be almost as good). -tkc -- https://mail.python.org/mailman/listinfo/python-list
Re: Guido sees the light: PEP 8 updated
On Wed, 20 Apr 2016 01:50:00 +1000, Steven D'Aprano wrote: > Anyone who has played (say) Dungeons and Dragons, or other role-playing > games, will know that events with a probability of 1 in 20 occur very > frequently. To be precise, they occur one time in twenty. > Million to 1 chances happen 9 time out of Ten (T prachett - Varius Discworld books :-) ) > Even if the claimed results are correct, how strong is the effect? > > (a) On average, Canadian students get 49.0% on a standard exam that > Chinese students get 89.0% for. > > (b) On average, Canadian students get 49.0% on a standard exam that > Chinese students get 49.1% for. > > The level of statistical significance is not related to the strength of > the effect: we can be very confident of small effects, and weakly > confident of large effects. -- If anyone has seen my dog, please contact me at x2883 as soon as possible. We're offering a substantial reward. He's a sable collie, with three legs, blind in his left eye, is missing part of his right ear and the tip of his tail. He's been recently fixed. Answers to "Lucky". -- https://mail.python.org/mailman/listinfo/python-list
Re: Guido sees the light: PEP 8 updated
On Tue, Apr 19, 2016 at 11:50 AM, Steven D'Aprano wrote: > On Wed, 20 Apr 2016 12:54 am, Rustom Mody wrote: > > >> I wonder who the joke is on: >> >> | A study comparing Canadian and Chinese students found that the latter >> | were better at complex maths > > Most published studies are wrong. > > http://www.ncbi.nlm.nih.gov/pmc/articles/PMC1182327/ > > - Has that study been replicated by others? Have people tried to > replicate it? Were negative findings published, or do they > languish in some researcher's bottom drawer? (Publication bias > is a big problem in research.) > > - Was the study well-designed, and the given conclusions supported > by the study? How well did it survive the critical attention of > experts in that field? Did the study account for differences in > mathematics education? > > - Did the study have sufficient statistical power to support the > claimed results? Most published studies are invalid since they > simply lack the power to justify their conclusion. > > - Is the effect due to chance? Remember, with a p-value of 0.05 (the > so-called 95% significance level), one in twenty experiments will > give a positive result just by chance. A p-value of 0.05 does not > mean "these results are proven", it just means "if every single > thing about this experiment is perfect, then the chances that these > results are due by chance alone is 1 in 20". > > Anyone who has played (say) Dungeons and Dragons, or other role-playing > games, will know that events with a probability of 1 in 20 occur very > frequently. To be precise, they occur one time in twenty. > > Even if the claimed results are correct, how strong is the effect? > > (a) On average, Canadian students get 49.0% on a standard exam that Chinese > students get 89.0% for. > > (b) On average, Canadian students get 49.0% on a standard exam that Chinese > students get 49.1% for. > > The level of statistical significance is not related to the strength of the > effect: we can be very confident of small effects, and weakly confident of > large effects. 85% of all statistics are made up. -- https://mail.python.org/mailman/listinfo/python-list
Re: Guido sees the light: PEP 8 updated
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 and you will get for example: inkscape gimp blender libreoffice writer/calc/prese wireshark skype firefox audacity musescore totem vlc dia Do these look like text-based apps to you? > Text > still makes up by far the bulk of human communication. It's compact (one > second of a Youtube video requires about the same bandwidth as about 7000 > words), it can be easily searched, edited, translated, the presentation can > be changed to suit the reader, and more. Yes so you just showed that in the realm of multimedia we are somewhere nearabouts... tickertape? Hollerith cards? Doesn't change the basic structure of the human being viz that 5 senses working in harmony make us more productive than one overworking rest languishing > When precision of meaning is > important, text is still the winner except in a few specialist areas, such > as technical drawings, and even they still make extensive use of text. Yes in the short to medium run our text capability remains better than others. Those who want to keep it so forever are keeping the rest of us back fortunately futilely! -- https://mail.python.org/mailman/listinfo/python-list
Re: Guido sees the light: PEP 8 updated
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. Text still makes up by far the bulk of human communication. It's compact (one second of a Youtube video requires about the same bandwidth as about 7000 words), it can be easily searched, edited, translated, the presentation can be changed to suit the reader, and more. When precision of meaning is important, text is still the winner except in a few specialist areas, such as technical drawings, and even they still make extensive use of text. -- Steven -- https://mail.python.org/mailman/listinfo/python-list
Re: Guido sees the light: PEP 8 updated
On Wed, 20 Apr 2016 01:50 am, Steven D'Aprano wrote: > - Is the effect due to chance? Remember, with a p-value of 0.05 (the > so-called 95% significance level), one in twenty experiments will > give a positive result just by chance. A p-value of 0.05 does not > mean "these results are proven", it just means "if every single > thing about this experiment is perfect, then the chances that these > results are due by chance alone is 1 in 20". Arggh! The above is, of course, *wrong*. This is why statistical significance is so hard. I know the correct interpretation[1] of p-values and I still got it wrong. p-values give the probability of a positive result by chance if the null hypothesis is true, that is, the chances of getting a false positive result. "We detected a difference that actually isn't there." It *doesn't* tell you anything about a false negative result: "We failed to detect a difference which actually is there." And it certainly doesn't tell you the chances that the result are true. More here: https://www.sciencenews.org/article/odds-are-its-wrong [1] At least, I'm confident I understand p-values with a 95% significance level. -- Steven -- https://mail.python.org/mailman/listinfo/python-list
Re: Guido sees the light: PEP 8 updated
On Wed, 20 Apr 2016 12:54 am, Rustom Mody wrote: > I wonder who the joke is on: > > | A study comparing Canadian and Chinese students found that the latter > | were better at complex maths Most published studies are wrong. http://www.ncbi.nlm.nih.gov/pmc/articles/PMC1182327/ - Has that study been replicated by others? Have people tried to replicate it? Were negative findings published, or do they languish in some researcher's bottom drawer? (Publication bias is a big problem in research.) - Was the study well-designed, and the given conclusions supported by the study? How well did it survive the critical attention of experts in that field? Did the study account for differences in mathematics education? - Did the study have sufficient statistical power to support the claimed results? Most published studies are invalid since they simply lack the power to justify their conclusion. - Is the effect due to chance? Remember, with a p-value of 0.05 (the so-called 95% significance level), one in twenty experiments will give a positive result just by chance. A p-value of 0.05 does not mean "these results are proven", it just means "if every single thing about this experiment is perfect, then the chances that these results are due by chance alone is 1 in 20". Anyone who has played (say) Dungeons and Dragons, or other role-playing games, will know that events with a probability of 1 in 20 occur very frequently. To be precise, they occur one time in twenty. Even if the claimed results are correct, how strong is the effect? (a) On average, Canadian students get 49.0% on a standard exam that Chinese students get 89.0% for. (b) On average, Canadian students get 49.0% on a standard exam that Chinese students get 49.1% for. The level of statistical significance is not related to the strength of the effect: we can be very confident of small effects, and weakly confident of large effects. -- Steven -- https://mail.python.org/mailman/listinfo/python-list
Re: Guido sees the light: PEP 8 updated
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 , hash, space, comment. No fancy aligning. -tkc -- https://mail.python.org/mailman/listinfo/python-list
Re: Guido sees the light: PEP 8 updated
On Tuesday, April 19, 2016 at 7:46:21 PM UTC+5:30, Grant Edwards wrote: > On 2016-04-19, Pete Forman wrote: > > > My question asks why monospace is used for the text. > > Well, I always use a monospaced font for code because I find it helps > readability for things like tables of data, block comments, and lines > of code that have some sort of parallel structure that I want to be > obvious to the reader. > > > And more generally that programmers sticking to text when rest of > > world has moved on is rather backward: > > http://blog.languager.org/2012/10/html-is-why-mess-in-programming-syntax.html > > The same reason humans use written and spoken language rather than > just drawing pictures, pointing, and grunting? I wonder who the joke is on: | A study comparing Canadian and Chinese students found that the latter were | better at complex maths | Native English speakers rely more on additional brain regions involved in the | meaning of words, whereas native Chinese speakers rely more on additional | brain regions involved in the visual appearance and physical manipulation of | numbers, from : https://www.newscientist.com/article/dn9422-mother-tongue-may-determine-maths-skills/ -- https://mail.python.org/mailman/listinfo/python-list
Re: Guido sees the light: PEP 8 updated
On 2016-04-18 21:14:02 +, 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. -- https://mail.python.org/mailman/listinfo/python-list
Re: Guido sees the light: PEP 8 updated
On Wed, Apr 20, 2016 at 12:15 AM, Grant Edwards wrote: >> And more generally that programmers sticking to text when rest of >> world has moved on is rather backward: >> http://blog.languager.org/2012/10/html-is-why-mess-in-programming-syntax.html > > The same reason humans use written and spoken language rather than > just drawing pictures, pointing, and grunting? http://catb.org/esr/writings/unix-koans/gui-programmer.html ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: Guido sees the light: PEP 8 updated
On Tuesday, April 19, 2016 at 7:30:18 PM UTC+5:30, Tim Chase wrote: > On 2016-04-19 04:37, Rustom Mody wrote: > > > No, they will not, because they'll make your code proprietary. > > > > Pragmatically yes; theoretically no because its like saying > > "If one dont want to get locked down to MSWord proprietary tools > > and formats one should use latex" > > Refuted by the fact that libreoffice and odf etc are free/open > > Except that I still regularly have trouble with consistent formatting > being portable between LO/OO.o/MSWord (heck, I still have trouble > with MS Word not being consistent between versions). 1. That libre is in sux category compared to MS 2. That MS does legal and illegal things to lock people in 3. And other charms of civilized existence naturally conduce us to the most rational choice - luddeiteism Fortunately or unfortunately we dont always make rational choices :-) text files are a luddite choice They work in the same way that pen-n-paper keep working when the power fails and computer is down -- https://mail.python.org/mailman/listinfo/python-list
Re: Guido sees the light: PEP 8 updated
On 2016-04-19, Pete Forman wrote: > My question asks why monospace is used for the text. Well, I always use a monospaced font for code because I find it helps readability for things like tables of data, block comments, and lines of code that have some sort of parallel structure that I want to be obvious to the reader. > And more generally that programmers sticking to text when rest of > world has moved on is rather backward: > http://blog.languager.org/2012/10/html-is-why-mess-in-programming-syntax.html The same reason humans use written and spoken language rather than just drawing pictures, pointing, and grunting? -- Grant Edwards grant.b.edwardsYow! What a COINCIDENCE! at I'm an authorized "SNOOTS gmail.comOF THE STARS" dealer!! -- https://mail.python.org/mailman/listinfo/python-list
Re: Guido sees the light: PEP 8 updated
On Wed, Apr 20, 2016 at 12:05 AM, Random832 wrote: > Source file contains: > ### Lorem ipsum dolor sit amet, consectetur adipiscing elit. Etiam > ### ut mattis leo. In sed arcu gravida, consequat tellus placerat, > ### ullamcorper metus. > if foo: > if bar: > do stuff > ### > some other stuff > > (the last ### is just an empty comment to push stuff after it down past > the first comment - if another comment is there instead, it will be > displayed starting from the "some other stuff" line) > > Displays as: > > if foo: # Lorem ipsum dolor sit amet, consectetur > if bar: # adipiscing elit. Etiam ut mattis leo. In sed > do stuff # arcu gravida, consequat tellus > # placerat, ullamcorper metus. > > some other stuff Why does it need to be displayed to the right, though? Do we gain anything by not having the comment above the code? ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: Guido sees the light: PEP 8 updated
On Tue, Apr 19, 2016, at 08:55, Rustom Mody wrote: > > Like, it ends up looking like this: > > > > if foo("what if it's a much longer condition"):# comment > > do something # > > comment2 > > > > There's no way to get this: > > > > if foo("what if it's a much longer condition"): # comment > > do something # comment2 > > I get it looking quite nice if I put a tab between "foo" and "(" > Is that an acceptable solution?? Dunno... No, because what if "foo" is much longer? You could put a tab after "if", but that means while-blocks are indented further than if-blocks. And that just delays the problem to the third indent block, you've got to find something to line that up to. if foo("blah blah blah"): # comment if bar("etc etc etc etc"): # comment do stuff# comment becomes if foo ("blah blah blah"):# comment if bar ("etc etc etc etc"): # comment do stuff # comment Maybe what we really need is a way to _display_ a multiline comment at the right margin (and hanging down for as many lines as it needs), without having it baked into the source code that way. Source file contains: ### Lorem ipsum dolor sit amet, consectetur adipiscing elit. Etiam ### ut mattis leo. In sed arcu gravida, consequat tellus placerat, ### ullamcorper metus. if foo: if bar: do stuff ### some other stuff (the last ### is just an empty comment to push stuff after it down past the first comment - if another comment is there instead, it will be displayed starting from the "some other stuff" line) Displays as: if foo: # Lorem ipsum dolor sit amet, consectetur if bar: # adipiscing elit. Etiam ut mattis leo. In sed do stuff # arcu gravida, consequat tellus # placerat, ullamcorper metus. some other stuff -- https://mail.python.org/mailman/listinfo/python-list
Re: Guido sees the light: PEP 8 updated
On 2016-04-19 04:37, Rustom Mody wrote: > > No, they will not, because they'll make your code proprietary. > > Pragmatically yes; theoretically no because its like saying > "If one dont want to get locked down to MSWord proprietary tools > and formats one should use latex" > Refuted by the fact that libreoffice and odf etc are free/open Except that I still regularly have trouble with consistent formatting being portable between LO/OO.o/MSWord (heck, I still have trouble with MS Word not being consistent between versions). -tkc -- https://mail.python.org/mailman/listinfo/python-list
Re: Guido sees the light: PEP 8 updated
On Tue, Apr 19, 2016 at 11:31 PM, Tim Chase 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 -- https://mail.python.org/mailman/listinfo/python-list
Re: Guido sees the light: PEP 8 updated
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 -- https://mail.python.org/mailman/listinfo/python-list
Re: Guido sees the light: PEP 8 updated
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 -- https://mail.python.org/mailman/listinfo/python-list
Re: Guido sees the light: PEP 8 updated
On Tuesday, April 19, 2016 at 9:41:24 AM UTC+5:30, Random832 wrote: > On Mon, Apr 18, 2016, at 23:54, Rustom Mody wrote: > > Start no tabs: > > if foo# comment that is aligned > > do some stuff# across multiple indent levels > > > > Add tabs as leading indents with second line indented 1 tab more > > (showing tabs as |) > > |if foo# comment that is aligned > > ||do some stuff# across multiple indent levels > > > > Indent the first comment with 2 tabs > > At this point the first comment is/shows lefter than the second > > > > Indent the second with 1 tab -- the two #es now line up > > Yeah but now the second line of code is to the right of the whole first > line of code. "if foo" must have been too short to illustrate it (it's > long enough if a tab is four spaces, but I guess it's longer in the > sample), but I assumed you would get the concept of what I was saying > and try putting something longer there or try extending the comments in > the C code the sample preloads. > > Like, it ends up looking like this: > > if foo("what if it's a much longer condition"):# comment > do something # > comment2 > > There's no way to get this: > > if foo("what if it's a much longer condition"): # comment > do something # comment2 I get it looking quite nice if I put a tab between "foo" and "(" Is that an acceptable solution?? Dunno... html tables need all sorts of 'un-table-ifying' options eg column/row groups, tables within tables and what not. At which point we cross the point of diminishing returns is not clear when we are still armchair discussing. For something a bit more practical here is emacs (orgtbl mode) doing html tables: https://www.youtube.com/watch?v=EQAd41VAXWo -- https://mail.python.org/mailman/listinfo/python-list
Re: Guido sees the light: PEP 8 updated
Rustom Mody : > In the same way and like colorforth, it would be better to distinguish > identifier from > identifier rather than the current status of > distinguishing identifier from Identifier But then we have a slippery > slope: Should be same/distinct from ? 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 -- https://mail.python.org/mailman/listinfo/python-list
Re: Guido sees the light: PEP 8 updated
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 identifier from identifier rather than the current status of distinguishing identifier from Identifier But then we have a slippery slope: Should be same/distinct from ? -- https://mail.python.org/mailman/listinfo/python-list
Re: Guido sees the light: PEP 8 updated
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! Marko -- https://mail.python.org/mailman/listinfo/python-list
Re: Guido sees the light: PEP 8 updated
On Tuesday, April 19, 2016 at 1:47:48 PM UTC+5:30, Chris Angelico wrote: > On Tue, Apr 19, 2016 at 6:09 PM, Marko Rauhamaa wrote: > > Now, descending back on earth, I don't believe the advantages of rich > > source code will outweigh those of plain text in the foreseeable future. > > No, they will not, because they'll make your code proprietary. Pragmatically yes; theoretically no because its like saying "If one dont want to get locked down to MSWord proprietary tools and formats one should use latex" Refuted by the fact that libreoffice and odf etc are free/open > Suddenly *nothing* else will viably work with your code. (And before > you say "but diff tools are fine with XML/JSON/YAML/whatever", it's > not that simple; as soon as the underlying structure is capable of > representing information that doesn't matter to your source code, you > open yourself up to diff noise. You just nicely described how diff is ½-assed. In more detail here is foo.txt foo1.txt and foo2.txt containing --- Now is the time for all good men to come to the aid of their country --- vi, emacs, shell (cat) show them right and having the same contents However diff (and therefore unfortunately git) have no clue that one has DOS line-endings and one is UTF-16 > I've had this exact problem with > git-managing my OBS configs, which are JSON files; there's one > particular array that's effectively a set, and the file keeps > reordering itself. I had to write a pre-commit script that sorts them > into a consistent order, else I'd have had useless diffs.) If you are ok with json morphing to yaml you may find ruamel useful http://stackoverflow.com/questions/5121931/in-python-how-can-you-load-yaml-mappings-as-ordereddicts https://pypi.python.org/pypi/ruamel.yaml -- https://mail.python.org/mailman/listinfo/python-list
Re: Guido sees the light: PEP 8 updated
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. -- https://mail.python.org/mailman/listinfo/python-list
Re: Guido sees the light: PEP 8 updated
On Tue, Apr 19, 2016 at 6:09 PM, Marko Rauhamaa wrote: > Now, descending back on earth, I don't believe the advantages of rich > source code will outweigh those of plain text in the foreseeable future. No, they will not, because they'll make your code proprietary. Suddenly *nothing* else will viably work with your code. (And before you say "but diff tools are fine with XML/JSON/YAML/whatever", it's not that simple; as soon as the underlying structure is capable of representing information that doesn't matter to your source code, you open yourself up to diff noise. I've had this exact problem with git-managing my OBS configs, which are JSON files; there's one particular array that's effectively a set, and the file keeps reordering itself. I had to write a pre-commit script that sorts them into a consistent order, else I'd have had useless diffs.) Of course, there's no such thing as "plain text". Encodings will always bite you. But if you can depend on all files being (a) binary, (b) UTF-8, or (c) tagged with a coding cookie, it's not too hard to work with other people's files. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: Guido sees the light: PEP 8 updated
Pete Forman : > I like that Nick separates out the concept of alignment with implicit > semantics from the n spaces v tabs arguments. My question asks why > monospace is used for the text. Because the so-called "plain text" is the age-old lowest common denominator for formal syntax. Python is especially picky about alignment, but the same de-facto assumption is critical pretty much in any programming language from Pascal to Go. Old computer science textbooks presenting algorithms in Algol, Pascal or, say, process algebra, did use varying-width fonts but they were typeset manually. You *could* liberate programming languages from the monospace stranglehold but then you couldn't effectively use "cat", "vi" or "firefox" to display Python programs. You probably would need to wrap the source code in some richer markup like XML and support it specially in the editors. Such enrichment would offer advantages. For example, the visual layout wouldn't necessarily have to be rigid. No more line-length wars (no lines would ever need to be "continued"). No more TAB wars. Comments could be displayed as floating bubbles, or maybe you would have to scratch the screen to see the comment text. Why, you could even decide on local language variations. How about braces to delineate blocks in Python? How about translating the keywords into Japanese? How about setting the Python code right-to-left with Hebrew keywords? Now, descending back on earth, I don't believe the advantages of rich source code will outweigh those of plain text in the foreseeable future. Marko -- https://mail.python.org/mailman/listinfo/python-list
Re: Guido sees the light: PEP 8 updated
Pete Forman writes: > My question asks why monospace is used for the text. Used by whom? Python the programming language (and that includes PEP 8) has nothing to say about what font you use in your text editor. -- \ “Why should I care about posterity? What's posterity ever done | `\for me?” —Groucho Marx | _o__) | Ben Finney -- https://mail.python.org/mailman/listinfo/python-list
Re: Guido sees the light: PEP 8 updated
Rustom Mody writes: > On Tuesday, April 19, 2016 at 6:49:34 AM UTC+5:30, sohcatoa wrote: >> On Monday, April 18, 2016 at 2:14:17 PM UTC-7, Pete Forman wrote: >> > 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. >> > >> > -- >> > Pete Forman >> >> "Why is it that Python continues to use a fixed width font " >> >> This guy is trolling, right? No, it is a genuine question. It applies to computer langauges in general but this thread is about PEP 8 so I framed it for Python. I was not proposing a change to the langauge. > See elastic tabstops: http://nickgravgaard.com/elastic-tabstops/ I like that Nick separates out the concept of alignment with implicit semantics from the n spaces v tabs arguments. My question asks why monospace is used for the text. > And more generally that programmers sticking to text when rest of > world has moved on is rather backward: > http://blog.languager.org/2012/10/html-is-why-mess-in-programming-syntax.html -- Pete Forman -- https://mail.python.org/mailman/listinfo/python-list
Re: Guido sees the light: PEP 8 updated
Ian Kelly wrote: What happens when another programmer reviews the code using a different font and finds that there is only 3.5em worth of space? Do we descend into Calibri / Verdana line-length edit wars? That's easy, we just decree that all Python source code is to be displayed in this font: http://fontstruct.com/fontstructions/show/89341/flying_circus -- Greg -- https://mail.python.org/mailman/listinfo/python-list
Re: Guido sees the light: PEP 8 updated
On Mon, Apr 18, 2016, at 23:54, Rustom Mody wrote: > Start no tabs: > if foo# comment that is aligned > do some stuff# across multiple indent levels > > Add tabs as leading indents with second line indented 1 tab more > (showing tabs as |) > |if foo# comment that is aligned > ||do some stuff# across multiple indent levels > > Indent the first comment with 2 tabs > At this point the first comment is/shows lefter than the second > > Indent the second with 1 tab -- the two #es now line up Yeah but now the second line of code is to the right of the whole first line of code. "if foo" must have been too short to illustrate it (it's long enough if a tab is four spaces, but I guess it's longer in the sample), but I assumed you would get the concept of what I was saying and try putting something longer there or try extending the comments in the C code the sample preloads. Like, it ends up looking like this: if foo("what if it's a much longer condition"):# comment do something # comment2 There's no way to get this: if foo("what if it's a much longer condition"): # comment do something # comment2 -- https://mail.python.org/mailman/listinfo/python-list
Re: Guido sees the light: PEP 8 updated
On Tuesday, April 19, 2016 at 9:00:12 AM UTC+5:30, Random832 wrote: > On Mon, Apr 18, 2016, at 23:04, Rustom Mody wrote: > > See elastic tabstops: http://nickgravgaard.com/elastic-tabstops/ > > >From there: > >A column block is a run of uninterrupted vertically adjacent cells. > > How's that going to handle this case: > > if foo: # comment that is aligned > do some stuff # across multiple indent levels Just tried it with the jar file¹ he supplies and it seems to work Start no tabs: if foo# comment that is aligned do some stuff# across multiple indent levels Add tabs as leading indents with second line indented 1 tab more (showing tabs as |) |if foo# comment that is aligned ||do some stuff# across multiple indent levels Indent the first comment with 2 tabs At this point the first comment is/shows lefter than the second Indent the second with 1 tab -- the two #es now line up The invariant of course is clear -- if the total no of tabs in the line prior to the char are equal then all such lines line up ¹ yeah thats not very secure! And does not work with open java, works with Sun/Oracle java -- https://mail.python.org/mailman/listinfo/python-list
Re: Guido sees the light: PEP 8 updated
On Mon, Apr 18, 2016, at 23:04, Rustom Mody wrote: > See elastic tabstops: http://nickgravgaard.com/elastic-tabstops/ >From there: >A column block is a run of uninterrupted vertically adjacent cells. How's that going to handle this case: if foo: # comment that is aligned do some stuff # across multiple indent levels As far as I can tell, the model being proposed would align the indented code either with the first line's comment, or somewhere after the colon. I think it's excessively "clever" to think you can or should use the same model to solve indentation as other forms of alignment. -- https://mail.python.org/mailman/listinfo/python-list
Re: Guido sees the light: PEP 8 updated
On Tuesday, April 19, 2016 at 6:49:34 AM UTC+5:30, sohcatoa wrote: > On Monday, April 18, 2016 at 2:14:17 PM UTC-7, Pete Forman wrote: > > 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. > > > > -- > > Pete Forman > > "Why is it that Python continues to use a fixed width font " > > This guy is trolling, right? See elastic tabstops: http://nickgravgaard.com/elastic-tabstops/ And more generally that programmers sticking to text when rest of world has moved on is rather backward: http://blog.languager.org/2012/10/html-is-why-mess-in-programming-syntax.html -- https://mail.python.org/mailman/listinfo/python-list
Re: Guido sees the light: PEP 8 updated
On Monday, April 18, 2016 at 2:14:17 PM UTC-7, Pete Forman wrote: > 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. > > -- > Pete Forman "Why is it that Python continues to use a fixed width font " This guy is trolling, right? -- https://mail.python.org/mailman/listinfo/python-list
Re: Guido sees the light: PEP 8 updated
Pete Forman writes: > Why is it that Python continues to use a fixed width font I think you know this isn't true. > and therefore specifies the maximum line width as a character count? and that this “therefore” is not justified by that. You've seen elsewhere the justification for *having* a maximum line width (primarily because of limits on human cognition of lines of text). As for what the limit *is*, it's much better to have an easy-to-apply and easy-to-measure rule, because consistent application is important for such a guide. Counting characters is objectively easy and easily comparable. -- \ “I think Western civilization is more enlightened precisely | `\ because we have learned how to ignore our religious leaders.” | _o__)—Bill Maher, 2003 | Ben Finney -- https://mail.python.org/mailman/listinfo/python-list
Re: Guido sees the light: PEP 8 updated
Ian Kelly writes: > On Mon, Apr 18, 2016 at 3:14 PM, Pete Forman wrote: >> 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. > > How many spaces is "4 em worth"? How would you incorporate that into > the Python compiler or a linter without needing to know what > particular font the programmer is using? What happens when another > programmer reviews the code using a different font and finds that > there is only 3.5em worth of space? Do we descend into Calibri / > Verdana line-length edit wars? 4 em is what PEP 8 implies, with the implicit use of a monospaced font. I was trying to convey that the mechanics of indentation was not relevant to my question about why Python and indeed other programming languages are rarely edited or viewed with proportional fonts. The programmer, other humans reading the source and the interpreter need to be able to discern structure by the indentation. It is what follows the indentation that interests me. The current Python interpreter will happily digest a combination of spaces and hard tabs as long as consistency rules are obeyed. My question was intended to concentrate on the presentation after the leading whitespace. -- Pete Forman -- https://mail.python.org/mailman/listinfo/python-list
Re: Guido sees the light: PEP 8 updated
On Mon, Apr 18, 2016 at 3:14 PM, Pete Forman wrote: > 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. How many spaces is "4 em worth"? How would you incorporate that into the Python compiler or a linter without needing to know what particular font the programmer is using? What happens when another programmer reviews the code using a different font and finds that there is only 3.5em worth of space? Do we descend into Calibri / Verdana line-length edit wars? -- https://mail.python.org/mailman/listinfo/python-list
Re: Guido sees the light: PEP 8 updated
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. -- Pete Forman -- https://mail.python.org/mailman/listinfo/python-list
Re: Guido sees the light: PEP 8 updated
On Sat, Apr 16, 2016 at 8:25 PM, Terry Reedy wrote: > On 4/16/2016 12:58 PM, Larry Martell wrote: > >> On Sat, Apr 16, 2016 at 12:51 PM, Marko Rauhamaa >> wrote: >> >>> Larry Martell : >>> >>> I have worked for many companies where you are required to get a clean run of pep8 on your code before your pull request will even be considered for approval. I don't agree with this at all, as I think it makes the code very ugly, especially enforcing the max line length. >>> >>> Agh, I was with you until your last remark. >>> >>> A max line length of 79 characters is among the *only* rigorous >>> principles I judge coding style on. >>> >>> It comes with the maxim that one function must be visible at once on the >>> screen. >>> >> >> if we still had 1970's 80 character TTYs that would matter but on my >> 29" 1920x1080 screen it doesn't. >> > > It depends on whether one prefers to use the extra width to have long > lines or side-by-side windows. I prefer the latter. That's my use case as well, and why I admire the forethought in the width length. Side by side windows rock when doing TTD. -Sivan -- https://mail.python.org/mailman/listinfo/python-list
Re: Guido sees the light: PEP 8 updated
2016-04-18 5:19 GMT+02:00 Steven D'Aprano : > On Mon, 18 Apr 2016 11:39 am, Rustom Mody wrote: > >> yes we can agree on this -- arbitrary line lengths are almost certainly >> unreadable. >> The problem then becomes so what is optimal? > > I really don't think it is a problem. We have about 400 years > of experience with printed text, and that experience tells us > that the optimal width for reading prose in Western languages > is about 60 characters, give or take. This width is optimal > for eye movement, and minimizes the number of errors and > reduces eye-strain. > > There's only so far that our eyes can follow a line to the > right without increasing stress or reading errors, and > likewise when returning back to the left margin. The longer > the line, the higher the chance of losing track, and the > physical effort it takes to read. (You have to move the eyes > further, and for extremely long lines, you may have to move > your entire head.) > > Long lines are simply harder to read because you have to > move your eyes more, and the longer the lines, the greater > the tendency to wander across the lines. Especially if the > lines are close together and the height of the lines is > small. (It boggles my mind how many programmers I've met who > routinely view their code in tiny physical heights, even > when reading it in fine detail.) > > The optimal width for eye-tracking (that is, the maximum > width for which the rate of such errors can be disregarded) > is somewhere about sixty characters per line. > > The same eye-tracking considerations apply to code, but: > > when it comes to code, we don't always have to track all the > way back to the left-hand margin. If we start (say) up to > twenty columns in, then we can afford to write up to twenty > columns further to the right too. > > > (Also, code tends to have VERY ragged right-hand margins. > Not all lines end up even close to sixty characters wide.) > > There are other considerations though. Unlike prose, with > code, shorter lines *may* sometimes force an increase in > complexity. For instance, temporary variables need to be > created, or new functions created, just to avoid otherwise > excessively long lines. So one might be willing to accept a > little more eye-movement for a little less code complexity. > > So allowing a total width of 80 (give or take) is already a > compromise from the optimal sixty characters. This compromise > allows for indented code, and allows up to 20 characters > extra to avoid creating more complexity elsewhere. > > > But there's another factor: long lines of code are themselves > a code-smell. Perhaps: > > - you have indented too deeply, suggesting that your function > is doing too much or has too much internal complexity: > > def func(): > if a: > for b in seq: > while c: > with d: > try: > try: > for e in it: > block # only 48 columns available here > > (But note also that even with this extreme example, eight > indentation levels deep, you can still fit almost > characters per line without breaking the 80-char limit. > You can do a lot in 50 characters.) > > > - you have too many expressions on one line, suggesting that > the over-all complexity of the line is excessive; > > - your variable or function names are needlessly verbose or > are doing too much or are too specific > ("calculate_number_of_pages_and_number_of_semicolons_in_chapter_one"); > > - or you are violating the rule of Demeter: > get(customer.trousers.pocket.wallet).open().money.pay(1) > > > In other words, long lines of code are themselves an > indication of poorly-designed code. Even though there are > exceptions, we should resist strongly the urge to extend > beyond the 60-80 (or perhaps 90 in extreme cases) limit. > Whenever I hear people saying that they regularly need to > use 100 or even 120 columns for their code, what I hear is > "my code is badly written". > > > > -- > Steven > > -- > https://mail.python.org/mailman/listinfo/python-list Excellent! Thank you for this contribution. -- https://mail.python.org/mailman/listinfo/python-list
Re: Guido sees the light: PEP 8 updated
On Monday, April 18, 2016 at 2:34:10 PM UTC+5:30, Gregory Ewing wrote: > Rustom Mody wrote: > > Come to think of it take an SQL DBMS browser. > > Should we say: Horizontal scrolls are BAD; just reformat the table after > > reaching 80 columns? > > I would say, yes, horizontal scrolling *is* bad in a table -- > probably even worse than it is for text or code. > > The reason is that tables are usually laid out so that > data items in a row are related to each other. You can't > make sense of a piece of data in the table without seeing > the other items in the same row. That's hard to do if > you can't see the whole row at once. "horizontal scrolling: BAD" + "Need to see whole row at once" How to reconcile these two? (Think of a 50 column table/spreadsheet) The only answer I know in DBMS lingo is "normalize" (refactor in programming lingo) which one way or other amounts to "Store some of those columns in your head" Obviously I am not against normalization when it actually cleans up I am against normalization just to reduce no of columns > > > In fact much of the point of > > http://blog.languager.org/2012/10/layout-imperative-in-functional.html > > is just this: that as code becomes more and more data-ish, > > a more-lines-less-columns regime becomes correspondingly irksome. > > I draw the opposite conclusion. The more your code is > laid out like a table, the more important it is to be > able to see the whole width of it at once. > > Your Haskell lexer example looks all very nice in a > good wide browser window. But reduce it so you can only > see half of it at a time and then tell me how readable > it is. Horrible. So what are we (if at all) disagreeing on? -- https://mail.python.org/mailman/listinfo/python-list
Re: Guido sees the light: PEP 8 updated
Gregory Ewing : > Marko Rauhamaa wrote: >> Steven D'Aprano : >> >>>def Do_The_Thing(): >>>def internal_subpart_start(): ... >>>def internal_subpart_middle(): ... >>>def internal_subpart_end(): ... >>>... >> >> That really should be done more. C weaned us from the routine Pascal >> mechanism, but there's no reason not to exploit it again in Python. > > Two things Python has that Pascal didn't are modules and classes. They > take care of a lot of the grouping that you had to rely on nested > functions for in Pascal. I don't think Pascal did it for grouping or readability but for conceptual correctness. When I moved from Pascal to C, I felt the absence of local functions; it was a slight unease about abstraction leakage. > I do find myself nesting functions like that in Python, but only very > occasionally. Same for me. Essentially, I use local functions to register callbacks. Decades of C has done that to us. Marko -- https://mail.python.org/mailman/listinfo/python-list
Re: Guido sees the light: PEP 8 updated
Rustom Mody wrote: Come to think of it take an SQL DBMS browser. Should we say: Horizontal scrolls are BAD; just reformat the table after reaching 80 columns? I would say, yes, horizontal scrolling *is* bad in a table -- probably even worse than it is for text or code. The reason is that tables are usually laid out so that data items in a row are related to each other. You can't make sense of a piece of data in the table without seeing the other items in the same row. That's hard to do if you can't see the whole row at once. In fact much of the point of http://blog.languager.org/2012/10/layout-imperative-in-functional.html is just this: that as code becomes more and more data-ish, a more-lines-less-columns regime becomes correspondingly irksome. I draw the opposite conclusion. The more your code is laid out like a table, the more important it is to be able to see the whole width of it at once. Your Haskell lexer example looks all very nice in a good wide browser window. But reduce it so you can only see half of it at a time and then tell me how readable it is. -- Greg -- https://mail.python.org/mailman/listinfo/python-list
Re: Guido sees the light: PEP 8 updated
Marko Rauhamaa wrote: Steven D'Aprano : def Do_The_Thing(): def internal_subpart_start(): ... def internal_subpart_middle(): ... def internal_subpart_end(): ... ... That really should be done more. C weaned us from the routine Pascal mechanism, but there's no reason not to exploit it again in Python. Two things Python has that Pascal didn't are modules and classes. They take care of a lot of the grouping that you had to rely on nested functions for in Pascal. I do find myself nesting functions like that in Python, but only very occasionally. -- Greg -- https://mail.python.org/mailman/listinfo/python-list
Re: Guido sees the light: PEP 8 updated
Steven D'Aprano : > One technique which is common in Pascal, but less so in Python, is to get > the best of both worlds by using nested functions. In Python syntax: > > def Do_The_Thing(): > def internal_subpart_start(): ... > def internal_subpart_middle(): ... > def internal_subpart_end(): ... > ... That really should be done more. C weaned us from the routine Pascal mechanism, but there's no reason not to exploit it again in Python. It also solves the problem of lugging the local context between internal functions, especially now that Python possesses the "nonlocal" keyword. Marko -- https://mail.python.org/mailman/listinfo/python-list
Re: Guido sees the light: PEP 8 updated
On Sunday, April 17, 2016 at 3:34:56 PM UTC+5:30, BartC wrote: > On 17/04/2016 04:44, Rustom Mody wrote: > > On Saturday, April 16, 2016 at 10:22:10 PM UTC+5:30, Marko Rauhamaa wrote: > > >> It comes with the maxim that one function must be visible at once on the > >> screen. > > > > Thats a strange self-contradiction. I wrote this: > > http://blog.languager.org/2012/10/layout-imperative-in-functional.html > > to make the case against PEP8 style line length strictures. > > Which has the SAME code formatted in two styles: > > > > -- < 80 cols, 48 lines > > -- 115 cols 37 lines > > > > Clearly the 115 cols is MORE fittable in a page than the 80 cols > > [Though my argument for that is based on other structural/semantic > > principles] > > Um, that's a different language, or does PEP8 apply to Haskell too? > > Haskell has a style that likes to be written horizontally (rather than > have statements one after another - /on separate lines/ - as in > imperative code). > > I also have trouble regarding that code as a single function, as it > implements (AFAICS) an entire lexer. It resembles data more than > anything else, and data presumably is allowed to be scrolled. Thats a nice point ... and often neglected by even the aficionados of functional programming. See Data Orientation http://blog.languager.org/2012/10/functional-programming-lost-booty.html [yeah funny that I am tell you this given your recent famous thread on lexing!] Come to think of it take an SQL DBMS browser. Should we say: Horizontal scrolls are BAD; just reformat the table after reaching 80 columns? In fact much of the point of http://blog.languager.org/2012/10/layout-imperative-in-functional.html is just this: that as code becomes more and more data-ish, a more-lines-less-columns regime becomes correspondingly irksome. > Otherwise things would be very restrictive! Dont understand that comment -- https://mail.python.org/mailman/listinfo/python-list
Re: Guido sees the light: PEP 8 updated
On Monday, April 18, 2016 at 8:49:33 AM UTC+5:30, Steven D'Aprano wrote: > On Mon, 18 Apr 2016 11:39 am, Rustom Mody wrote: > > > yes we can agree on this -- arbitrary line lengths are almost certainly > > unreadable. > > The problem then becomes so what is optimal? > > I really don't think it is a problem. We have about 400 years > of experience with printed text, and that experience tells us > that the optimal width for reading prose in Western languages > is about 60 characters, give or take. This width is optimal > for eye movement, and minimizes the number of errors and > reduces eye-strain. No disagreement so far > > There's only so far that our eyes can follow a line to the > right without increasing stress or reading errors, and > likewise when returning back to the left margin. The longer > the line, the higher the chance of losing track, and the > physical effort it takes to read. (You have to move the eyes > further, and for extremely long lines, you may have to move > your entire head.) > > Long lines are simply harder to read because you have to > move your eyes more, and the longer the lines, the greater > the tendency to wander across the lines. Especially if the > lines are close together and the height of the lines is > small. (It boggles my mind how many programmers I've met who > routinely view their code in tiny physical heights, even > when reading it in fine detail.) > > The optimal width for eye-tracking (that is, the maximum > width for which the rate of such errors can be disregarded) > is somewhere about sixty characters per line. Maybe even this is ok > > The same eye-tracking considerations apply to code This is nonsense. The last attempt of making code text-ish was Cobol -- by most accounts an unhappy experience. What is more code needs to be read very intensively for comprehension "x... what is x where is it defined? (scan backwards) ah there? Uh no further back... No global..." My own estimate of increased back-n-forth scanning of code vs plain text is probably an order of magnitude ie close to 10 times Even if I grant that you are twice as good a programmer as I am it will become 5 times. You would have to be 10 times better than me to equalize to (my) plaintext rate But if you are that kind of genius you probably speed-read plain text as well. tl;dr 1. Different languages -- natural and computer -- have different optimal line lengths. 2. There is very scant data on that. 3. PEP8 style strictures only delay discovery and collection of such data -- https://mail.python.org/mailman/listinfo/python-list
Re: Guido sees the light: PEP 8 updated
On Mon, 18 Apr 2016 11:39 am, Rustom Mody wrote: > yes we can agree on this -- arbitrary line lengths are almost certainly > unreadable. > The problem then becomes so what is optimal? I really don't think it is a problem. We have about 400 years of experience with printed text, and that experience tells us that the optimal width for reading prose in Western languages is about 60 characters, give or take. This width is optimal for eye movement, and minimizes the number of errors and reduces eye-strain. There's only so far that our eyes can follow a line to the right without increasing stress or reading errors, and likewise when returning back to the left margin. The longer the line, the higher the chance of losing track, and the physical effort it takes to read. (You have to move the eyes further, and for extremely long lines, you may have to move your entire head.) Long lines are simply harder to read because you have to move your eyes more, and the longer the lines, the greater the tendency to wander across the lines. Especially if the lines are close together and the height of the lines is small. (It boggles my mind how many programmers I've met who routinely view their code in tiny physical heights, even when reading it in fine detail.) The optimal width for eye-tracking (that is, the maximum width for which the rate of such errors can be disregarded) is somewhere about sixty characters per line. The same eye-tracking considerations apply to code, but: when it comes to code, we don't always have to track all the way back to the left-hand margin. If we start (say) up to twenty columns in, then we can afford to write up to twenty columns further to the right too. (Also, code tends to have VERY ragged right-hand margins. Not all lines end up even close to sixty characters wide.) There are other considerations though. Unlike prose, with code, shorter lines *may* sometimes force an increase in complexity. For instance, temporary variables need to be created, or new functions created, just to avoid otherwise excessively long lines. So one might be willing to accept a little more eye-movement for a little less code complexity. So allowing a total width of 80 (give or take) is already a compromise from the optimal sixty characters. This compromise allows for indented code, and allows up to 20 characters extra to avoid creating more complexity elsewhere. But there's another factor: long lines of code are themselves a code-smell. Perhaps: - you have indented too deeply, suggesting that your function is doing too much or has too much internal complexity: def func(): if a: for b in seq: while c: with d: try: try: for e in it: block # only 48 columns available here (But note also that even with this extreme example, eight indentation levels deep, you can still fit almost characters per line without breaking the 80-char limit. You can do a lot in 50 characters.) - you have too many expressions on one line, suggesting that the over-all complexity of the line is excessive; - your variable or function names are needlessly verbose or are doing too much or are too specific ("calculate_number_of_pages_and_number_of_semicolons_in_chapter_one"); - or you are violating the rule of Demeter: get(customer.trousers.pocket.wallet).open().money.pay(1) In other words, long lines of code are themselves an indication of poorly-designed code. Even though there are exceptions, we should resist strongly the urge to extend beyond the 60-80 (or perhaps 90 in extreme cases) limit. Whenever I hear people saying that they regularly need to use 100 or even 120 columns for their code, what I hear is "my code is badly written". -- Steven -- https://mail.python.org/mailman/listinfo/python-list
Re: Guido sees the light: PEP 8 updated
On Sun, 17 Apr 2016 09:01 pm, Marko Rauhamaa wrote: > In fact, if you find yourself introducing coding "paragraphs" with > comments: > > def f(...): > # I'll start by doing this > ... > # segueing into the middle portion > ... > # and finish it off as follows > ... > > you had better break those paragraphs off into separate functions. Just > turn your comments into function names. I'm reminded of the book "Refactoring - Ruby Edition" by Jay Fields, Shane Harvie and Martin Fowler (which I strongly recommend, for what it's worth). It is full of sections like: Change Value to Reference Change Reference to Value Decompose Conditional Recompose Conditional and most relevant to this discussion: Extract Method Inline Method (For "Method", substitute "Function".) The intro to Extract Method says: "You have a code fragment that can be grouped together." and then the author explains that he looks for methods which are too long, or code that needs a comment to explain what it does, and turns that fragment of code into its own method. But then the same author goes on to introduce Inline Method: "A method's body is just as clear as its name." and explains "sometimes you do come across a method in which the body is as clear as the name. ... When this happens, you should then get rid of the method. Indirection can be helpful, but needless indirection is irritating." Indeed. Once your code is the most straight-forward and simple implementation of the needed algorithm, it is hard to reduce complexity any further. All you can do is move the complexity around. You can hide the complexity inside the function, where it exposes itself only to those who need to dig into the body of the function to understand what it does. Or you can extract the code into functions of their own, which decreases the internal complexity of the function, but increases the complexity of the application or module. Extract Method hides complexity of the function by moving it into the module: def Do_The_Thing(): ... def internal_subpart_start(): ... def internal_subpart_middle(): ... def internal_subpart_end(): ... Inline Method reduces module complexity by moving it into the function: def Do_The_Thing(): ... # internal subpart start ... # internal subpart middle ... # internal subpart end But the total complexity remains the same. One technique which is common in Pascal, but less so in Python, is to get the best of both worlds by using nested functions. In Python syntax: def Do_The_Thing(): def internal_subpart_start(): ... def internal_subpart_middle(): ... def internal_subpart_end(): ... ... This hides complexity of the function by moving it into the nested functions, where they can be ignored, but without increasing the complexity of the module. (Of course, the *total* complexity of module, function and nested functions is the same.) -- Steven -- https://mail.python.org/mailman/listinfo/python-list
Re: Guido sees the light: PEP 8 updated
On Sunday, April 17, 2016 at 9:19:48 AM UTC+5:30, Chris Angelico wrote: > On Sun, Apr 17, 2016 at 1:44 PM, Rustom Mody wrote: > > Thats a strange self-contradiction. I wrote this: > > http://blog.languager.org/2012/10/layout-imperative-in-functional.html > > to make the case against PEP8 style line length strictures. > > Which has the SAME code formatted in two styles: > > > > -- < 80 cols, 48 lines > > -- 115 cols 37 lines > > > > Clearly the 115 cols is MORE fittable in a page than the 80 cols > > [Though my argument for that is based on other structural/semantic > > principles] > > There are certain specific situations where 80 (79) is the correct > width to aim for, but even if you aren't going for that, there's still > the general principle that longer lines are harder to read. So maybe > you declare that your codebase is allowed to go to 100, or 120, but > you don't want to let it run to 2048. No matter WHAT screen you're on, > that's too wide! yes we can agree on this -- arbitrary line lengths are almost certainly unreadable. The problem then becomes so what is optimal? Interesting question... and one that certainly has no bearing on the characteristics. of 30 year old technology. Remember that the most important characteristics of code are almost always un-legislatable eg choose 'nice' names. -- https://mail.python.org/mailman/listinfo/python-list
Re: Guido sees the light: PEP 8 updated
On Sun, Apr 17, 2016, at 19:56, Gregory Ewing wrote: > And then legacy command-line exes will be supported by running > cmd.exe under WINE in the Linux subsystem. Running the command directly under WINE, more like. Because cmd.exe is pretty terrible as a scripting language and command interpreter (MS knows this, this is why they created PowerShell), and isn't required to run console programs. -- https://mail.python.org/mailman/listinfo/python-list
Re: Guido sees the light: PEP 8 updated
Michael Torrie wrote: On 04/17/2016 10:13 AM, Dennis Lee Bieber wrote: On Sat, 16 Apr 2016 21:59:01 -0400, Random832 declaimed the following: I heard Windows 10 is going to finally fix this, anyway. Probably by removing the old CLI window completely and making everyone learn PowerShell ISE Or a Linux ELF bash binary running on the new Linux subsystem for Windows. :) And then legacy command-line exes will be supported by running cmd.exe under WINE in the Linux subsystem. -- Greg -- https://mail.python.org/mailman/listinfo/python-list
Re: Guido sees the light: PEP 8 updated
Marko Rauhamaa writes: > Chris Angelico : > > > What more often happens is that, once the function exceeds the > > stipulated maximum, it gets split somewhat arbitrarily into a > > "master" function and several "part" functions, with each part > > having exactly one call site in the driver and exactly none > > elsewhere. Even if the partial functions have reasonable names > > (which they don't always), they're still tightly bound to the > > master, and end up still functioning as a single unit. > > And? That's a feature, not a bug. It makes you analyze your approach a > bit more. It makes you give names to things. It makes it more likely > that your solution really works. Yes. It also counters the tendency to let distant areas of code in a function become too tightly dependent. By identifying large functions with inherent “do this then do that then do the other then …” structure as a problem in itself, the writer must split it into small functions and think *explicitly* about how those parts interact. The interface between those parts is already part of the code design, and if they're tightly coupled in a way difficult to describe simply, it is a *bad* design already. A large function just obscures that, it doesn't make it better. Encouraging the split of large functions into small ones makes that design explicit, and exposes places wehre the coupling is too complex or too tight. The code writer is then explicitly and routinely thinking about how best to narrow the coupling between the parts. > > Unless you can genuinely make that subfunction useful in some other > > context, there's not a lot of use splitting it into a function. You > > don't generally see those perfect "paragraphs" in real-world code. The point of splitting functions is not re-use (though that is a useful side effect when it happens). The point is, in the face of trends that are all toward code becoming difficult to understand and tangled, to make the design as clear and simple and obviously correct as feasible. -- \ “Welchen Teil von ‘Gestalt’ verstehen Sie nicht? [What part of | `\‘gestalt’ don't you understand?]” —Karsten M. Self | _o__) | Ben Finney -- https://mail.python.org/mailman/listinfo/python-list
Re: Guido sees the light: PEP 8 updated
On 04/17/2016 10:13 AM, Dennis Lee Bieber wrote: > On Sat, 16 Apr 2016 21:59:01 -0400, Random832 > declaimed the following: > >> >> I heard Windows 10 is going to finally fix this, anyway. > > Probably by removing the old CLI window completely and making everyone > learn PowerShell ISE Or a Linux ELF bash binary running on the new Linux subsystem for Windows. :) -- https://mail.python.org/mailman/listinfo/python-list
Re: Guido sees the light: PEP 8 updated
On Sun, Apr 17, 2016 at 11:13 AM, Dennis Lee Bieber wrote: > On Sat, 16 Apr 2016 21:59:01 -0400, Random832 > declaimed the following: >> >>I heard Windows 10 is going to finally fix this, anyway. > > Probably by removing the old CLI window completely and making everyone > learn PowerShell ISE PowerShell ISE doesn't support interactive console applications. It runs console apps with a hidden console (conhost.exe) and sets the StandardOutput and StandardError to pipes. It leaves StandardInput set to the console input handle. If you run python.exe in this environment, you can use ctypes to show the console. Then enter commands in the console, and get the output in ISE. Or rebind sys.stdout and sys.stderr to \\.\CONOUT$ handles and forget about ISE, which is really only meant for developing PowerShell scripts. Microsoft won't abandon existing console programs, such as python.exe. The console system was fairly stagnant between NT 4 and Vista. In Windows 7, they changed how it interacts with a Windows session, by moving the server out of csrss.exe to multiple conhost.exe instances. In Windows 8, they reimplemented the API to use a kernel device driver, condrv.sys. For Windows 10, they've focused on improving the user interface: https://blogs.windows.com/buildingapps/2014/10/07/ console-improvements-in-the-windows-10-technical-preview There's a new blog dedicated to Windows command-line tools, which should be the place to look for announcements about the console subsystem and the new Linux command-line environment that depends on the console: https://blogs.msdn.microsoft.com/commandline -- https://mail.python.org/mailman/listinfo/python-list
Re: Guido sees the light: PEP 8 updated
On 2016-04-17 16:35, Coos Haak wrote: > Op Sat, 16 Apr 2016 20:30:52 -0500 schreef Tim Chase: > >> Try `mode con cols=120 lines=30`. > > > > Yeah, that will do it, as will going into the settings and > > changing it. But basically every other program on Windows, and > > every console on Linux/BSD/Mac will let me resize a terminal > > running while another program is running. For a cmd.exe window, > > I have to quit, issue the `mode` command, restart my application, > > and return to where I was. > > No need to close. Right-click on statusbar and set properties. By "close", I meant "close the application running within the cmd.exe window" rather than "close the cmd.exe window". In most *nix programs, they understand the SIGWINCH (window-size changed) signal and respond accordingly. In the Win32 world, it was pretty fixed in size, so most terminal programs don't readily accommodate changed size while they're running. So as Eryk Sun mentions, the program has to jump through hoops to run "mode" in a subprocess to change the terminal size, or use GetConsoleScreenBufferInfoEx/SetConsoleScreenBufferInfoEx or other such mechanisms. It's not that it *can't* be done, it's just done in an *inconvenient* way (if done at all). -tkc -- https://mail.python.org/mailman/listinfo/python-list
Re: Guido sees the light: PEP 8 updated
Op Sat, 16 Apr 2016 20:30:52 -0500 schreef Tim Chase: > On 2016-04-16 19:39, eryk sun wrote: >> On Sat, Apr 16, 2016 at 4:50 PM, Tim Chase wrote: >>> I also do some editing/diffing within a cmd.exe window on Windows >>> which is limited to 80 characters unless you do some hijinks in >>> the settings to expand it. >> >> Try `mode con cols=120 lines=30`. > > Yeah, that will do it, as will going into the settings and changing > it. But basically every other program on Windows, and every console > on Linux/BSD/Mac will let me resize a terminal running while another > program is running. For a cmd.exe window, I have to quit, issue the > `mode` command, restart my application, and return to where I was. > > -tkc No need to close. Right-click on statusbar and set properties. groet Coos -- https://mail.python.org/mailman/listinfo/python-list
Re: Guido sees the light: PEP 8 updated
On Sat, Apr 16, 2016 at 4:30 PM, Marko Rauhamaa wrote: > > Java generics ruined a perfectly good language. I mean: > > Map> customersOfAccountManager = > new HashMap>(); > > where classic Java would have: > > Map customersOfAccountManager = new HashMap(); The diamond operator in JDK 7 makes this a lot more tolerable, IMO: Map> customersOfAccountManager = new HashMap<>(); -- https://mail.python.org/mailman/listinfo/python-list
Re: Guido sees the light: PEP 8 updated
Chris Angelico : > On Sun, Apr 17, 2016 at 9:01 PM, Marko Rauhamaa wrote: >> In fact, if you find yourself introducing coding "paragraphs" with >> comments: >> >> def f(...): >> # I'll start by doing this >> ... >> # segueing into the middle portion >> ... >> # and finish it off as follows >> ... >> >> you had better break those paragraphs off into separate functions. Just >> turn your comments into function names. > > It's really easy to do this in toy examples, isn't it? But the real > world is not so wonderful, as Alice's nanny said. I do this in the real world, professionally. Been doing it for decades, and it hasn't failed me so far. Exceptions exist, but they are that: rare exceptions. > What more often happens is that, once the function exceeds the > stipulated maximum, it gets split somewhat arbitrarily into a "master" > function and several "part" functions, with each part having exactly > one call site in the driver and exactly none elsewhere. Even if the > partial functions have reasonable names (which they don't always), > they're still tightly bound to the master, and end up still > functioning as a single unit. And? That's a feature, not a bug. It makes you analyze your approach a bit more. It makes you give names to things. It makes it more likely that your solution really works. And the main thing: whoever needs to come and maintain your code will have an easier time understanding what your code is trying to accomplish. > Unless you can genuinely make that subfunction useful in some other > context, there's not a lot of use splitting it into a function. You > don't generally see those perfect "paragraphs" in real-world code. No, that's Software Engineering 101: you split your solution into subroutines regardless of whether those subroutines are needed in multiple places. (The main practical problem with the divide-and-conquer approach is the fact that you need to drag the context around. Sometimes you have to keep piling on function arguments, which spoil the visual advantages you are trying to gain by partitioning your solution. One obvious solution to the argument clutter is to carry the context in *the* object or *a* special-purpose context object.) The compactness requirement for the code discourages empty lines and commenting. If find that, too, a feature rather than a bug. The code should in general speak for itself. Well-chosen names and a compact, elegant structure communicate the intent of the code better than plain-English comments that will not stay current with the code anyway. Marko -- https://mail.python.org/mailman/listinfo/python-list
Re: Guido sees the light: PEP 8 updated
On 17/04/2016 12:14, Chris Angelico wrote: On Sun, Apr 17, 2016 at 9:01 PM, Marko Rauhamaa wrote: In fact, if you find yourself introducing coding "paragraphs" with comments: def f(...): # I'll start by doing this ... # segueing into the middle portion ... # and finish it off as follows ... you had better break those paragraphs off into separate functions. Just turn your comments into function names. It's really easy to do this in toy examples, isn't it? But the real world is not so wonderful, as Alice's nanny said. What more often happens is that, once the function exceeds the stipulated maximum, it gets split somewhat arbitrarily into a "master" function and several "part" functions, with each part having exactly one call site in the driver and exactly none elsewhere. Even if the partial functions have reasonable names (which they don't always), they're still tightly bound to the master, and end up still functioning as a single unit. Unless you can genuinely make that subfunction useful in some other context, there's not a lot of use splitting it into a function. You don't generally see those perfect "paragraphs" in real-world code. With the additional problems that the sub-functions need a way of accessing the local and declared names of the 'master' function. That means creating an interface (possibly a custom one for each sub-function) so that the master's local variables can be shared. Except that a sub-function can't directly write to the local variables that would be simply shared in the original monolithic function. Besides, for a set of sub-functions that are only used by a master function F, they really belong as local functions in F. That makes it even bigger and more complex, although access to F's locals is simplified. -- bartc -- https://mail.python.org/mailman/listinfo/python-list
Re: Guido sees the light: PEP 8 updated
On Sun, Apr 17, 2016 at 9:01 PM, Marko Rauhamaa wrote: > In fact, if you find yourself introducing coding "paragraphs" with > comments: > > def f(...): > # I'll start by doing this > ... > # segueing into the middle portion > ... > # and finish it off as follows > ... > > you had better break those paragraphs off into separate functions. Just > turn your comments into function names. It's really easy to do this in toy examples, isn't it? But the real world is not so wonderful, as Alice's nanny said. What more often happens is that, once the function exceeds the stipulated maximum, it gets split somewhat arbitrarily into a "master" function and several "part" functions, with each part having exactly one call site in the driver and exactly none elsewhere. Even if the partial functions have reasonable names (which they don't always), they're still tightly bound to the master, and end up still functioning as a single unit. Unless you can genuinely make that subfunction useful in some other context, there's not a lot of use splitting it into a function. You don't generally see those perfect "paragraphs" in real-world code. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: Guido sees the light: PEP 8 updated
Rustom Mody : > On Saturday, April 16, 2016 at 10:22:10 PM UTC+5:30, Marko Rauhamaa wrote: >> A max line length of 79 characters is among the *only* rigorous >> principles I judge coding style on. >> >> It comes with the maxim that one function must be visible at once on the >> screen. > > Thats a strange self-contradiction. Why? You are allowed to break a function into subfunctions, you know. In fact, if you find yourself introducing coding "paragraphs" with comments: def f(...): # I'll start by doing this ... # segueing into the middle portion ... # and finish it off as follows ... you had better break those paragraphs off into separate functions. Just turn your comments into function names. Marko -- https://mail.python.org/mailman/listinfo/python-list
Re: Guido sees the light: PEP 8 updated
On 17/04/2016 04:44, Rustom Mody wrote: On Saturday, April 16, 2016 at 10:22:10 PM UTC+5:30, Marko Rauhamaa wrote: It comes with the maxim that one function must be visible at once on the screen. Thats a strange self-contradiction. I wrote this: http://blog.languager.org/2012/10/layout-imperative-in-functional.html to make the case against PEP8 style line length strictures. Which has the SAME code formatted in two styles: -- < 80 cols, 48 lines -- 115 cols 37 lines Clearly the 115 cols is MORE fittable in a page than the 80 cols [Though my argument for that is based on other structural/semantic principles] Um, that's a different language, or does PEP8 apply to Haskell too? Haskell has a style that likes to be written horizontally (rather than have statements one after another - /on separate lines/ - as in imperative code). I also have trouble regarding that code as a single function, as it implements (AFAICS) an entire lexer. It resembles data more than anything else, and data presumably is allowed to be scrolled. Otherwise things would be very restrictive! -- Bartc -- https://mail.python.org/mailman/listinfo/python-list
Re: Guido sees the light: PEP 8 updated
On Sun, Apr 17, 2016 at 12:10 AM, Random832 wrote: > > On Sun, Apr 17, 2016, at 01:01, eryk sun wrote: >> It doesn't support fonts that mix half-width and full-width glyphs. > > This is the most baffling bit to me. I mean, it _has_ to, for Chinese, > Japanese, and Korean users. This support obviously exists in the code. > Why not extend it to everyone, instead of maintaining two versions of > whatever it's doing? Right, the console implements this for CJK locales, in which case it uses 2 columns for a full-width character. But based on the public symbols, I'd guess that the implementation is tied to using a DBCS codepage: 0:004> x /1 /n conhostv2!*dbcs* ConhostV2!DBCS_SCREEN_BUFFER::CreateInstance ConhostV2!DBCS_SCREEN_BUFFER::`scalar deleting destructor' ConhostV2!DBCS_SCREEN_BUFFER::~DBCS_SCREEN_BUFFER ConhostV2!InitializeDbcsMisc ConhostV2!IsDBCSLeadByteConsole ConhostV2!ReCreateDbcsScreenBuffer ConhostV2!ReCreateDbcsScreenBufferWorker ConhostV2!RemoveDbcsMark ConhostV2!RemoveDbcsMarkAll ConhostV2!RemoveDbcsMarkCell ConhostV2!g_fIsDBCSACP Implementing this in a Western locale would need an implementation based on Unicode character properties. -- https://mail.python.org/mailman/listinfo/python-list
Re: Guido sees the light: PEP 8 updated
On Sun, Apr 17, 2016, at 01:01, eryk sun wrote: > It doesn't support fonts that mix half-width and full-width glyphs. This is the most baffling bit to me. I mean, it _has_ to, for Chinese, Japanese, and Korean users. This support obviously exists in the code. Why not extend it to everyone, instead of maintaining two versions of whatever it's doing? -- https://mail.python.org/mailman/listinfo/python-list
Re: Guido sees the light: PEP 8 updated
On Sat, Apr 16, 2016 at 8:30 PM, Tim Chase wrote: > On 2016-04-16 19:39, eryk sun wrote: >> On Sat, Apr 16, 2016 at 4:50 PM, Tim Chase wrote: >> > I also do some editing/diffing within a cmd.exe window on Windows >> > which is limited to 80 characters unless you do some hijinks in >> > the settings to expand it. >> >> Try `mode con cols=120 lines=30`. > > Yeah, that will do it, as will going into the settings and changing > it. But basically every other program on Windows, and every console > on Linux/BSD/Mac will let me resize a terminal running while another > program is running. For a cmd.exe window, I have to quit, issue the > `mode` command, restart my application, and return to where I was. cmd.exe doesn't own a window. You probably meant the console host/server, conhost.exe. cmd has handles for StandardInput, StandardOutput, and StandardError -- which may be handles for console I/O, but not necessarily. I agree that the classic console window has a bad UI. It can only be resized up to the size of the screen buffer, which is not terribly useful. There's no way to change the screen buffer size when manually sizing the window. You have to either use the properties dialog or the API. In Python you can run mode.com via subprocess.call('mode.com con cols=120'). Or you can use ctypes to call GetConsoleScreenBufferInfoEx and SetConsoleScreenBufferInfoEx. The Windows 10 console is a significant step in the right direction. It automatically resizes the screen buffer with text wrapping, selects a text stream instead of a rectangle, and uses regular keyboard shortcuts such as Ctrl+C and Ctrl+V for copy and paste. It still has room for improvement, however. It doesn't support fonts that mix half-width and full-width glyphs. It can't display characters that use multiple WCHAR values, such as astral characters (UTF-16 surrogate pairs) and decomposed characters. It doesn't support ANSI/VT100 terminal emulation (but maybe this is in the works for the new Linux subsystem). -- https://mail.python.org/mailman/listinfo/python-list
Re: Guido sees the light: PEP 8 updated
On Sun, Apr 17, 2016 at 1:44 PM, Rustom Mody wrote: > Thats a strange self-contradiction. I wrote this: > http://blog.languager.org/2012/10/layout-imperative-in-functional.html > to make the case against PEP8 style line length strictures. > Which has the SAME code formatted in two styles: > > -- < 80 cols, 48 lines > -- 115 cols 37 lines > > Clearly the 115 cols is MORE fittable in a page than the 80 cols > [Though my argument for that is based on other structural/semantic principles] There are certain specific situations where 80 (79) is the correct width to aim for, but even if you aren't going for that, there's still the general principle that longer lines are harder to read. So maybe you declare that your codebase is allowed to go to 100, or 120, but you don't want to let it run to 2048. No matter WHAT screen you're on, that's too wide! ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: Guido sees the light: PEP 8 updated
On Saturday, April 16, 2016 at 10:22:10 PM UTC+5:30, Marko Rauhamaa wrote: > Larry Martell : > > > I have worked for many companies where you are required to get a clean > > run of pep8 on your code before your pull request will even be > > considered for approval. I don't agree with this at all, as I think it > > makes the code very ugly, especially enforcing the max line length. > > Agh, I was with you until your last remark. Count me in the "80-chars is ante-deluvian gunk" camp > > A max line length of 79 characters is among the *only* rigorous > principles I judge coding style on. > > It comes with the maxim that one function must be visible at once on the > screen. Thats a strange self-contradiction. I wrote this: http://blog.languager.org/2012/10/layout-imperative-in-functional.html to make the case against PEP8 style line length strictures. Which has the SAME code formatted in two styles: -- < 80 cols, 48 lines -- 115 cols 37 lines Clearly the 115 cols is MORE fittable in a page than the 80 cols [Though my argument for that is based on other structural/semantic principles] Should mention an irony here though: When I first wrote it, the examples were inline and blogger was breaking the lines randomly completely invalidating my point. IIRC blogger was breaking at 68 cols -- invalidating the 80 cols from the other side. Clearly 80 cols is more portable than longer. However if we literally implement the view that different people use different technologies -- AND WE SHOULD SUPPORT THEM ALL -- then notepad becomes the ineluctable gold standard. -- https://mail.python.org/mailman/listinfo/python-list
Re: Guido sees the light: PEP 8 updated
On Sat, Apr 16, 2016, at 21:30, Tim Chase wrote: > On 2016-04-16 19:39, eryk sun wrote: > > On Sat, Apr 16, 2016 at 4:50 PM, Tim Chase wrote: > > > I also do some editing/diffing within a cmd.exe window on Windows > > > which is limited to 80 characters unless you do some hijinks in > > > the settings to expand it. > > > > Try `mode con cols=120 lines=30`. > > Yeah, that will do it, as will going into the settings and changing > it. But basically every other program on Windows, and every console > on Linux/BSD/Mac will let me resize a terminal running while another > program is running. For a cmd.exe window, I have to quit, issue the > `mode` command, restart my application, and return to where I was. Well, if your interactive application allows you to run commands within it, you don't have to quit. Plus you can always go into the settings window, I don't know what's "hijinks" about that. I heard Windows 10 is going to finally fix this, anyway. -- https://mail.python.org/mailman/listinfo/python-list
Re: Guido sees the light: PEP 8 updated
On 2016-04-16 19:39, eryk sun wrote: > On Sat, Apr 16, 2016 at 4:50 PM, Tim Chase wrote: > > I also do some editing/diffing within a cmd.exe window on Windows > > which is limited to 80 characters unless you do some hijinks in > > the settings to expand it. > > Try `mode con cols=120 lines=30`. Yeah, that will do it, as will going into the settings and changing it. But basically every other program on Windows, and every console on Linux/BSD/Mac will let me resize a terminal running while another program is running. For a cmd.exe window, I have to quit, issue the `mode` command, restart my application, and return to where I was. -tkc -- https://mail.python.org/mailman/listinfo/python-list
Re: Guido sees the light: PEP 8 updated
Chris Angelico writes: > On Sun, Apr 17, 2016 at 9:25 AM, Ben Bacarisse wrote: >> Dennis Lee Bieber writes: >> >>> I still miss the Amiga -- in which one could /push/ a window to the >>> back of the stack while still retaining input focus! Made it nice for >>> transcribing stuff from a visible window to a text input region while it >>> was obscured. >> >> That was commonly available on Unix window managers and is still around. >> I use it on even an up-to-date Linux/Gnome3 system (you set focus >> follows mouse rather than focus on click). > > Focus follows mouse is annoying for other reasons though. Sure. But if you want it only sometimes you can bind a key to turn it on or off so you can have it only momentarily. The other way is to bind a key (if not already bound) to the "lower winder" action. That won't (or shouldn't) alter the focus and will push the window under the one you want to see. -- Ben. -- https://mail.python.org/mailman/listinfo/python-list
Re: Guido sees the light: PEP 8 updated
On 2016-04-17 00:11, Chris Angelico wrote: On Sun, Apr 17, 2016 at 9:02 AM, Dennis Lee Bieber wrote: I still miss the Amiga -- in which one could /push/ a window to the back of the stack while still retaining input focus! Made it nice for transcribing stuff from a visible window to a text input region while it was obscured. OS/2 could do the same thing. I've tried to mess with it in various Linux desktops, but haven't really found what I want. You could also do that on Acorn's RISC OS. -- https://mail.python.org/mailman/listinfo/python-list
Re: Guido sees the light: PEP 8 updated
On 2016-04-16 19:02, Dennis Lee Bieber wrote: > I still miss the Amiga -- in which one could /push/ a > window to the back of the stack while still retaining input focus! > Made it nice for transcribing stuff from a visible window to a text > input region while it was obscured. What OS (or if X-based, which window-manager) do you use? I have Mod4 Next :LowerLayer Mod4 Prior :RaiseLayer in my ~/.fluxbox/keys configuration which lets me use the logo key with pageup/pagedown to raise/lower the focus of the current window. I find that most of the time I want to raise one particular window above all other windows (most of the time I end up closing it when done, but sometimes I want to lower it back down to the main application layer). -tkc -- https://mail.python.org/mailman/listinfo/python-list
Re: Guido sees the light: PEP 8 updated
The 80 column limit probably helps protect us from the singularity. Once the robots take over we will have code with a digestible amount of logic per line and can fix what we have caused. In other words, Java is only armoring the robots against us for the inevitable battle. On Sat, Apr 16, 2016 at 7:33 PM, Chris Angelico wrote: > On Sun, Apr 17, 2016 at 9:25 AM, Ben Bacarisse > wrote: > > Dennis Lee Bieber writes: > > > >> I still miss the Amiga -- in which one could /push/ a window to > the > >> back of the stack while still retaining input focus! Made it nice for > >> transcribing stuff from a visible window to a text input region while it > >> was obscured. > > > > That was commonly available on Unix window managers and is still around. > > I use it on even an up-to-date Linux/Gnome3 system (you set focus > > follows mouse rather than focus on click). > > Focus follows mouse is annoying for other reasons though. > > ChrisA > -- > https://mail.python.org/mailman/listinfo/python-list > -- "On two occasions I have been asked, 'Pray, Mr. Babbage, if you put into the machine wrong figures, will the right answers come out?' I am not able rightly to apprehend the kind of confusion of ideas that could provoke such a question." -Charles Babbage, 19th century English mathematician, philosopher, inventor and mechanical engineer who originated the concept of a programmable computer. -- https://mail.python.org/mailman/listinfo/python-list
Re: Guido sees the light: PEP 8 updated
On Sun, Apr 17, 2016 at 9:25 AM, Ben Bacarisse wrote: > Dennis Lee Bieber writes: > >> I still miss the Amiga -- in which one could /push/ a window to the >> back of the stack while still retaining input focus! Made it nice for >> transcribing stuff from a visible window to a text input region while it >> was obscured. > > That was commonly available on Unix window managers and is still around. > I use it on even an up-to-date Linux/Gnome3 system (you set focus > follows mouse rather than focus on click). Focus follows mouse is annoying for other reasons though. ChrisA -- https://mail.python.org/mailman/listinfo/python-list