A desperate lunge for on-topic-ness

[Zero Piraeus]

:

Okay, so, first thing vaguely Python-related that comes to mind [so
probably not even slightly original, but then that's not really the
point]:

What are people's preferred strategies for dealing with lines that go
over 79 characters? A few I can think of off the bat:

1. Say "screw it" and go past 79, PEP8 be damned.

2. Say "screw it" and break the line using a backslash.

3. Say "well, at least it's not a backslash" and break the line using
parentheses.

4. Spend 45 minutes trying to think up shorter [but still sensible]
variable names to make it fit.

5. Perform an otherwise pointless assignment to a temp variable on the
previous line to make it fit.

6. Realise that if it's that long, it probably shouldn't have been a
list comprehension in the first place.

Any I've missed? Any preferences?

-[]z.

[Chris Angelico]

On Thu, Oct 18, 2012 at 5:06 PM, Zero Piraeus <sch...@gmail.com> wrote:
> What are people's preferred strategies for dealing with lines that go
> over 79 characters? A few I can think of off the bat:
>
> 1. Say "screw it" and go past 79, PEP8 be damned.
>

> 6. Realise that if it's that long, it probably shouldn't have been a
> list comprehension in the first place.

Depending on how far past, I'd be most inclined to one of these. I
don't consider the eightieth character position to be sacrosanct, but
on the other hand, I'm not going to go thousands of characters to the
right. Most of my development screens will happily go to ~200
characters, definitely above 100, so I tend to write a bit wider than
PEP 8 demands. Generally I'd not look at splitting a line until it
goes over 100-120 characters. (And even then, I won't automatically
split it. I've been known to write some rather long lines of code.)
When I do split, it's usually by dividing the line into multiple
logical actions; if the split looks like type #5, I'll not split it.

ChrisA

[Steven D'Aprano]

On Thu, 18 Oct 2012 02:06:19 -0400, Zero Piraeus wrote:

> What are people's preferred strategies for dealing with lines that go
> over 79 characters? A few I can think of off the bat:
>
> 1. Say "screw it" and go past 79, PEP8 be damned.

I've been burnt enough by word-wrapping in editors that don't handle word-
wrapping that well that it makes me really uncomfortable to go over 78-79
characters, even by only 1 extra. So I don't like doing this.

Just about the only time I go over is if I have a comment that includes a
URL with more than 78 characters. I hate breaking URLs more than I hate
breaking the 79 character limit.

> 2. Say "screw it" and break the line using a backslash.

Low on my preference list, but occasionally.

> 3. Say "well, at least it's not a backslash" and break the line using
> parentheses.

I mostly do this. Since most lines include a bracket of some sort, I
rarely need to add outer parentheses just for the purpose of line
continuation.

some_variable = spam('x') + ham(
some_longer_variables, here_and_here,
and_here_also)

I know PEP 8 says I should drop the final round bracket to the next line,
but I don't normally like that.

> 4. Spend 45 minutes trying to think up shorter [but still sensible]
> variable names to make it fit.

Ha! Since most of my variable names are already relatively short, that's
not often much help.

> 5. Perform an otherwise pointless assignment to a temp variable on the
> previous line to make it fit.

Hardly ever.

You missed one:

5a. Perform an assignment to a temp variable that you really should have
done anyway, but reducing the number of characters in the line was the
impetus that finally made you act.

> 6. Realise that if it's that long, it probably shouldn't have been a
> list comprehension in the first place.

What if it wasn't a list comp in the first place? :)

Refactoring code makes most long lines go away on their own.



--
Steven

[Demian Brecht]

> 3. Say "well, at least it's not a backslash" and break the line using
> parentheses.

This. More times than not, there's a function call in that line, which
makes sense to me when reading it if the args are on the next line.

> 4. Spend 45 minutes trying to think up shorter [but still sensible]
> variable names to make it fit.

I generally can't shorten my variable names without breaking the
minimum length PEP8 rule ;)


Now having said that, it kind of depends on the code base I'm working
with. If it's my own project, I never go past 79 characters (vim
tw=79). However, if it's a code base that I didn't start and it seems
to consistently go past 79 characters, I'll usually follow suit (with
my feet dragging of course). Nothing worse than inconsistency, even if
it's a standard I don't necessarily agree with :P

[rusi]

On Oct 18, 11:06 am, Zero Piraeus <sche...@gmail.com> wrote:
> :
>
> Okay, so, first thing vaguely Python-related that comes to mind [so
> probably not even slightly original, but then that's not really the
> point]:
>
> What are people's preferred strategies for dealing with lines that go
> over 79 characters? A few I can think of off the bat:

It really depends on whether one is programming for learning, as a
profession or publicly (as on this list).

The third is necessary to say because mailers are going to break long
lines.
As for the other two, there is a distinction because:
For example, a candidate C-programmer would be expected to show
prowess with pointers in an interview that would be frowned upon when
he professionally develops in C for production.

[Paul Rubin]

Zero Piraeus <sch...@gmail.com> writes:
> 2. Say "screw it" and break the line using a backslash.

Often the line will break ok without a backslash, but I don't feel any
particular pain in using a backslash in the other cases.

I do pretty rigorously try to keep all lines shorter than 72 columns or
so, unless there's a long literal like a url. Even such a literal would
probably only occur in throwaway code. Any specific url in
longer-lasting code should probably be read from a configuration file
rather than being hard coded.

[Hans Mulder]

On 18/10/12 08:31:51, Steven D'Aprano wrote:
> On Thu, 18 Oct 2012 02:06:19 -0400, Zero Piraeus wrote:
>> 3. Say "well, at least it's not a backslash" and break the line using
>> > parentheses.
> I mostly do this. Since most lines include a bracket of some sort, I
> rarely need to add outer parentheses just for the purpose of line
> continuation.
>
> some_variable = spam('x') + ham(
> some_longer_variables, here_and_here,
> and_here_also)

I would spell that as:

some_variable = spam('x') + ham(
some_longer_variables,
here_and_here,

and_here_also,

)

> I know PEP 8 says I should drop the final round bracket to the next line,
> but I don't normally like that.

I normally put the final bracket on the next line, where it is
very visible. Compare:

if looks_like_it_might_be_spam(
some_longer_variables,
here_and_here, and_here_also):
logger.notice("might be spam")
move_to_spam_folder(some_longer_variables)
update_spam_statistics(here_and_here)

vs.

if looks_like_it_might_be_spam(
some_longer_variables,
here_and_here,
and_here_also,
):
logger.notice("might be spam")
move_to_spam_folder(some_longer_variables)
update_spam_statistics(here_and_here)

Which one would you say is more readable?


-- HansM

[Mark Lawrence]

On 18/10/2012 07:06, Zero Piraeus wrote:
> :
>
> Okay, so, first thing vaguely Python-related that comes to mind [so
> probably not even slightly original, but then that's not really the
> point]:
>
> What are people's preferred strategies for dealing with lines that go
> over 79 characters? A few I can think of off the bat:
>

> 1. Say "screw it" and go past 79, PEP8 be damned.
>

> 2. Say "screw it" and break the line using a backslash.

>
> 3. Say "well, at least it's not a backslash" and break the line using
> parentheses.
>

> 4. Spend 45 minutes trying to think up shorter [but still sensible]
> variable names to make it fit.
>

> 5. Perform an otherwise pointless assignment to a temp variable on the
> previous line to make it fit.
>

> 6. Realise that if it's that long, it probably shouldn't have been a
> list comprehension in the first place.
>

> Any I've missed? Any preferences?
>
> -[]z.
>

I suggest re-reading PEP 8, particularly the section titled "A Foolish
Consistency is the Hobgoblin of Little Minds" and specifically the first
sentence of the third paragraph "But most importantly: know when to be
inconsistent -- sometimes the style guide just doesn't apply."

--
Cheers.

Mark Lawrence.

[wxjm...@gmail.com]

I use a "double indentation".

>>> if 'asdf' and 'asdf' and 'asdf' \
... 'asdf' and 'asdf' and \
... 'asdf' and 'asdf':
... print('do if')
... s = 'asdf'
... ss = 'asdf'
...
do if
>>> if looks_like_it_might_be_spam(
... some_longer_variables,
... here_and_here, and_here_also):
... logger.notice("might be spam")
... move_to_spam_folder(some_longer_variables)
... update_spam_statistics(here_and_here)
...
Traceback (most recent call last):

jmf

[Chris Angelico]

On Thu, Oct 18, 2012 at 8:07 PM, Hans Mulder <han...@xs4all.nl> wrote:
>
> if looks_like_it_might_be_spam(
> some_longer_variables,
> here_and_here, and_here_also):
> logger.notice("might be spam")
> move_to_spam_folder(some_longer_variables)
> update_spam_statistics(here_and_here)
>

This wants different indentation levels for the condition and the
code. That'd make it readable enough.

ChrisA

[Zero Piraeus]

:

There seems to be a consensus [to the extent there ever is, anyway]
around using parentheses etc., then ...

On 18 October 2012 02:31, Steven D'Aprano

<steve+comp....@pearwood.info> wrote:
> I've been burnt enough by word-wrapping in editors that don't handle word-
> wrapping that well that it makes me really uncomfortable to go over 78-79
> characters, even by only 1 extra. So I don't like doing this.

I have to admit, I try quite hard not to exceed 78. I don't know why
[never been bitten by badly behaved editors], but something about 79
characters in an 80-char window makes me uncomfortable.

> Just about the only time I go over is if I have a comment that includes a
> URL with more than 78 characters. I hate breaking URLs more than I hate
> breaking the 79 character limit.

Agreed.

> You missed one:
>
> 5a. Perform an assignment to a temp variable that you really should have
> done anyway, but reducing the number of characters in the line was the
> impetus that finally made you act.

Ah. Yes :-)

On 18 October 2012 05:33, <wxjm...@gmail.com> wrote:
> I use a "double indentation".
>
>>>> if 'asdf' and 'asdf' and 'asdf' \
> ... 'asdf' and 'asdf' and \
> ... 'asdf' and 'asdf':
> ... print('do if')
> ... s = 'asdf'
> ... ss = 'asdf'

Actually, I had a follow-up question about indentation planned. I used
to double-indent, but am now more likely to go with e.g.

>>> if check_something(
... arg1,
... arg2,
... arg3
... ):
... do_something()

as others have suggested. An alternative would be something like

>>> if check_something(arg1,
... arg2,
... arg3):
... do_something()

which I like much less. I have to admit, though, that all the original
options make me feel a little dirty except (#4) "shorter variable
names" [which just makes me feel that I am being overly precious] and
(#6 generalised) "this needs refactoring" [which I would say includes
Steven's #5a].

-[]z.

[Tim Chase]

On 10/18/12 04:33, wxjm...@gmail.com wrote:
> I use a "double indentation".
>
>>>> if 'asdf' and 'asdf' and 'asdf' \
> ... 'asdf' and 'asdf' and \
> ... 'asdf' and 'asdf':
> ... print('do if')
> ... s = 'asdf'
> ... ss = 'asdf'
> ...
> do if
>>>> if looks_like_it_might_be_spam(
> ... some_longer_variables,
> ... here_and_here, and_here_also):
> ... logger.notice("might be spam")
> ... move_to_spam_folder(some_longer_variables)
> ... update_spam_statistics(here_and_here)

I lean towards double-indent as well, though I favor parens/brackets
vs. trailing backslashes. My conditions usually go one-per-line,
too. I also tend to put my closing paren+colon on a stand-alone line:

if (
something
or something_else
or yet_other_stuff
):
do_thing1()
do_thing2()

It's not quite as nice with pure parens, working better with
function-calls. However, it makes my git/svn diffs easier to read
when conditions get added/removed because only that line (usually)
changes, rather than having the noise of the paren moving around.

In 2.5 and later, I like to write that as

if any([
something,
something_else,
yet_other_stuff,
]):
do_thing1()
do_thing2()

where each item is uniform (one trailing comma, rather than one item
being special without a comma/or/and) so I don't have the diff noise
for "or"/"and" bouncing around either.

Making my diffs easy to read is pretty important to me.

-tkc

PS: and in such cases, yes, I often alphabetize my conditions too as
long as the order doesn't matter. Just a little CDO. That's OCD,
but in alphabetical order the way the letters should be :-)

[Grant Edwards]

On 2012-10-18, Zero Piraeus <sch...@gmail.com> wrote:

> What are people's preferred strategies for dealing with lines that go
> over 79 characters? A few I can think of off the bat:

I try to do what's easiest to read and understand. Sometimes that
means using a line thats 120 characters long, sometimes that means
breaking up the line.

--
Grant Edwards grant.b.edwards Yow! Am I in GRADUATE
at SCHOOL yet?
gmail.com

[Jean-Michel Pichavant]

----- Original Message -----
> On 2012-10-18, Zero Piraeus <sch...@gmail.com> wrote:
>
> > What are people's preferred strategies for dealing with lines that
> > go
> > over 79 characters? A few I can think of off the bat:
>
> I try to do what's easiest to read and understand. Sometimes that
> means using a line thats 120 characters long, sometimes that means
> breaking up the line.
>

Imo, def. a good approach to the problem. Mark's also pointed the fact that the guidelines themselves state that rules are made to be broken when they need to be.
The 79 char limit purpose is to allow someone to read the code on a 80 char terminal (and allow old printers to print the code). If following this rules breaks readability for all other terminals, meaning 99,99% of them, you know what to do.

JM

[Den]

On Wednesday, October 17, 2012 11:06:43 PM UTC-7, Zero Piraeus wrote:
> :
>
>
> What are people's preferred strategies for dealing with lines that go
>
> over 79 characters? A few I can think of off the bat:
>

I personally just keep typing until my statement is finished. This is my program, not PEP's.

But I have to say I'm amused by the whole question, and others related to PEP8. A quick aside, the width of our roads all go back to the width of a two horse rig. The suggested maximum of 80 characters goes back to teletype machines, and IBM cards, and character based terminals

Should that really be the basis for a suggested style now?

Den

[Den]

On Wednesday, October 17, 2012 11:06:43 PM UTC-7, Zero Piraeus wrote:
> :
>
>

> What are people's preferred strategies for dealing with lines that go
>
> over 79 characters? A few I can think of off the bat:
>

[Neil Cerutti]

On 2012-10-18, Den <paten...@gmail.com> wrote:
> But I have to say I'm amused by the whole question, and others
> related to PEP8. A quick aside, the width of our roads all go
> back to the width of a two horse rig. The suggested maximum of
> 80 characters goes back to teletype machines, and IBM cards,
> and character based terminals
>
> Should that really be the basis for a suggested style now?

I had to use vim's reformatting powers to fix your first
paragraph. ;)

http://www.codinghorror.com/blog/2006/06/text-columns-how-long-is-too-long.html

Code is limited to one column, is left-justified, and
comprehension is much more important than reading speed. There
are lots of studies, but they are all about blocks of text, not
code.

Though technology has moved along swiftly, keeping your code
accessible to the guy using a crummy old console xterm might
still be worthwhile, and it makes printouts easy to create.

--
Neil Cerutti

[Chris Angelico]

On Fri, Oct 19, 2012 at 2:49 AM, Dan Stromberg <drsa...@gmail.com> wrote:
> In fact, I tend to do lots of "otherwise pointless" variables, because I
> want to be able to quickly and easily insert print statements/functions
> without having to split up large commands, during debugging.

When will we next have a language with something like the REXX 'trace
i' command?

[C:\Desktop]rexxtry trace i; say 1+2*3 "equals" words(linein(word(source,3)))
95 *-* Say 1 + 2 * 3 'equals'
words(linein(word(source, 3)));
>L> "1"
>L> "2"
>L> "3"
>O> "6"
>O> "7"
>L> "equals"
>O> "7 equals"
>V> "OS/2 COMMAND C:\OS2\REXXTRY.CMD"
>L> "3"
>F> "C:\OS2\REXXTRY.CMD"
>F> "/* SAA-portable REXXTRY procedure
11/08/91 version 1.05"
>F> "7"
>O> "7 equals 7"
>>> "7 equals 7"
96 *-* Trace 'Off';

Intermediate expression/statement evaluation, full details. Takes some
knowledge to comprehend (>L> means literal, >V> variable, >F> function
return value, etc), but extremely handy. Unfortunately REXX is an
aging language, as evidenced by such features as DBCS support (but no
Unicode), and functions as first-class objects support (nonexistent).
But this is a feature that I'd love to see implemented somewhere else.

Which probably means I'm going to have to write it somewhere else...

ChrisA

[Evan Driscoll]

Ooo, a good religious war. How could I resist? :-) Bear in mind that
what I say is relative to layout issues, which in the grand scheme of
things. So even if I say I really disklike something, it's still not so
bad in practice. Except for backslash continuations. :-)

On 10/18/2012 01:06 AM, Zero Piraeus wrote:
> What are people's preferred strategies for dealing with lines that go
> over 79 characters?

My general rules are:

1. I dislike 80 character limits, and basically don't make a
particularly strong attempt adhere to them for, well, basically
any code I write, Python or not. I'll explain a little bit of why
later. (I'd begrudgingly go along if I were working on a different
code base that did of course, but in the meantime I don't have to
deal with corporate style standards or anything like that so can
bend the rules a bit.) 100 about where I start getting
uncomfortable, and my semi-hard limit is 110-120. No doubt that's
because that's about the line length I get with half of my monitor's
width. :-)

Python isn't as bad as C++ though (my main other language), where
80 characters can go by *very* quickly.

2. Backslash continuations are *terrible*. I hate them with a firery
passion. :-) A line could be 1000 characters long and it would be
better than a 120-character line backslash-continued.

3. Using parentheses for continuations is sunshine and rainbows.

4. Extra variables are also great; I suspect I tend to use a
more-than-average amount of extra variables anyway. (Though
probably less so compared with the Python coder community than with
the C++ coder community.)


Hans Mulder said:

> Steven D'Aprano said:
>> some_variable = spam('x') + ham(
>> some_longer_variables, here_and_here,
>> and_here_also)
>
> I would spell that as:
>
> some_variable = spam('x') + ham(
> some_longer_variables,
> here_and_here,
> and_here_also,
> )

Ugh, I hate both. :-) I really dislike the arguments to a function
appearing to the left of the function. I'm fine with either

some_function(foo,
bar,
baz)

or

some_function(
foo,
bar,
baz)

but the two quoted suggestion makes me cringe a bit. (Of my two options,
I think I actually prefer the latter, but tend to use the former because
I'm too lazy to figure out how to make Emacs do the second one.)

So with the above rule I might format that as:

some_variable = spam('x') + ham(some_longer_variables,
here_and_here,

and_here_also)

except that runs afoul of another of my implict formatting "rules",
which is that if I have a multi-argument construct (e.g. an operator
or function call) and one of the arguments is multiple lines, I'd prefer
to see all of the arguments on their own lines. So I'd format
that as:

some_variable = (spam('x')
+ ham(a, b, c))

as my first choice (long var names truncated here, but in real code with
no indent that's only 76 characters with the full ones in so it's fine
-- I'd do it that way even with a couple levels of indent) and

some_variable = (spam('x')
+ ham(some_longer_variables,
here_and_here,
and_here_also))

as my second, even though they require an extra set of parentheses and
even though there is plenty of room on the first line for "foo +
foo(".


The reason I say I dislike the quoted suggestions -- and ultimately why
I really dislike the 80 character limit -- is the following. If you ask
proponents of the 80 character limit, they'll tell you about how there's
only so much horizontal space and stuff like that. But I think that
ignores the benefits you get from intelligently using *vertical* space,
and I think the quoted suggestions do too.

I've taken each of the suggested formattings of the above and turned
them into a graphic, which you can see at
http://pages.cs.wisc.edu/~driscoll/temp/indent.png

I've drawn the boundary of every valid subexpression (except for the RHS
of each assignment) in each of the versions. In my suggestions, the
"ham(....)" subexpression is always contained within a rectangle -- in
the quoted suggestions, it is not, and is a more complicated shape. It
seems to me that the relationship between the vertical and horizontal
layout in those examples is somewhat haphazard. I can't even come up
with a "rule" for how the quoted examples arose; for mine, I'd say I'm
trying to keep subexpressions together in space (both horizontal and
vertical). I'm not sure that "drawing boxes" is exactly the right thing
to say what I'm doing, but I think it at least serves to illustrate my
point in this case.

Evan

[Chris Angelico]

On Fri, Oct 19, 2012 at 3:13 AM, Neil Cerutti <ne...@norwich.edu> wrote:
> Though technology has moved along swiftly, keeping your code
> accessible to the guy using a crummy old console xterm might
> still be worthwhile, and it makes printouts easy to create.

And keeping your interface accessible to someone who can't use the
Home and End keys allows it to be used by someone who's using PuTTY on
Windows to SSH to a gateway and then SSH from there to a firewalled
computer that's running your application. And yes, I do exactly that,
and yes, for some reason Home/End don't always work. One day I'll
probably figure out what the issue is, but for now, I'm just glad
there are baseline text editors that don't need such keys...

Technology moves on, but not everywhere.

ChrisA

[Chris Angelico]

On Fri, Oct 19, 2012 at 3:16 AM, Evan Driscoll <dris...@cs.wisc.edu> wrote:
> Python isn't as bad as C++ though (my main other language), where
> 80 characters can go by *very* quickly.
>
> 2. Backslash continuations are *terrible*. I hate them with a firery
> passion. :-) A line could be 1000 characters long and it would be
> better than a 120-character line backslash-continued.

I have one mid-sized C++ project at work that's pretty much
exclusively under my control. There is precisely ONE place where
backslash continuations crop up, and that's long strings that want to
be formatted on multiple lines (eg huge SQL statements) - in Python,
they'd be trip-quoted. We don't have *any* backslash continuations in
Python code.

ChrisA

[Dave Angel]

But both C++ and Python have automatic concatenation of adjacent
strings. So you can just start and end each line with a quote, and
leave off the backslash.

Similarly, if you need a newline at the end of each line, you can use
the \n just before the trailing quote. Naturally I agree with you that
this case is better handled in Python with triple-quote.

I never use the backslash at end-of-line to continue a statement to the
next. Not only is it a readability problem, but if your editor doesn't
have visible spaces, you can accidentally have whitespace after the
backslash, and wonder what went wrong.

--

DaveA

[Dave Angel]

On 10/18/2012 12:58 PM, Chris Kaynor wrote:
> On Thu, Oct 18, 2012 at 9:47 AM, Dave Angel <d...@davea.name> wrote:
>
>> <SNIP>

>> But both C++ and Python have automatic concatenation of adjacent
>> strings. So you can just start and end each line with a quote, and
>> leave off the backslash.
>>

> That will work in C++ as the statements won't terminate on new-line (only
> on semi-colon), however in Python that won't work as the statement
> will terminate at the end of the line. You can get around this by wrapping
> the multiple strings inside of parentheses.
>
>

You're right of course. As it happens, i tested my "remembery" with a
function call (print, in Python 3) , so I already had the parens.

--

DaveA

[Grant Edwards]

On 2012-10-18, Den <paten...@gmail.com> wrote:

You don't expect me to through my Heathkit H19 terminal in the trash,
do you? :)

--
Grant Edwards grant.b.edwards Yow! This is a NO-FRILLS
at flight -- hold th' CANADIAN
gmail.com BACON!!

[Prasad, Ramit]

Unlike IBM cards and the teletype, character based terminals are still
widely used (at least in the developer communities). They often default to
80 characters, but handle various sizes. So that comparison is not quite
fair.

Ramit Prasad

This email is confidential and subject to important disclaimers and
conditions including on offers for the purchase or sale of
securities, accuracy and completeness of information, viruses,
confidentiality, legal privilege, and legal entity disclaimers,
available at http://www.jpmorgan.com/pages/disclosures/email.

[Prasad, Ramit]

Chris Angelico wrote:
> On Fri, Oct 19, 2012 at 3:13 AM, Neil Cerutti <ne...@norwich.edu> wrote:

> > Though technology has moved along swiftly, keeping your code
> > accessible to the guy using a crummy old console xterm might
> > still be worthwhile, and it makes printouts easy to create.
>

> And keeping your interface accessible to someone who can't use the
> Home and End keys allows it to be used by someone who's using PuTTY on
> Windows to SSH to a gateway and then SSH from there to a firewalled
> computer that's running your application. And yes, I do exactly that,
> and yes, for some reason Home/End don't always work. One day I'll
> probably figure out what the issue is, but for now, I'm just glad
> there are baseline text editors that don't need such keys...
>
> Technology moves on, but not everywhere.
>
> ChrisA

> --

Home and end do not bother me much as I can usually use ctrl+a/ctrl+e
for the same purpose. I do wish I found a better way to page up/down.

[Prasad, Ramit]

For the first example, I would probably indent the arguments more
to differentiate a continuing line. That way the "):" does not
look like it was un-indented to be part of a different block.

if looks_like_it_might_be_spam(
some_longer_variables,
here_and_here, and_here_also):
logger.notice("might be spam")
move_to_spam_folder(some_longer_variables)
update_spam_statistics(here_and_here)

[Ian Kelly]

On Thu, Oct 18, 2012 at 10:47 AM, Dave Angel <d...@davea.name> wrote:
> I never use the backslash at end-of-line to continue a statement to the
> next. Not only is it a readability problem, but if your editor doesn't
> have visible spaces, you can accidentally have whitespace after the
> backslash, and wonder what went wrong.

Note the actual error message that you get in this case is:

"SyntaxError: unexpected character after line continuation character"

Seems pretty transparent to me.

[Zero Piraeus]

:

On 18 October 2012 11:55, Den <paten...@gmail.com> wrote:
> [...] I'm amused by the whole question, and others related

> to PEP8. A quick aside, the width of our roads all go back to the
> width of a two horse rig. The suggested maximum of 80 characters goes
> back to teletype machines, and IBM cards, and character based

> terminals [...]

... and the decisions made back in the day about line length on
teletypes etc. were informed [perhaps unconsciously] by the rules of
printed literature - and *those* rules have a *lot* of accumulated
wisdom behind them.

Robert Bringhurst's Elements of Typographical Style is very good on
that stuff; one thing he points out is that, at root, what's
comfortable is defined by the size of the human hand, the distance we
hold a book from our eye, etc. ... and while we still live in a world
composed of physical objects, a lot of that gut feeling about what's
comfortable carries across into the digital world.

The accepted rule in print is that lines of prose should be between 45
and 90 characters, with 66 being ideal for readability. Code is not
prose, and the combination of fixed-width and much more variable line
length aids readability, but however it came about, ~80 does seem to
more or less work as a limit.

I'm pretty slavish about adhering to PEP 8 these days. Programmers are
an opinionated bunch, and we all, given the opportunity, will come up
with our own set of obviously [goddammit] correct rules. Having a
broadly sensible, authoritative set of guidelines that we grudgingly
agree to follow makes working with other coders easier IMO.

-[]z.

[Gene Heskett]

On Thursday 18 October 2012 18:40:52 Grant Edwards did opine:

> On 2012-10-18, Den <paten...@gmail.com> wrote:
> > On Wednesday, October 17, 2012 11:06:43 PM UTC-7, Zero Piraeus wrote:
> >> What are people's preferred strategies for dealing with lines that go
> >
> >> over 79 characters? A few I can think of off the bat:
> > I personally just keep typing until my statement is finished. This
> > is my program, not PEP's.
> >
> > But I have to say I'm amused by the whole question, and others
> > related to PEP8. A quick aside, the width of our roads all go back
> > to the width of a two horse rig. The suggested maximum of 80
> > characters goes back to teletype machines, and IBM cards, and
> > character based terminals
> >
> > Should that really be the basis for a suggested style now?
>
> You don't expect me to through my Heathkit H19 terminal in the trash,
> do you? :)

Or me to delete the vt-220 I wrote to run on a TRS-80 Color Computer
running OS-9 for an OS, 20 years ago when the Dec made one ate its H.O.T. &
Dec would not sell me a H.O.T. since it was over 5 years old and wanted
$2995 for brand new vt-550 (with no guarantee it would be compatible)?

That, and their field service engineers inability to fix a crashing hourly
or more PDP-11/723a amply explains why DEC is no longer with us.

That single obstinate computer made the CBS tv network design a new system
and distribute it gratis to every network affiliate they had, somewhere
around 125 stations, at a cost of at least 10G's a station.

Screw that. I had better things to than throw more good money after bad.
So did CBS at the time.

Cheers, Gene
--
"There are four boxes to be used in defense of liberty:
soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
My web page: <http://coyoteden.dyndns-free.com:85/gene> is up!
How sharper than a hound's tooth it is to have a thankless serpent.

[Ben Finney]

Zero Piraeus <sch...@gmail.com> writes:

> :
>

(Why is this colon appearing at the top of your messages? Can you remove
it if it's not germane?)

> What are people's preferred strategies for dealing with lines that go
> over 79 characters? A few I can think of off the bat:

> 1. Say "screw it" and go past 79, PEP8 be damned.

There are many people who are irritated by Python code that has lines
longer than 80 characters. In my experience, though, it's much easier to
read code which is written using a strict maximum length of 80
characters per line, and code which tends to exceed that length is
strongly correlated with code which is difficult to read for other
reasons too.

> 2. Say "screw it" and break the line using a backslash.

Never this. A backslash is almost never a good choice (it leaves the
code in a state that an invisible difference – trailing whitespace – can
cause it to break), especially because there are so many other better
options.

> 3. Say "well, at least it's not a backslash" and break the line using
> parentheses.

Long lines frequently have some kind of bracketing syntax (parentheses,
brackets, braces, triple-quotes, etc.) which make it easy to break the
line properly. That's a natural place to break the line, and the
continuations should all be indented 8 characters (recommended in PEP 8
also).

> 4. Spend 45 minutes trying to think up shorter [but still sensible]
> variable names to make it fit.

If the names are so long that they make it difficult to fit the line
within 80 characters, one of the following is probably true:

* The line is indented too far. Re-factor the chunk of code to a smaller
function.

* The line is too complex. Break it into several smaller statements.

* The names are too long. Make them descriptive, but not huge. In a
simple function (which all of them should ideally be) there should be
few enough names involved that they can all be short. Corollary: if
the names are too long, the function is probably too dependent on a
large context.

> 5. Perform an otherwise pointless assignment to a temp variable on the
> previous line to make it fit.

Using assignments for intermediate steps is not pointless. One
significant benefit is that it makes the code more obvious to the
reader.

> 6. Realise that if it's that long, it probably shouldn't have been a
> list comprehension in the first place.

List comprehensions are already within bracketing syntax, so are
trivially easy to break across multiple lines.

> Any I've missed? Any preferences?

I prefer continuation lines to look like this::

def prepare_smorgasbord(
smorgasbord_class, poultry, food_preparation_handbook):
""" Prepare the smorgasbord with poultry.

The `food_preparation_handbook` is used to cite a warning if
a gizzard is past its expiration date.

"""
smorgasbord = smorgasbord_class()
for item in [
foo for foo in
poultry.giblets.iteritems()
if foo.type = 'gizzard']:
smorgasbord.add(
prepare_gizzard_for_consumption(item))
if item.expiry < datetime.datetime.now():
smorgasbord.flag(
food_preparation_handbook.warning("Only for the brave"))

return smorgasbord

Every statement should stay beyond the starting level of indentation;
returning to the same level of indentation or earlier should only happen
when a new statement occurs.

The 8-column indentation makes it clear that this is not a new code
block, making it obvious to the eye where a code block (indented at 4
columns) actually starts.

That's a contrived example, obviously, and for some of those things I'd
probably be tempted to re-factor self-contained parts to separate
functions in order to make the code at this location simpler. But it
illustrates the line continuation style I advocate.

--
\ “Program testing can be a very effective way to show the |
`\ presence of bugs, but is hopelessly inadequate for showing |
_o__) their absence.” —Edsger W. Dijkstra |
Ben Finney

[Ben Finney]

Hans Mulder <han...@xs4all.nl> writes:

> On 18/10/12 08:31:51, Steven D'Aprano wrote:
> > some_variable = spam('x') + ham(
> > some_longer_variables, here_and_here,
> > and_here_also)

The indentation level for continuation lines shouldn't be dependent on
the content of the first line of the statement. That leads to either
pointless fiddling with the continuation lines when one line changes; or
to a large indentation which is also pointless because it no longer
matches the first line.

> I would spell that as:
>
> some_variable = spam('x') + ham(
> some_longer_variables,
> here_and_here,
> and_here_also,
> )

I dislike the indentation of the final line, because it pops out like
the start of a new statement. Either::

some_variable = spam('x') + ham(
some_longer_variables,
here_and_here,
and_here_also)

do_next_thing()

Or::

some_variable = spam('x') + ham(
some_longer_variables,
here_and_here,
and_here_also,
)

do_next_thing()

depending on whether I deem it likely that new items will later be added
within the parentheses.

> > I know PEP 8 says I should drop the final round bracket to the next
> > line, but I don't normally like that.
>
> I normally put the final bracket on the next line, where it is
> very visible. Compare:
>
> if looks_like_it_might_be_spam(
> some_longer_variables,
> here_and_here, and_here_also):
> logger.notice("might be spam")
> move_to_spam_folder(some_longer_variables)
> update_spam_statistics(here_and_here)

To avoid this problem, I advocate 8-column indentation for continuation lines
to contrast with the 4-column indentation for a code block::

if looks_like_it_might_be_spam(
some_longer_variables,
here_and_here, and_here_also):
logger.notice("might be spam")
move_to_spam_folder(some_longer_variables)
update_spam_statistics(here_and_here)

>
> vs.
>
> if looks_like_it_might_be_spam(
> some_longer_variables,
> here_and_here,
> and_here_also,
> ):
> logger.notice("might be spam")
> move_to_spam_folder(some_longer_variables)
> update_spam_statistics(here_and_here)
>
> Which one would you say is more readable?

Mine :-)

--
\ “When I get new information, I change my position. What, sir, |
`\ do you do with new information?” —John Maynard Keynes |
_o__) |
Ben Finney

[Ben Finney]

Jean-Michel Pichavant <jeanm...@sequans.com> writes:

> The 79 char limit purpose is to allow someone to read the code on a 80
> char terminal (and allow old printers to print the code).

There is a very good reason for a strict line width limit regardless of
terminal size: scanning long lines is cognitively more difficult than
scanning shorter lines.

This doesn't mean we should keep reducing the length of our lines, of
course; obviously there needs to be enough room on a line to be
expressive. But it does mean that lines which are too long are not kind
to the reader.

Another good reason: Even if you have a large terminal, you will often
need to compare distinct sections of code. Knowing that code won't
exceed 80 columns means that you can lay several windows of code
side-by-side, for a three-way merge, for example.

--
\ “Anyone who believes exponential growth can go on forever in a |
`\ finite world is either a madman or an economist.” —Kenneth |
_o__) Boulding |
Ben Finney

[Steven D'Aprano]

On Thu, 18 Oct 2012 12:47:48 -0400, Dave Angel wrote:

> I never use the backslash at end-of-line to continue a statement to the
> next. Not only is it a readability problem, but if your editor doesn't
> have visible spaces, you can accidentally have whitespace after the
> backslash, and wonder what went wrong.

What, you don't read the SyntaxError that you will invariably get?


# Python 2.7 and 3.3:

py> x = 42 + \
File "<stdin>", line 1
x = 42 + \
^

SyntaxError: unexpected character after line continuation character

Even if you go back to truly ancient Python 1.5:

[steve@ando ~]$ python1.5
Python 1.5.2 (#1, Aug 27 2012, 09:09:18) [GCC 4.1.2 20080704 (Red Hat
4.1.2-52)] on linux2
Copyright 1991-1995 Stichting Mathematisch Centrum, Amsterdam
>>> x = 42 + \
File "<stdin>", line 1
x = 42 + \
^
SyntaxError: invalid token


Honestly, it's not that hard to diagnose line continuation errors. It's
probably easier to diagnose them than to diagnose missing parentheses.

The more I hear people dissing line continuation backslashes, the more I
want to use them everywhere.


--
Steven

[Steven D'Aprano]

On Thu, 18 Oct 2012 15:59:18 +0200, Jean-Michel Pichavant wrote:

> ----- Original Message -----
>> On 2012-10-18, Zero Piraeus <sch...@gmail.com> wrote:
>>
>> > What are people's preferred strategies for dealing with lines that go
>> > over 79 characters? A few I can think of off the bat:
>>
>> I try to do what's easiest to read and understand. Sometimes that
>> means using a line thats 120 characters long, sometimes that means
>> breaking up the line.
>>
>>
> Imo, def. a good approach to the problem. Mark's also pointed the fact
> that the guidelines themselves state that rules are made to be broken
> when they need to be. The 79 char limit purpose is to allow someone to
> read the code on a 80 char terminal (and allow old printers to print the
> code).

And people who like to have multiple windows open side-by-side.

And people who may have some need to email or post code inline rather
than as attached files (say, on this list).

And people who may need to run external tools over their code (e.g. grep,
diff) and view the output in a terminal with, say, 120 character width.
This allows ~80 characters for the source and ~40 characters for whatever
extraneous information the tool displays on the same line.

And, quite frankly, people who care more about the readability of their
code than about squeezing in as much processing into a single line of
text as possible.

In my not-in-the-slightest-bit-humble opinion, if someone is consistently
needing more than 79 characters per line, they're probably doing one or
more of the following coding sins:

- using one-liners for the sake of one liners;
- code that is too deeply nested (if you need more than 3 or 4 indents
for a block, you're probably doing something wrong);
- doing too much in one line, e.g. overly busy list comps;
- excessively long variable or function names;
- badly designed functions or classes that take too many arguments;
- misuse of Hungarian Notation; and
- violations of the Law of Demeter.

Or possibly they're just unlucky to require a library with excessively
long names and can't do much about it.

I'm not saying that every line that exceeds 79 characters is crap, but I
am saying that if you have trouble keeping *at least* 90% of your code
under 79 characters, you may very well be suffering from poor design,
lousy code, or both.

Flame away :)



--
Steven

[Steven D'Aprano]

On Thu, 18 Oct 2012 17:36:57 -0400, Zero Piraeus wrote:

> The accepted rule in print is that lines of prose should be between 45
> and 90 characters, with 66 being ideal for readability. Code is not
> prose, and the combination of fixed-width and much more variable line
> length aids readability, but however it came about, ~80 does seem to
> more or less work as a limit.

On the other hand, code is typically *much* harder to understand than
normal prose.

On the third hand, the "chunks" of semantic meaning in code is
significantly greater -- you can often ignore 99% of the code and just
skim past it, and so not even notice long line lengths until you get to
the specific few lines you care about. But once you reach the lines you
care about, or *might* care about, horizontal space is costly and
vertical space is cheap.

So reading code often has two distinct phases: skim and inspect. When
skimming, vertical space is at a premium, and you want to fit as much
code as possible in as few lines as possible. When inspecting code
closely, you want to fit as little code as practical in each line. So
there's a trade-off.

But for anything but the most horribly obfuscated code, it is much easier
to identify bits of code that are irrelevant to your problem than to
identify which bit of code is specifically causing the bug. So skimming
is inherently easier than close study (well duh). Consequently it is wise
to optimise your code layout for the hard parts, not the easy parts, and
so you should treat vertical space is cheaper than horizontal space, and
try to keep your line length down.

And note that, even when writing, most of your time is problem spent in
writing what is already there. Coding is rarely like typing out dictation.


--
Steven

[Dave Angel]

The context was both C++ and python, and I got into the habit of
avoiding the continuation characters in C++, where the compiler usually
has a totally stupid error, if any.

it's been so long since I've used them, it's quite possible I never
tried it in python.


--

DaveA

[rusi]

>  \       “When I get new information, I change my position. What, sir, |
>   `\             do you do with new information?” —John Maynard Keynes |
> _o__)                                                                  |

> \ “Anyone who believes exponential growth can go on forever in a |
> `\ finite world is either a madman or an economist.” —Kenneth |
> _o__) Boulding |

I am amused by the juxtaposition of these two signatures --
considering that Keynes was an economist

[Steven D'Aprano]

On Thu, 18 Oct 2012 20:35:20 -0700, rusi wrote:
(extracting the text without the ASCII-art)

> > “When I get new information, I change my position. What, sir,
> > do you do with new information?” —John Maynard Keynes

> > “Anyone who believes exponential growth can go on forever in a

> > finite world is either a madman or an economist.” —Kenneth Boulding

>
> I am amused by the juxtaposition of these two signatures --
> considering that Keynes was an economist

So was Kenneth Boulding.


http://www.adbusters.org/magazine/85/kenneth-boulding.html


I dare say that Keynes, and Adam Smith for that matter, would have agreed
with him.




--
Steven

[Jean-Michel Pichavant]

----- Original Message -----
[snipe 80 char line discussion]

> And, quite frankly, people who care more about the readability of
> their
> code than about squeezing in as much processing into a single line of
> text as possible.
>

As usual Steven, you take someone's argument, you add a little bit of exaggeration and make it sound silly.
Using 80+ char lines doesn't mean I put all my efforts exceeding the 80 char limit. As a matter of fact, I never
get the char limit get into the way of readability. What needs to be short will be short, and what needs to be long will be long.


[snip]
> Flame away :)

good job :o)

JM

[Demian Brecht]

On 2012-10-18, at 6:34 PM, Steven D'Aprano <steve+comp....@pearwood.info> wrote:

> Flame away :)


This post made my Friday, even though I'm sitting on a nearly two hour bus ride into work because I missed my commuter train. Just wanted you to know ;) You noted *every* reason (and them some) why my own code never passed 79 chars and why I try to instil that same value in others.

[Steven D'Aprano]

On Fri, 19 Oct 2012 11:21:06 +0200, Jean-Michel Pichavant wrote:

> Using 80+ char lines doesn't mean
> I put all my efforts exceeding the 80 char limit.

I didn't say it did. I was describing some of the reasons people might
choose to stick to the 79 character limit, beyond the reason you gave,
which quite frankly is the least important reason. 80 character
terminals? Who still uses them? Well, a few people, but they're in a
minority. But caring about the readability of code? Everyone needs to
read code at some point, and 79 characters is a good balance between
stuffing too much into a single line and spreading it out too thinly over
multiple lines.

> As a matter of fact, I
> never get the char limit get into the way of readability. What needs to
> be short will be short, and what needs to be long will be long.

Code never *needs* to be long, because it can always be shortened.

Some code might be more conveniently written as a single long line. But I
would argue that nearly never is code more easily *read* as a single long
line, and since code is read much more than it is written, it is more
important to optimise for reading, not writing.



--
Steven

[Krzysztof Voss]

On Thursday, October 18, 2012 12:06:43 AM UTC-6, Zero Piraeus wrote:
> :
>
>
>
> Okay, so, first thing vaguely Python-related that comes to mind [so
>
> probably not even slightly original, but then that's not really the
>
> point]:

>
>
>
> What are people's preferred strategies for dealing with lines that go
>
> over 79 characters? A few I can think of off the bat:
>
>
>

> 1. Say "screw it" and go past 79, PEP8 be damned.
>

Once you ":set cc=79", you never want to cross it.

>
>
> 2. Say "screw it" and break the line using a backslash.
>
>
>

> 3. Say "well, at least it's not a backslash" and break the line using
>
> parentheses.
>
>

Some nice, IMHO, tips on the style can be found in:
http://google-styleguide.googlecode.com/svn/trunk/pyguide.html#Line_length


Cheers!

[Krzysztof Voss]

[Tim Chase]

On 10/19/12 17:14, Steven D'Aprano wrote:
> Code never *needs* to be long, because it can always be shortened.

I advocate one bit per line:

1
0
1
0
0
1
0
1
1
0
0
1
0
1
1
1
0
0
0
0
1
1
1
0
1
1
0
0
1
1
0
1
1
0
0
1
1
1
1
0
0
1
1
1
1
1
1
1

«grins, ducks, and flees»

Shortenedly-yers,

-tkc

[rusi]

T
H
A
N
K
S

T
I
M
(for the sanity)

[Grant Edwards]

On 2012-10-20, Dennis Lee Bieber <wlf...@ix.netcom.com> wrote:

> Strangely, we've gone from 80-character fixed width displays to
> who-knows-what (if I drop my font size I can probably get nearly 200
> characters across in full-screen mode)...
>
> But at the same time we've gone from 132-character line-printers
> using fan-fold 11x17 pages, to office inkjet/laser printers using 8.5x11
> paper, defaulting to portrait orientation -- with a 10 character/inch
> font, and 1/4" left/right margins, we're back to 80 character limitation
><G>

True, but nobody prints source code out on paper do they?

Seriously -- I can't remember the last time I printed souce code...

--
Grant

[Walter Hurry]

On Sat, 20 Oct 2012 14:18:47 +0000, Grant Edwards wrote:

> True, but nobody prints source code out on paper do they?
>
> Seriously -- I can't remember the last time I printed souce code...

I remember my first IT job - COBOL programming in the early 80's. The
rule was that every time we delivered a new or updated program into
testing, we had to print a listing onto fanfold paper and hang it, in a
cardboard binder, onto a set of rails which ran down the center of the
office.

I recall even then thinking the practice ludicrous.

[David Robinow]

On Sat, Oct 20, 2012 at 3:10 PM, Dennis Lee Bieber
<wlf...@ix.netcom.com> wrote:
> On Sat, 20 Oct 2012 14:18:47 +0000 (UTC), Grant Edwards
> <inv...@invalid.invalid> declaimed the following in
> gmane.comp.python.general:

>
>>
>> True, but nobody prints source code out on paper do they?
>>
>> Seriously -- I can't remember the last time I printed souce code...
>

> Well, having been unemployed for a year, I can't speak much of
> recent practice...
>
> But I did tend to run up listings when I had to take over
> maintenance of some programs and needed to become familiar with the
> overall code base...
Same here. I've been unemployed (retired!) 6 years, but I'd
occasionally print code written by someone else, never anything of my
own.

[Roy Smith]

In article <5081d0c3$0$30003$c3e8da3$5496...@news.astraweb.com>,

Steven D'Aprano <steve+comp....@pearwood.info> wrote:

> Some code might be more conveniently written as a single long line. But I
> would argue that nearly never is code more easily *read* as a single long
> line, and since code is read much more than it is written, it is more
> important to optimise for reading, not writing.

Like many people here, I don't worry much about the 80 column limit. I
make my lines of code as long as they have to be, and no longer. If
there's some obvious and easy way to fold the statement onto multiple
lines, I'll do it. If not, I won't.

This tends to result in lines that are less than 80 characters, but if
not, I don't worry about it (assuming I'm even aware of it).

I just did a little experiment. I took about 20 KLOC of python that was
largely written by me and make a histogram of the line lengths
(http://www.panix.com/~roy/length.pdf). Just by eye, I'd say "most are
less than 80, almost all are less than 100". I'd guess the average of
all non-empty lines is about 45 or so. The longest line is 273
characters:

sys.stderr.write("Error: Can't find the file 'settings.py'
in the directory containing %r.\nYou'll have to run django-profile.py,
passing it your settings module.\n(If the file settings.py does indeed
exist, it's causing an ImportError somehow.)\n" % __file__)

Would that have been better rewritten broken up into several shorter
lines? Absolutely. Such is life.

PS: I didn't write that line :-)

[Steven D'Aprano]

On Sat, 20 Oct 2012 14:18:47 +0000, Grant Edwards wrote:

> On 2012-10-20, Dennis Lee Bieber <wlf...@ix.netcom.com> wrote:
>
>> Strangely, we've gone from 80-character fixed width displays to
>> who-knows-what (if I drop my font size I can probably get nearly 200
>> characters across in full-screen mode)...
>>
>> But at the same time we've gone from 132-character line-printers
>> using fan-fold 11x17 pages, to office inkjet/laser printers using
>> 8.5x11 paper, defaulting to portrait orientation -- with a 10
>> character/inch font, and 1/4" left/right margins, we're back to 80
>> character limitation
>><G>
>
> True, but nobody prints source code out on paper do they?

I do.

There's nothing better than spreading out a dozen sheets of source code
over a table to get a good, high-level overview of what does what in
preparation to refactoring it.

> Seriously -- I can't remember the last time I printed souce code...

I've never printed souce code either *wink*



--
Steven

[Chris Angelico]

So what you actually mean is that there's nothing _like_ spreading out
&c &c. I should think that throwing cold water over the code would be
better.

ChrisA

[Steven D'Aprano]

Er, no. Note spelling of "source code" vs "souce code". Hence the grin.

I seriously do print out source code. When I'm having trouble seeing how
the parts of a module fit together, reading print-outs is a good way
around the problem. Class browsers don't show you duplicate code, and
besides, only works with classes. Reading code on screen is limited in
how much you can see at a time. Both of these things play a part in
refactoring, and so does printing out the source and having a human being
(i.e. me) look at it.


--
Steven

[Tim Chase]

On 10/21/12 05:00, Steven D'Aprano wrote:
> I seriously do print out source code. When I'm having trouble
> seeing how the parts of a module fit together, reading print-outs
> is a good way around the problem.

I don't print my personal code--both in light of the fact that I
know it much more intimately and I longer own a printer. But when
trying to wrap my head around other people's code at work, printing
helps to get both the big picture and the details at the same time,
as well as allows me to annotate it with multi-colored
pens/highlighters.

Maybe I'll reconsider when I have a 300+ dpi desktop surface that is
as large as my desk+walls (where those printouts end up).

-tkc

[Gene Heskett]

On Sunday 21 October 2012 07:02:26 Steven D'Aprano did opine:

So do I, but I often am looking at assembler listings with the assembler
set for 132 chars a line to preserve the src codes comments, so lp gets a
use 17 cpi option on the cli that makes the listing. I probably recycle 2
reams of paper a year doing exactly that. Those who won't take advantage
of that are doomed to publish buggy code.

Cheers, Gene
--
"There are four boxes to be used in defense of liberty:
soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
My web page: <http://coyoteden.dyndns-free.com:85/gene> is up!
Not all men who drink are poets. Some of us drink because we aren't poets.

[Chris Angelico]

On Sun, Oct 21, 2012 at 9:00 PM, Steven D'Aprano
<steve+comp....@pearwood.info> wrote:
> Er, no. Note spelling of "source code" vs "souce code". Hence the grin.

Ahh. I totally didn't see that, I'm way too used to reading past
typos. Sure. Printing out *source* code, that's altogether different.

Me, though, I don't print anything. Paper and I are not exactly on
speaking terms; the last time we met, he cut me, and that's one of the
rudest things you can do to someone.

ChrisA

[DJC]

On 20/10/12 15:18, Grant Edwards wrote:
> On 2012-10-20, Dennis Lee Bieber <wlf...@ix.netcom.com> wrote:
>
>> Strangely, we've gone from 80-character fixed width displays to
>> who-knows-what (if I drop my font size I can probably get nearly 200
>> characters across in full-screen mode)...
>>
>> But at the same time we've gone from 132-character line-printers
>> using fan-fold 11x17 pages, to office inkjet/laser printers using 8.5x11
>> paper, defaulting to portrait orientation -- with a 10 character/inch
>> font, and 1/4" left/right margins, we're back to 80 character limitation
>> <G>
>
> True, but nobody prints source code out on paper do they?

I print source code. Usually when the development has got to a stage
that the program works but needs a lot of tidying up. It's a lot more
comfortable than scrolling up and down screen to look through pages from
the comfort of an armchair. Also I can take the listing to a Café and
write notes all over it. Sometimes removing the temptation to
immediately hit the keyboard is a good thing.

[Steven D'Aprano]

On Sun, 21 Oct 2012 22:43:07 +1100, Chris Angelico wrote:

> On Sun, Oct 21, 2012 at 9:00 PM, Steven D'Aprano
> <steve+comp....@pearwood.info> wrote:
>> Er, no. Note spelling of "source code" vs "souce code". Hence the grin.
>
> Ahh. I totally didn't see that, I'm way too used to reading past typos.

As a programmer, doesn't that screw up your debugging ability?

> Sure. Printing out *source* code, that's altogether different.
>
> Me, though, I don't print anything. Paper and I are not exactly on
> speaking terms; the last time we met, he cut me, and that's one of the
> rudest things you can do to someone.

Man, you must have deserved it. Paper, he don't just cut anybody.


--
Steven

[Grant Edwards]

On 2012-10-21, Steven D'Aprano <steve+comp....@pearwood.info> wrote:
> On Sun, 21 Oct 2012 22:43:07 +1100, Chris Angelico wrote:
>
>> On Sun, Oct 21, 2012 at 9:00 PM, Steven D'Aprano
>> <steve+comp....@pearwood.info> wrote:
>>> Er, no. Note spelling of "source code" vs "souce code". Hence the grin.
>>
>> Ahh. I totally didn't see that, I'm way too used to reading past typos.
>
> As a programmer, doesn't that screw up your debugging ability?

Indeed it does.

I spent a half hour the other day trying to figure out what was wrong
with a line of PHP code, when it was nothing but a mis-spelled
variable name. [I've only been working with PHP a short time, but
have quickly grown to dislike it.]

--
Grant

[Roy Smith]

In article <k61i2o$63u$1...@reader1.panix.com>,

Grant Edwards <inv...@invalid.invalid> wrote:

> On 2012-10-21, Steven D'Aprano <steve+comp....@pearwood.info> wrote:
> > On Sun, 21 Oct 2012 22:43:07 +1100, Chris Angelico wrote:
> >
> >> On Sun, Oct 21, 2012 at 9:00 PM, Steven D'Aprano
> >> <steve+comp....@pearwood.info> wrote:
> >>> Er, no. Note spelling of "source code" vs "souce code". Hence the grin.
> >>
> >> Ahh. I totally didn't see that, I'm way too used to reading past typos.
> >
> > As a programmer, doesn't that screw up your debugging ability?
>
> Indeed it does.

The human brain is amazingly good at real-time error correction. For
the most part, this improves communication since it lets people make all
sorts of minor errors in both spoken and written language without
seriously degrading comprehension.

The down-side is that you hear (and read) what you're expecting to hear
(or read). This makes us really suck as things like finding typos in
variable names.

> I spent a half hour the other day trying to figure out what was wrong
> with a line of PHP code, when it was nothing but a mis-spelled
> variable name. [I've only been working with PHP a short time, but
> have quickly grown to dislike it.]

Of course, the same can happen in Python. I could do:

foo = "default value"
if blah == 47:
fooo = "some other value"
print foo

No syntax error, no NameError, just the wrong thing printing. This does
not in any way detract from the fact that PHP is a horrible language.
Trust me, if you continue to use it, your dislike for it will only grow.
It is truly evil. Have you discovered "unexpected
T_PAAMAYIM_NEKUDOTAYIM" yet?

[Chris Angelico]

On Mon, Oct 22, 2012 at 6:11 AM, Steven D'Aprano

<steve+comp....@pearwood.info> wrote:
> On Sun, 21 Oct 2012 22:43:07 +1100, Chris Angelico wrote:
>
>> On Sun, Oct 21, 2012 at 9:00 PM, Steven D'Aprano
>> <steve+comp....@pearwood.info> wrote:
>>> Er, no. Note spelling of "source code" vs "souce code". Hence the grin.
>>
>> Ahh. I totally didn't see that, I'm way too used to reading past typos.
>
> As a programmer, doesn't that screw up your debugging ability?

Reading-past-typos applies mainly to English, which is a pretty
redundant language. In code, it would only apply to variable names;
with (effectively) single words/tokens standing alone, the automatic
correction doesn't really apply. But yes, sometimes I have stared at a
piece of code for a long time without knowing why there's an error on
line X. (This is another good reason to require that all variables be
declared, incidentally. I might have a variable called "source" but
not "souce", so using the other causes an instant compile-time failure
on the exact line with the bug.)

And Grant, I agree; PHP does not make life easy.

>> Sure. Printing out *source* code, that's altogether different.
>>
>> Me, though, I don't print anything. Paper and I are not exactly on
>> speaking terms; the last time we met, he cut me, and that's one of the
>> rudest things you can do to someone.
>
> Man, you must have deserved it. Paper, he don't just cut anybody.

Perhaps. Also, perhaps I've just finished Hell Week and am behaving
less than sanely, with a strong tendency to quote/reference Through
The Looking Glass. :)

ChrisA

[Chris Angelico]

On Mon, Oct 22, 2012 at 7:19 AM, Roy Smith <r...@panix.com> wrote:
> Of course, the same can happen in Python. I could do:
>
> foo = "default value"
> if blah == 47:
> fooo = "some other value"
> print foo
>
> No syntax error, no NameError, just the wrong thing printing.

Yeah, that's the worst kind of bug. No error, just wrong behaviour.
This kind of issue is one of the "balancing downsides" of the freedom
of not requiring variable declarations. For small scripts, it's not a
problem, and Python and PHP both save you the hassle of explicitly
telling the language that you really do know what you're doing, and
that's a Good Thing. For large modules, debugging creeps up in
significance, and variable declarations are less of a cost.
JaCMaScript in "use strict" mode and a good linter can catch a lot of
these sorts of bugs, though it has its own weirdnesses (why does a
'var' statement apply to the whole function regardless of where it
is?). C-derived languages with proper block scope have a good chance
of catching bugs of this nature at compile time, but at the cost of
demanding code that's mainly there to satisfy the compiler ("isn't it
OBVIOUS that I want this to be an integer? I'm assigning an integer to
it!").

> This does
> not in any way detract from the fact that PHP is a horrible language.
> Trust me, if you continue to use it, your dislike for it will only grow.
> It is truly evil. Have you discovered "unexpected
> T_PAAMAYIM_NEKUDOTAYIM" yet?

The double-double-dot-in-Hebrew token name isn't actually a bad error;
the only problem is the token name itself. If it said "unexpected
T_SCOPE" or something, it'd be easier to debug. Several of PHP's most
annoying issues are solved in version 5.4 (array indexing a function
call that returns an array now works), but there's still a huge
fundamental that's unsolved: Unicode support. Python FTW there,
especially now that PEP 393 means strings are as compact as possible.

ChrisA

[Walter Hurry]

On Sat, 20 Oct 2012 16:37:23 -0400, Roy Smith wrote:

> sys.stderr.write("Error: Can't find the file 'settings.py'
> in the directory containing %r.\nYou'll have to run django-profile.py,
> passing it your settings module.\n(If the file settings.py does indeed
> exist, it's causing an ImportError somehow.)\n" % __file__)

textwrap.dedent?

[Steven D'Aprano]

On Mon, 22 Oct 2012 07:22:18 +1100, Chris Angelico wrote:

> On Mon, Oct 22, 2012 at 6:11 AM, Steven D'Aprano
> <steve+comp....@pearwood.info> wrote:

>>> Ahh. I totally didn't see that, I'm way too used to reading past
>>> typos.
>>
>> As a programmer, doesn't that screw up your debugging ability?
>
> Reading-past-typos applies mainly to English, which is a pretty
> redundant language. In code, it would only apply to variable names; with
> (effectively) single words/tokens standing alone, the automatic
> correction doesn't really apply. But yes, sometimes I have stared at a
> piece of code for a long time without knowing why there's an error on
> line X. (This is another good reason to require that all variables be
> declared, incidentally. I might have a variable called "source" but not
> "souce", so using the other causes an instant compile-time failure on
> the exact line with the bug.)

"Another" good reason?

For languages without static types, what other reasons for declaring
variables are there?



--
Steven

[Chris Angelico]

The main one is scope nesting. Compare a few different languages.

Python: If you don't declare, it's global if you don't rebind it, but
local if you do. You may declare variables as global or nonlocal.

PHP: If you don't declare, it's local, but functions are in a separate scope.

C: If you don't declare, it's looked for in some broader scope. If
it's not declared in any scope, error.

All three approaches make reasonable sense. The PHP one is perfectly
consistent, but would be hopelessly impractical if all your function
names had to be marked off as globals. (Plus PHP has superglobals,
with their own Marvellous mess.) Python's system "just works" most of
the time, but can introduce yet another trap for the unsuspecting
newbie who doesn't understand the difference between rebinding and
mutating; I've not looked into multiple levels of closures but I
suspect there'll be odd limitations there, as there's only one
"nonlocal" keyword. The C style has administrative overhead (requiring
explicit declarations for all variables), but allows full flexibility
(variables having narrower scope than entire functions, infinite
nesting of scopes, etc).

Incidentally, variable declarations don't have to be connected with
static typing. JavaScript/ECMAScript simply has 'var x;' to declare
that x exists in this function. But it's hardly a language that I'd
hold up as a shining example; a var declaration anywhere in a function
makes that variable name local to that entire function. There's
actually no block scoping at all. And then there's the whole confusion
of the global object, 'this', and 'with' statements...

You knew I was going to cite it sooner or later :) Pike has true block
scoping, though unlike C++, Pike does not guarantee that destructors
will be called immediately at the close brace (but zero-reference
objects will be cleaned up, including destructor calls, at the next
function return - even if not the current function). Variables can be
mostly-statically-typed, or can be declared as 'mixed' and be rebound
freely (like in JS and Python). So scoped variable declarations and
static typing are quite orthogonal.

ChrisA

[Roy Smith]

In article <5084e819$0$29897$c3e8da3$5496...@news.astraweb.com>,

Variable declarations serve two purposes. One is to declare the type
(which obviously doesn't apply to Python). The other is to declare the
beginning of a scope.

On occasion, I will make typos in variable names which a
scope-introduction declaration would have prevented. If the cost of
having to declare every variable would be justified by the rare bug it
would prevent, is another question.

Pet peeve of the day...

Why do you have to write:

global foo
foo = 4

when

global foo = 4

would have been so much easier?

[Prasad, Ramit]

Roy Smith wrote:
> Pet peeve of the day...
>
> Why do you have to write:
>
> global foo
> foo = 4
>
> when
>
> global foo = 4
>
> would have been so much easier?

To make it more annoying for people who use globals, duh. :)

Ramit Prasad

This email is confidential and subject to important disclaimers and
conditions including on offers for the purchase or sale of
securities, accuracy and completeness of information, viruses,
confidentiality, legal privilege, and legal entity disclaimers,
available at http://www.jpmorgan.com/pages/disclosures/email.

[Ian Kelly]

On Mon, Oct 22, 2012 at 1:03 AM, Chris Angelico <ros...@gmail.com> wrote:
> Python's system "just works" most of
> the time, but can introduce yet another trap for the unsuspecting
> newbie who doesn't understand the difference between rebinding and
> mutating; I've not looked into multiple levels of closures but I
> suspect there'll be odd limitations there, as there's only one
> "nonlocal" keyword.

On my wishlist for Python is a big, fat SyntaxError for any variable
that could be interpreted as either local or nonlocal and is not
explicitly declared as either. It would eliminate this sort of
confusion entirely and make code that shadows nonlocal variables much
more readable.

Ideally, the same thing would also be done for locals that shadow
globals, but I don't see how that could possibly be enforced at
compile time.

[Joshua Landau]

On 23/10/2012, Dennis Lee Bieber <wlf...@ix.netcom.com> wrote:
> On Mon, 22 Oct 2012 16:02:34 -0600, Ian Kelly <ian.g...@gmail.com>

> declaimed the following in gmane.comp.python.general:
>

>> On my wishlist for Python is a big, fat SyntaxError for any variable
>> that could be interpreted as either local or nonlocal and is not
>> explicitly declared as either. It would eliminate this sort of
>> confusion entirely and make code that shadows nonlocal variables much
>> more readable.
>>

> Which now makes code dependent upon changes to some imported modules
> if someone is foolish enough to use the
>
> from xyz import *
>
> notation...
>
> I'd be very displeased if working code with local names suddenly
> fails because some third-party package was updated.
>
> Yes, I prefer not to use the "from...*" notation, but how many
> tutorials (especially of GUI toolkits, with their dozens of constants)
> illustrate using the wildcard?

I'm not particularly fond (or disliking) of the proposal, but we
already make changes to the structure of locals/globals and so forth
when someone does "from <something> import *". Disabling checks when
it is used is totally reasonable.

Additionally, "SyntaxError: import * only allowed at module level".
This means, as far as I grasp, one should never *manage* to create an
ambiguity here. Ian already stated this idea should (due to
neccessity) be disabled for possible globals.

[Ian Kelly]

On Mon, Oct 22, 2012 at 7:39 PM, Dennis Lee Bieber

<wlf...@ix.netcom.com> wrote:
> On Mon, 22 Oct 2012 16:02:34 -0600, Ian Kelly <ian.g...@gmail.com>
> declaimed the following in gmane.comp.python.general:
>
>> On my wishlist for Python is a big, fat SyntaxError for any variable
>> that could be interpreted as either local or nonlocal and is not
>> explicitly declared as either. It would eliminate this sort of
>> confusion entirely and make code that shadows nonlocal variables much
>> more readable.
>>
> Which now makes code dependent upon changes to some imported modules
> if someone is foolish enough to use the
>
> from xyz import *
>
> notation...

It's already a SyntaxError to use a wildcard import anywhere other
than the module level, so its use can only affect global variables.

[Steven D'Aprano]

On Tue, 23 Oct 2012 10:50:11 -0600, Ian Kelly wrote:

>> if someone is foolish enough to use the
>>
>> from xyz import *
>>
>> notation...
>
> It's already a SyntaxError to use a wildcard import anywhere other than
> the module level, so its use can only affect global variables.

In Python 3.x.

In Python 2.x, which includes the most recent version of three of the
four "big implementations" (PyPy, Jython, IronPython) it is still legal,
at least in theory.

I haven't tested PyPy, but IronPython 2.6 allows wildcard imports inside
functions without even a warning. Bizarrely, Jython 2.5 *appears* to
allow them with only a warning, but they don't take:

steve@runes:~$ jython
Jython 2.5.1+ (Release_2_5_1, Aug 4 2010, 07:18:19)
[OpenJDK Client VM (Sun Microsystems Inc.)] on java1.6.0_18
Type "help", "copyright", "credits" or "license" for more information.
>>> def test():
... from math import *
... return cos
...
<stdin>:2: SyntaxWarning: import * only allowed at module level
>>> test()
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
File "<stdin>", line 3, in test
NameError: global name 'cos' is not defined


So, legal or not, they're definitely something you want to avoid.


--
Steven

[Ian Kelly]

On Tue, Oct 23, 2012 at 4:34 PM, Steven D'Aprano
<steve+comp....@pearwood.info> wrote:
> On Tue, 23 Oct 2012 10:50:11 -0600, Ian Kelly wrote:
>
>>> if someone is foolish enough to use the
>>>
>>> from xyz import *
>>>
>>> notation...
>>
>> It's already a SyntaxError to use a wildcard import anywhere other than
>> the module level, so its use can only affect global variables.
>
> In Python 3.x.
>
> In Python 2.x, which includes the most recent version of three of the
> four "big implementations" (PyPy, Jython, IronPython) it is still legal,
> at least in theory.

If we're talking about making changes to the language, then we're
clearly talking about Python 3.x and beyond. There are no more major
releases planned for 2.x.

[Steven D'Aprano]

In what way does "it is ALREADY a SyntaxError" [emphasis added] refer to
making future changes to the language? :)

My point is that for probably 80% or more of Python users, it is not the
case that wildcard imports in functions are already a syntax error.
Anyone using CPython 2.x, PyPy, Jython or IronPython have such a syntax
error to look forward to in the future, but not now. Until then, they
have to deal with syntax warnings, implementation-dependent behaviour,
and as far as I can see, an outright language bug in Jython, but no
syntax errors.


--
Steven