Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.python > #31593 > unrolled thread

A desperate lunge for on-topic-ness

Back to article view | Back to comp.lang.python

Contents

  A desperate lunge for on-topic-ness Zero Piraeus <schesis@gmail.com> - 2012-10-18 02:06 -0400
    Re: A desperate lunge for on-topic-ness Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2012-10-18 06:31 +0000
      Re: A desperate lunge for on-topic-ness Hans Mulder <hansmu@xs4all.nl> - 2012-10-18 11:07 +0200
        Re: A desperate lunge for on-topic-ness wxjmfauth@gmail.com - 2012-10-18 02:33 -0700
          Re: A desperate lunge for on-topic-ness Tim Chase <python.list@tim.thechases.com> - 2012-10-18 06:05 -0500
        Re: A desperate lunge for on-topic-ness Chris Angelico <rosuav@gmail.com> - 2012-10-18 21:01 +1100
        RE: A desperate lunge for on-topic-ness "Prasad, Ramit" <ramit.prasad@jpmorgan.com> - 2012-10-18 18:42 +0000
        Re: A desperate lunge for on-topic-ness Ben Finney <ben+python@benfinney.id.au> - 2012-10-19 11:33 +1100
          Re: A desperate lunge for on-topic-ness rusi <rustompmody@gmail.com> - 2012-10-18 20:35 -0700
            Re: A desperate lunge for on-topic-ness Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2012-10-19 04:08 +0000
      Re: A desperate lunge for on-topic-ness Zero Piraeus <schesis@gmail.com> - 2012-10-18 06:31 -0400
    Re: A desperate lunge for on-topic-ness rusi <rustompmody@gmail.com> - 2012-10-17 23:55 -0700
    Re: A desperate lunge for on-topic-ness Paul Rubin <no.email@nospam.invalid> - 2012-10-17 23:56 -0700
    Re: A desperate lunge for on-topic-ness Grant Edwards <invalid@invalid.invalid> - 2012-10-18 13:16 +0000
      Re: A desperate lunge for on-topic-ness Ben Finney <ben+python@benfinney.id.au> - 2012-10-19 11:39 +1100
    Re: A desperate lunge for on-topic-ness Den <patentsvnc@gmail.com> - 2012-10-18 08:55 -0700
      Re: A desperate lunge for on-topic-ness Neil Cerutti <neilc@norwich.edu> - 2012-10-18 16:13 +0000
        Re: A desperate lunge for on-topic-ness Chris Angelico <rosuav@gmail.com> - 2012-10-19 03:21 +1100
        RE: A desperate lunge for on-topic-ness "Prasad, Ramit" <ramit.prasad@jpmorgan.com> - 2012-10-18 18:51 +0000
      RE: A desperate lunge for on-topic-ness "Prasad, Ramit" <ramit.prasad@jpmorgan.com> - 2012-10-18 18:50 +0000
      Re: A desperate lunge for on-topic-ness Zero Piraeus <schesis@gmail.com> - 2012-10-18 17:36 -0400
        Re: A desperate lunge for on-topic-ness Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2012-10-19 01:50 +0000
    Re: A desperate lunge for on-topic-ness Den <patentsvnc@gmail.com> - 2012-10-18 08:55 -0700
      Re: A desperate lunge for on-topic-ness Grant Edwards <invalid@invalid.invalid> - 2012-10-18 17:44 +0000
        Re: A desperate lunge for on-topic-ness Gene Heskett <gheskett@wdtv.com> - 2012-10-18 18:53 -0400
    Re: A desperate lunge for on-topic-ness Krzysztof Voss <shobbo@gmail.com> - 2012-10-19 15:16 -0700
    Re: A desperate lunge for on-topic-ness Krzysztof Voss <shobbo@gmail.com> - 2012-10-19 15:16 -0700

Page 1 of 2  [1] 2  Next page →

#31593 — A desperate lunge for on-topic-ness

:

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.

[toc] | [next] | [standalone]

#31597

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

[toc] | [prev] | [next] | [standalone]

#31611

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

[toc] | [prev] | [next] | [standalone]

#31616

Le jeudi 18 octobre 2012 11:07:25 UTC+2, Hans Mulder a écrit :
> 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

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

[toc] | [prev] | [next] | [standalone]

#31627

On 10/18/12 04:33, wxjmfauth@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 :-)

[toc] | [prev] | [next] | [standalone]

#31619

On Thu, Oct 18, 2012 at 8:07 PM, Hans Mulder <hansmu@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

[toc] | [prev] | [next] | [standalone]

#31678

Hans Mulder wrote:
> 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?
> 

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)


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.  

[toc] | [prev] | [next] | [standalone]

#31697

Hans Mulder <hansmu@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

[toc] | [prev] | [next] | [standalone]

#31710

>  \       “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

[toc] | [prev] | [next] | [standalone]

#31712

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

[toc] | [prev] | [next] | [standalone]

#31626

:

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.lang.python@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,  <wxjmfauth@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.

[toc] | [prev] | [next] | [standalone]

#31601

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.

[toc] | [prev] | [next] | [standalone]

#31602

Zero Piraeus <schesis@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.

[toc] | [prev] | [next] | [standalone]

#31634

On 2012-10-18, Zero Piraeus <schesis@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            

[toc] | [prev] | [next] | [standalone]

#31698

Jean-Michel Pichavant <jeanmichel@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

[toc] | [prev] | [next] | [standalone]

#31654

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

[toc] | [prev] | [next] | [standalone]

#31660

On 2012-10-18, Den <patentsvnc@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

[toc] | [prev] | [next] | [standalone]

#31663

On Fri, Oct 19, 2012 at 3:13 AM, Neil Cerutti <neilc@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

[toc] | [prev] | [next] | [standalone]

#31675

Chris Angelico wrote: 
> On Fri, Oct 19, 2012 at 3:13 AM, Neil Cerutti <neilc@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.


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.  

[toc] | [prev] | [next] | [standalone]

#31674

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

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.  

[toc] | [prev] | [next] | [standalone]

Page 1 of 2  [1] 2  Next page →

Back to top | Article view | comp.lang.python

csiph-web