Re: Guido sees the light: PEP 8 updated

[Oscar Benjamin]

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

[Oscar Benjamin]

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

[Gregory Ewing]

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

[Terry Reedy]

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

[Rustom Mody]

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

[Rustom Mody]

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

[Chris Angelico]

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

[Terry Reedy]

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

[Chris Angelico]

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

[Random832]

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

[Random832]

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

[Steven D'Aprano]

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

[Steven D'Aprano]

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

[Steven D'Aprano]

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

[Steven D'Aprano]

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

[Tim Chase]

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

[Chris Angelico]

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

[Grant Edwards]

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

[sohcahtoa82]

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

[Marko Rauhamaa]

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

[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?

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

[Ben Finney]

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

[Random832]

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

[Rustom Mody]

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

[Tim Chase]

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

[alister]

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

[Larry Martell]

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

[Rustom Mody]

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

[Steven D'Aprano]

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

[Steven D'Aprano]

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

[Steven D'Aprano]

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

[Tim Chase]

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

[Rustom Mody]

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

[Alice Bevan–McGregor]

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

[Chris Angelico]

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

[Rustom Mody]

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

[Grant Edwards]

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

[Chris Angelico]

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

[Random832]

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

[Tim Chase]

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

[Chris Angelico]

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

[Tim Chase]

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

[Antoon Pardon]

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

[Rustom Mody]

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

[Marko Rauhamaa]

Rustom Mody :

> In the same way and like colorforth, it would be better to distinguish
> 

Re: Guido sees the light: PEP 8 updated

[Rustom Mody]

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

Re: Guido sees the light: PEP 8 updated

[Marko Rauhamaa]

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

[Rustom Mody]

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

[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.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Guido sees the light: PEP 8 updated

[Chris Angelico]

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

[Marko Rauhamaa]

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

[Ben Finney]

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

[Pete Forman]

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

[Gregory Ewing]

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

[Random832]

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

[Rustom Mody]

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

[Random832]

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

[Rustom Mody]

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

[sohcahtoa82]

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

[Ben Finney]

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

[Pete Forman]

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

[Ian Kelly]

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

[Pete Forman]

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

[Sivan Greenberg]

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

[David Palao]

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: [OT] Java generics (was: Guido sees the light: PEP 8 updated)

[Tim Delaney]

On 18 April 2016 at 09:30, Chris Angelico  wrote:

> On Mon, Apr 18, 2016 at 8:02 AM, Tim Delaney
>  wrote:
> > I also wouldn't describe Java as a
> > "perfectly good language" - it is at best a compromise language that just
> > happened to be heavily promoted and accepted at the right time.
> >
> > Python is *much* closer to my idea of a perfectly good language.
>
> "Java" was originally four related, but separate, concepts: a source
> language, a bytecode, a sandboxing system, and one other that I can't
> now remember.


I was very specifically referring to Java the language. The JVM is fairly
nice, especially with the recent changes specifically aimed at more easily
supporting dynamic languages.

Speaking of JVM changes - I had to take over support of a chat applet
developed by a contractor built on Java 1.0. We just could not get it to
work reliably (this was for the original Foxtel web site - I remember
trying to keep it up and running while Richard Fidler was doing a promoted
chat session ...). Then Java 1.1 was released and what a huge improvement
that was.

Tim Delaney
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Guido sees the light: PEP 8 updated

[Rustom Mody]

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

[Marko Rauhamaa]

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

[Gregory Ewing]

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

[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 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

[Marko Rauhamaa]

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

[Rustom Mody]

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

[Rustom Mody]

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

[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

Re: Guido sees the light: PEP 8 updated

[Steven D'Aprano]

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

[Rustom Mody]

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: [OT] Java generics (was: Guido sees the light: PEP 8 updated)

[Chris Angelico]

On Mon, Apr 18, 2016 at 11:03 AM, Steven D'Aprano  wrote:
> On Mon, 18 Apr 2016 09:30 am, Chris Angelico wrote:
>
>> "Java" was originally four related, but separate, concepts: a source
>> language, a bytecode, a sandboxing system, and one other that I can't
>> now remember.
>
> The virtual machine? Or is that what you mean by bytecode?

Could be. I can't remember where it was that I read about the
four-part name overloading on "Java", but it doesn't much matter. The
VM and bytecode go together, and the sandboxing is the thing that
makes that better than just compiling to machine code.

> The Java Virtual Machine is probably the most successful part of Java, as it
> has spawned a whole lot of new languages that are built on the JVM,
> including Clojure, Groovy and Scala, as well as JVM implementations of
> Python, Ruby, Javascript, Perl6, TCL, Fortran, Oberon, Pascal and more.
>
> https://en.wikipedia.org/wiki/List_of_JVM_languages

Yes, but how long did it take before they came along? I didn't click
on all the links, but the five that Wikipedia lists as "High Profile"
are all post-2000. By that time, Flash had already established a
strong footing. NetRexx, in contrast, dates back to 1996, when the
battle was on. It could have been Java's game entirely if there'd been
enough interest in the early days.

> One of the more interesting approaches is of Fantom, a new language designed
> from the beginning to run on top of any of the JVM, the .Net CLR, or a
> Javascript VM.

I hadn't heard of that one specifically, but there have been some
extremely interesting forays into language layering. (PyPyJS, I'm
looking at you.) Code is code, compilers are compilers, you can
implement anything in anything. Although sometimes it's just for the
sake of showing off ("hey look, I just compiled Firefox to asm.js and
ran it inside Firefox!")... but that's fun too :)

ChrisA
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: [OT] Java generics (was: Guido sees the light: PEP 8 updated)

[Steven D'Aprano]

On Mon, 18 Apr 2016 09:30 am, Chris Angelico wrote:

> "Java" was originally four related, but separate, concepts: a source
> language, a bytecode, a sandboxing system, and one other that I can't
> now remember. 

The virtual machine? Or is that what you mean by bytecode?

The Java Virtual Machine is probably the most successful part of Java, as it
has spawned a whole lot of new languages that are built on the JVM,
including Clojure, Groovy and Scala, as well as JVM implementations of
Python, Ruby, Javascript, Perl6, TCL, Fortran, Oberon, Pascal and more.

https://en.wikipedia.org/wiki/List_of_JVM_languages

One of the more interesting approaches is of Fantom, a new language designed
from the beginning to run on top of any of the JVM, the .Net CLR, or a
Javascript VM.



-- 
Steven

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Guido sees the light: PEP 8 updated

[Random832]

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

[Gregory Ewing]

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: [OT] Java generics (was: Guido sees the light: PEP 8 updated)

[Chris Angelico]

On Mon, Apr 18, 2016 at 8:02 AM, Tim Delaney
 wrote:
> I also wouldn't describe Java as a
> "perfectly good language" - it is at best a compromise language that just
> happened to be heavily promoted and accepted at the right time.
>
> Python is *much* closer to my idea of a perfectly good language.

"Java" was originally four related, but separate, concepts: a source
language, a bytecode, a sandboxing system, and one other that I can't
now remember. The published bytecode was way ahead of its day, and
coupled with the sandbox, it made Java into the one obvious language
for web browser applets (until the rise of Flash, and then the
increase in power of JavaScript etc).

If the source language and bytecode+sandbox had been more
disconnected, and the latter more standardized, Java might have been a
hugely popular language because of one important role (web browser
applets) that can also be used elsewhere. Instead, it made a promise
of "write once, run everywhere" that didn't really hold up (the
Australian Taxation Office let you file corporate taxes either on
paper or using their Java application - and it didn't run on OS/2
Java) and lost a ton of potential marketshare. Imagine how the world
would be today, if languages like NetRexx had had a chance to shine -
completely different source code language, compiling to the same Java
bytecode.

Jython might have been the one most popular language for applet development...

ChrisA
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Guido sees the light: PEP 8 updated

[Ben Finney]

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

[OT] Java generics (was: Guido sees the light: PEP 8 updated)

[Tim Delaney]

On 17 April 2016 at 23:38, Ian Kelly  wrote:


> > Java generics ruined a perfectly good language. I mean:
>
> The diamond operator in JDK 7 makes this a lot more tolerable, IMO:
>
> Map customersOfAccountManager =
> new HashMap<>();
>

To some extent - you can't use the diamond operator when creating an
anonymous subclass, and you often need to explicitly specify the types for
generic methods. The inference engine is fairly limited.

I wouldn't say generics ruined Java - they made it better in some ways (for
a primarily statically-typed language) but worse in others (esp. that
they're implemented by erasure). I also wouldn't describe Java as a
"perfectly good language" - it is at best a compromise language that just
happened to be heavily promoted and accepted at the right time.

Python is *much* closer to my idea of a perfectly good language.

Tim Delaney
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Guido sees the light: PEP 8 updated

[Michael Torrie]

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

[eryk sun]

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: Falsehoods People Believe about PEP 8 (was: Guido sees the light: PEP 8 updated)

[Chris Angelico]

On Sun, Apr 17, 2016 at 6:21 AM, Ben Finney  wrote:
> Chris Angelico  writes:
>
>> Maybe we need a blog post "Falsehoods Programmers Believe About PEP
>> 8", along the lines of the ones about time and names.
>
> Great suggestion. (Do you have a blog on which you could post an article
> like this?)

An initial list has been posted here:

http://rosuav.blogspot.com/2016/04/falsehoods-programmers-believe-about.html

Additional contributions are still welcome.

ChrisA
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Guido sees the light: PEP 8 updated

[Tim Chase]

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

[Coos Haak]

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

[Ian Kelly]

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

[Marko Rauhamaa]

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

[BartC]

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

[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. 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

[Marko Rauhamaa]

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

[BartC]

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

[eryk sun]

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

[Random832]

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

[eryk sun]

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: Falsehoods People Believe about PEP 8 (was: Guido sees the light: PEP 8 updated)

[Dan Sommers]

On Sun, 17 Apr 2016 11:48:11 +1000, Steven D'Aprano wrote:

> On Sun, 17 Apr 2016 09:35 am, Dan Sommers wrote:
> 
>> We (this mailing list, or maybe it was the python-ideas mailing list)
>> just had a thread about non-ASCII characters in identifiers.  One of
>> the main argument against is the confusables (A vs Α vs А).
>> Sufficient tooling, however, could render (pun intended) that
>> argument moot.  Not too long ago, one of the main arguments against
>> was that not everyone's tools could even render Α or А.
> 
> Technically speaking, they still might not. My editor can render both
> Cyrillic and Greek characters, but does a terrible job at Chinese and
> Korean because I don't have the font support. So all I see is a series
> of "missing character" boxes. There may be folks who don't have
> installed fonts that support Cyrillic or Greek.

I think we're agreeing.  Not everyone's tools render the same source
code the same way, which means that at least some part of readability
depends on the tools people use.

People who use screen readers rather than visual displays probably
wonder why the rest of us can't tell our "l"s from our "1"s and our "O"s
from our "0"s.

If PEP8 is about readability, then it should dispell the myth that
everyone perceives source code the same way through the same tools.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Guido sees the light: PEP 8 updated

[Chris Angelico]

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

[Rustom Mody]

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