Re: PEP 8 : Maximum line Length :

2014-05-17 Thread Albert van der Horst
In article mailman.10041.1400164039.18130.python-l...@python.org,
Chris Angelico  ros...@gmail.com wrote:
On Fri, May 16, 2014 at 12:17 AM,  wxjmfa...@gmail.com wrote:
 One another trick is to drop spaces around keywords

 9and 12345or 99if 'a'in'a' else or 77
 12345

 and pray, the tools from those who are wasting their time in
 writing code analyzers or syntax colorizers or doc strings
 collectors or ... are finally working. Depending of the tools
 the interpretation may vary, but definitely all are producing
 erroneous results.

Yes. Another very effective way to get your code below 80 characters
is to shorten all names to a single letter. Since you don't need to
restrict yourself to monocase Roman letters (as I had to in my
earliest programming days, in BASIC), it's actually quite practical to
uniquely name everything in a single character; you could save
enormous amounts of horizontal space. Then, aggressively import as
to do the same with remote symbols (you might need two characters for
those), and you'll be able to write everything in just a few tight
symbols!

That may be tong-in-cheek but mathematicians do exactly that. We
use roman, greek and hebrew alphabets in normal italics and boldface
and then some special characters for element-of, logical-or, integral signs,
triangles and what not. Underbarred and upper twiggled, as a suffix a prefix
or a superfix. All in the name of avoiding names longer than one character.

When we run out then there are creative ways to combine known characters
into Jacobi symbols and choose functions.

There are even conventions that allow to leave out characters, like
juxtaposition means multiplication and the Einstein summation convention.

You have to invest but terseness pays off.

Now translate E=mc^2 into Java.


ChrisA
-- 
Albert van der Horst, UTRECHT,THE NETHERLANDS
Economic growth -- being exponential -- ultimately falters.
albert@spearc.xs4all.nl =n http://home.hccnet.nl/a.w.m.van.der.horst

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


Re: PEP 8 : Maximum line Length :

2014-05-17 Thread Chris Angelico
On Sat, May 17, 2014 at 10:52 PM, Albert van der Horst
alb...@spenarnc.xs4all.nl wrote:
 That may be tong-in-cheek but mathematicians do exactly that. We
 use roman, greek and hebrew alphabets in normal italics and boldface
 and then some special characters for element-of, logical-or, integral signs,
 triangles and what not. Underbarred and upper twiggled, as a suffix a prefix
 or a superfix. All in the name of avoiding names longer than one character.

 When we run out then there are creative ways to combine known characters
 into Jacobi symbols and choose functions.

 There are even conventions that allow to leave out characters, like
 juxtaposition means multiplication and the Einstein summation convention.

This, I think, is the main reason for the one-character variable name
convention. Why else are there subscripts? Instead of using V0
(two-character name), you use V₀ (one-character name with a
subscript tag on it) to avoid collision with multiplication.

 Now translate E=mc^2 into Java.

Dunno, but in Python it would be:

assert E==m*c*c

And would probably fail, because that's all floating point :)

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


Re: PEP 8 : Maximum line Length :

2014-05-17 Thread Tim Chase
On 2014-05-17 12:52, Albert van der Horst wrote:
 Now translate E=mc^2 into Java.

I suspect it would be something like

public class Einstein  {
  private double mass=0, energy=0;
  public class Relativity implements IEquation {
Relativity(double mass) {
  set_mass(mass);
}
public double getEnergy() {return energy;}
public double setEnergy(double newEnergy) {
  energy = newEnergy;
  mass = newEnergy / (units.SPEED_OF_LIGHT * units.SPEED_OF_LIGHT);
}
public double get_mass() {return mass;}
public double setMass(double newMass) {
  mass = newMass;
  energy = newMass * (units.SPEED_OF_LIGHT * units.SPEED_OF_LIGHT);
}
  }
  
  public static void main(String[] args) {
Relativity relativity = new Relativity(
  Integer.parseInt(args[1])
  );
System.out.println(relativity.getEnergy())
  }
}


(untested, as it has been a long time since I've touched any Java code)

-tkc





signature.asc
Description: PGP signature
-- 
https://mail.python.org/mailman/listinfo/python-list


Re: PEP 8 : Maximum line Length :

2014-05-17 Thread Roy Smith
In article mailman.10085.140038.18130.python-l...@python.org,
 Tim Chase python.l...@tim.thechases.com wrote:

 On 2014-05-17 12:52, Albert van der Horst wrote:
  Now translate E=mc^2 into Java.
 
 I suspect it would be something like
 
 public class Einstein  {
   private double mass=0, energy=0;
   public class Relativity implements IEquation {
 Relativity(double mass) {
   set_mass(mass);
 }
 public double getEnergy() {return energy;}
 public double setEnergy(double newEnergy) {
   energy = newEnergy;
   mass = newEnergy / (units.SPEED_OF_LIGHT * units.SPEED_OF_LIGHT);
 }
 public double get_mass() {return mass;}
 public double setMass(double newMass) {
   mass = newMass;
   energy = newMass * (units.SPEED_OF_LIGHT * units.SPEED_OF_LIGHT);
 }
   }
   
   public static void main(String[] args) {
 Relativity relativity = new Relativity(
   Integer.parseInt(args[1])
   );
 System.out.println(relativity.getEnergy())
   }
 }
 
 
 (untested, as it has been a long time since I've touched any Java code)
 
 -tkc

Not good enough.  Einstein should really be a singleton, so you need 
something like an AbstractScientistFactory, which implements Singleton.  
And you really should be importing 
SPEED_OF_LIGHT_IN_VACUUM_METERS_PER_SECOND from 
org.universe.physics.constants.  And you need to declare that 
Einstein.getEnergy() raises NumericValueOutOfBoundsError if mass is 
negative (and FlatEarthError if the code is run in certain states south 
of the Mason-Dixie line).
-- 
https://mail.python.org/mailman/listinfo/python-list


Re: PEP 8 : Maximum line Length :

2014-05-17 Thread Roy Smith
In article mailman.10083.1400332708.18130.python-l...@python.org,
 Chris Angelico ros...@gmail.com wrote:

 On Sat, May 17, 2014 at 10:52 PM, Albert van der Horst
 alb...@spenarnc.xs4all.nl wrote:
  That may be tong-in-cheek but mathematicians do exactly that. We
  use roman, greek and hebrew alphabets in normal italics and boldface
  and then some special characters for element-of, logical-or, integral signs,
  triangles and what not. Underbarred and upper twiggled, as a suffix a prefix
  or a superfix. All in the name of avoiding names longer than one character.
 
  When we run out then there are creative ways to combine known characters
  into Jacobi symbols and choose functions.
 
  There are even conventions that allow to leave out characters, like
  juxtaposition means multiplication and the Einstein summation convention.
 
 This, I think, is the main reason for the one-character variable name
 convention. Why else are there subscripts? Instead of using V0
 (two-character name), you use V? (one-character name with a
 subscript tag on it) to avoid collision with multiplication.
 
  Now translate E=mc^2 into Java.
 
 Dunno, but in Python it would be:
 
 assert E==m*c*c
 
 And would probably fail, because that's all floating point :)
 
 ChrisA

Nah.  Python has relativistic duck typing:

 c = 186000
 m = 100
 E = 34596L
 assert E==m*c*c

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


Re: PEP 8 : Maximum line Length :

2014-05-17 Thread Mark Lawrence

On 17/05/2014 13:52, Albert van der Horst wrote:


Now translate E=mc^2 into Java.



I can't do that as I simply don't understand it.  What has the 
Marylebone Cricket Club got to do with E?


--
My fellow Pythonistas, ask not what our language can do for you, ask 
what you can do for our language.


Mark Lawrence

---
This email is free from viruses and malware because avast! Antivirus protection 
is active.
http://www.avast.com


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


Re: PEP 8 : Maximum line Length :

2014-05-17 Thread Roy Smith
In article mailman.10088.1400335366.18130.python-l...@python.org,
 Mark Lawrence breamore...@yahoo.co.uk wrote:

 On 17/05/2014 13:52, Albert van der Horst wrote:
 
  Now translate E=mc^2 into Java.
 
 
 I can't do that as I simply don't understand it.  What has the 
 Marylebone Cricket Club got to do with E?

A wicket looks like an E on its side.  Does that help?
-- 
https://mail.python.org/mailman/listinfo/python-list


Re: PEP 8 : Maximum line Length :

2014-05-17 Thread Mark Lawrence

On 17/05/2014 15:06, Roy Smith wrote:

In article mailman.10088.1400335366.18130.python-l...@python.org,
  Mark Lawrence breamore...@yahoo.co.uk wrote:


On 17/05/2014 13:52, Albert van der Horst wrote:


Now translate E=mc^2 into Java.



I can't do that as I simply don't understand it.  What has the
Marylebone Cricket Club got to do with E?


A wicket looks like an E on its side.  Does that help?



Ah, now I get it, thanks for that :)

--
My fellow Pythonistas, ask not what our language can do for you, ask 
what you can do for our language.


Mark Lawrence

---
This email is free from viruses and malware because avast! Antivirus protection 
is active.
http://www.avast.com


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


Re: PEP 8 : Maximum line Length :

2014-05-17 Thread Rustom Mody
On Saturday, May 17, 2014 7:36:19 PM UTC+5:30, Roy Smith wrote:
 
  Mark Lawrence  wrote:
   Now translate E=mc^2 into Java.
  
  
  I can't do that as I simply don't understand it.  What has the 
  Marylebone Cricket Club got to do with E?
 
 A wicket looks like an E on its side.  Does that help?

Heh! Imaginative!

Now spend your life meditating on all the glyphs that inhabit unicode.
And mon cher u-no-hoo will award you with an epiphany.
-- 
https://mail.python.org/mailman/listinfo/python-list


Re: PEP 8 : Maximum line Length :

2014-05-16 Thread Ben Finney
Rustom Mody rustompm...@gmail.com writes:

 You said this:

  The 80 character line limit is *not* driven by a limitation of
  computer technology; it is driven by a limitation of human
  cognition. For that reason, it remains relevant until human
  cognition in the general reading population improves.

 And you answered:

  Until then may we relegate '79' to quaint historical
  curiosities...??

 with

  Not until the general capacity of human cognition advances to make
  longer lines easier to read.

Indeed. Once again: Human cognition has limits, including limits on
reading speed and reading comprehension as the length of a line of text
increases beyond a threshold.

You have caricatured that as some kind of statement that every human has
a fundamental 79-column limit, which no-one has claimed.

If you can't see the difference between what I and others have been
saying about limits on human cognition, versus your caricature, then I
can only leave you to re-read until you do understand. And I'll thank
you not to straw-man people's positions.

-- 
 \ “Dyslexia means never having to say that you're ysror.” |
  `\—anonymous |
_o__)  |
Ben Finney

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


Re: PEP 8 : Maximum line Length :

2014-05-16 Thread Steven D'Aprano
On Thu, 15 May 2014 17:12:57 +0300, Marko Rauhamaa wrote:

 A definitive Python source file could be binary, XML, .py, .ast,
 whatever, 

Containing *what*? You can't just wave your hands and say binary. What 
sort of binary file? Perhaps a JPEG file, where red triangles of 
different sizes represent keywords. Variable names can be encoded using a 
pattern of purple dots. Expressions and blocks of code can be formed by 
joining components with lines. Operators by squares of different colours 
(green means +, blue means -, etc.).

No? Then what?

Besides, where does the information inside the file come from? You surely 
don't expect people to write the binary data/AST/whatever directly. How 
can the zip file be definitive when it is derived from something more 
fundamental?

Source code is, *by definition*, the definitive version. (It's the 
SOURCE, see?) Zipping the source code just means that the *source* inside 
the zip file is the definitive version, not the compressed binary data.

The AST is not definitive. Human beings write *text*, which is what the 
source code is. It may be text with an especially restrictive grammar, 
but it's still text. Everything else -- the parse tree, the abstract 
syntax tree, the byte code, the machine code, the compressed text, 
encrypted text, the pixel rendering of the text, ... are derived from the 
code as written by human beings.

Code is written primarily for human beings. Many programmers, and many 
language designers, don't realise this, which is why so many programs are 
write-only code. Presentation *is important*, and cannot always be 
separated from semantics without hurting the primary audience, the human 
reader. This is what code obfuscators do, deliberately: mangle the 
presentation while keeping the semantics the same. You're inadvertently 
proposing the same thing (albeit to a lesser degree).



-- 
Steven D'Aprano
http://import-that.dreamwidth.org/
-- 
https://mail.python.org/mailman/listinfo/python-list


Re: PEP 8 : Maximum line Length :

2014-05-16 Thread Ben Finney
Steven D'Aprano steve+comp.lang.pyt...@pearwood.info writes:

 Source code is, *by definition*, the definitive version. (It's the
 SOURCE, see?) Zipping the source code just means that the *source*
 inside the zip file is the definitive version, not the compressed
 binary data.

I find the Free Software Foundation has a good, clear definition of
“source” for programs:

The source code for a work means the preferred form of the work
for making modifications to it.

(GNU General Public License, version 3 §1).

There is ambiguity there, but it's exactly where it needs to be:
focussing the discussion on what form of the work is preferred for
making modofications to it.

A byte stream is only source *with respect to some work*, and is only
the source of *that* work if it is the preferred form of that work for
making modifications to that work.

This neatly cuts of at the knees a whole mob of futile speculative
distractions about “who is to say whether one person might consider this
byte stream to be source”.

To hell with all that. We're interested in making modifications to a
work, and we reach for some form of the work to do so: *that* form is
the source for the work.

 The AST is not definitive. Human beings write *text*, which is what
 the source code is.

And if it's not text in some outlying cases, then it will only be
because some *other* form of the work which is preferred by actual human
programmers for making modifications to the work.

 Code is written primarily for human beings. Many programmers, and many
 language designers, don't realise this, which is why so many programs
 are write-only code. Presentation *is important*, and cannot always be
 separated from semantics without hurting the primary audience, the
 human reader. This is what code obfuscators do, deliberately: mangle
 the presentation while keeping the semantics the same. You're
 inadvertently proposing the same thing (albeit to a lesser degree).

Yes. And this is why obfuscated code, though it may be interpreted
without difficulty by the same compiler algorithm, still does not
constitute the source for the program.

-- 
 \  “Any intelligent fool can make things bigger and more complex… |
  `\It takes a touch of genius – and a lot of courage – to move in |
_o__)the opposite direction.” —Albert Einstein |
Ben Finney

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


Re: PEP 8 : Maximum line Length :

2014-05-16 Thread Marko Rauhamaa
Steven D'Aprano steve+comp.lang.pyt...@pearwood.info:

 On Thu, 15 May 2014 17:12:57 +0300, Marko Rauhamaa wrote:

 A definitive Python source file could be binary, XML, .py, .ast,
 whatever, 

 Containing *what*? You can't just wave your hands and say binary.

I sure can and am.

 Besides, where does the information inside the file come from?

The file would a canonical serialization of the AST. The information
would come from an editor (say, emacs) that displays the AST as
two-dimensional text according to your preferences.

Analogy: How do you edit a .png file? With an editor (say, gimp).
Programming languages could work the same way.

 Source code is, *by definition*, the definitive version.

The AST file would be the source code, only it wouldn't have line
numbers or columns. Maybe it could even leave out
capitalization/camel-casing so the editor can display the variable,
function and class names according to your preferences.

 The AST is not definitive. Human beings write *text*, which is what the 
 source code is.

You are stuck to the status quo. I'm proposing the AST should be the
definitive source and the human beings would express AST through the
editor. Yes, it would probably be text, at least partly, but for example
the AST wouldn't specify the order of the function or class definitions.

 This is what code obfuscators do, deliberately: mangle the
 presentation while keeping the semantics the same. You're
 inadvertently proposing the same thing (albeit to a lesser degree).

At least, we could stop debating silly surface presentation issues
(indentation, line width, spacing around operators...).

Well, actually, any .py file *does* specify a unique AST. Nothing would
prevent the text editor from presenting it according to your
preferences. They all do that to a degree anyway (colors, fonts), but
they could take even more liberties (which some IDE's do: hiding/showing
comments and function definitions).

There are tools that reindent and refactor code automatically. The text
editor could do that on the fly.


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


Re: PEP 8 : Maximum line Length :

2014-05-16 Thread Steven D'Aprano
On Thu, 15 May 2014 17:06:13 -0700, Rustom Mody wrote:

 The claim being made is that 79/80 is a fundamental, cognitive limit and
 has no relation to technological changes.

I don't believe anyone has made that claim. You are reading a statement 
about general (typical, average) behaviour, and turning it into an absurd 
statement of a fundamental (your word) which applies to every single 
human being on earth.




-- 
Steven D'Aprano
http://import-that.dreamwidth.org/
-- 
https://mail.python.org/mailman/listinfo/python-list


Re: PEP 8 : Maximum line Length :

2014-05-16 Thread Chris Angelico
On Fri, May 16, 2014 at 4:25 PM, Steven D'Aprano
steve+comp.lang.pyt...@pearwood.info wrote:
 Containing *what*? You can't just wave your hands and say binary. What
 sort of binary file? Perhaps a JPEG file, where red triangles of
 different sizes represent keywords. Variable names can be encoded using a
 pattern of purple dots. Expressions and blocks of code can be formed by
 joining components with lines. Operators by squares of different colours
 (green means +, blue means -, etc.).

http://www.dangermouse.net/esoteric/piet.html

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


Re: PEP 8 : Maximum line Length :

2014-05-16 Thread Chris Angelico
On Fri, May 16, 2014 at 5:00 PM, Marko Rauhamaa ma...@pacujo.net wrote:
 Well, actually, any .py file *does* specify a unique AST. Nothing would
 prevent the text editor from presenting it according to your
 preferences. They all do that to a degree anyway (colors, fonts), but
 they could take even more liberties (which some IDE's do: hiding/showing
 comments and function definitions).

 There are tools that reindent and refactor code automatically. The text
 editor could do that on the fly.

You still haven't answered my biggest objection from earlier. Source
code contains more information than the AST does; even if you make a
frAnkenSTein's monster that includes comments, there's still the point
that whitespace carries information, and that information is
frequently communicative of the programmer's intent. Any automated
reformatter destroys that information, and that is, by definition, a
net loss to the code. How do you propose to fix that? Or if not, will
you at least acknowledge that the AST cannot perfectly transmit what
the source code says?

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


Re: PEP 8 : Maximum line Length :

2014-05-16 Thread Marko Rauhamaa
Chris Angelico ros...@gmail.com:

 You still haven't answered my biggest objection from earlier. Source
 code contains more information than the AST does; even if you make a
 frAnkenSTein's monster that includes comments, there's still the point
 that whitespace carries information, and that information is
 frequently communicative of the programmer's intent. Any automated
 reformatter destroys that information, and that is, by definition, a
 net loss to the code. How do you propose to fix that? Or if not, will
 you at least acknowledge that the AST cannot perfectly transmit what
 the source code says?

If every bit of your Python text conveys information, obviously, it
can't be abstracted. I don't believe that to be the case, though. So
this AST should contain all *actual* information worth conveying and
strip away irrelevant stuff.

Examples:

 * Function definition order.

 * Indentation depth.

 * Vertical empty space.


Of course, I'm not being completely serious about all this stuff because
the surface coding style questions are among the least relevant problems
in the code. But at least that kind of arrangement would free us from
the heated debates concerning the maximum line length etc.

(BTW, regardless of PEP8, the maximum line length *must* be 79, and the
maximum function length *must* be whatever can be seen on the screen at
once.)


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


Re: PEP 8 : Maximum line Length :

2014-05-16 Thread Chris Angelico
On Fri, May 16, 2014 at 7:18 PM, Marko Rauhamaa ma...@pacujo.net wrote:
 If every bit of your Python text conveys information, obviously, it
 can't be abstracted. I don't believe that to be the case, though. So
 this AST should contain all *actual* information worth conveying and
 strip away irrelevant stuff.

 Examples:

  * Function definition order.

  * Indentation depth.

  * Vertical empty space.

* Logical layout as expressed by whitespace and specific line breaks.

Compare these two assignment statements:

area = (base*base + extension*extension
+ annex*annex + (annex-extension)*annex
+ triangle*triangle/2
+ circle*circle*math.PI + sphere*sphere*4*math.PI)

area = (base*base + extension*extension + annex*annex
+ (annex-extension)*annex + triangle*triangle/2
+ circle*circle*math.PI + sphere*sphere*4*math.PI)

Both are wrapped to sixty characters, which means they can be indented
twenty without breaking PEP 8. One of them takes up only three lines,
the other takes up four. But the first one groups the annex's terms,
separates out the triangle, groups the circular elements, and
presumably corresponds accurately to the (mythical) real-world
geometry that it's implementing. How are you going to cope with this
distinction? That's real, useful information, which the AST doesn't
carry.

(You might argue that each of these lines should have a comment at the
end of it or above it, which would provide that grouping. But in that
case, you lose the canonicalization of anything with trailing comments
or interspersed comments, meaning that you effectively can't reformat
anything with comments in it.)

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


Re: PEP 8 : Maximum line Length :

2014-05-16 Thread Marko Rauhamaa
Chris Angelico ros...@gmail.com:

 Compare these two assignment statements:

 area = (base*base + extension*extension
 + annex*annex + (annex-extension)*annex
 + triangle*triangle/2
 + circle*circle*math.PI + sphere*sphere*4*math.PI)

 area = (base*base + extension*extension + annex*annex
 + (annex-extension)*annex + triangle*triangle/2
 + circle*circle*math.PI + sphere*sphere*4*math.PI)

 [...]
 How are you going to cope with this distinction? That's real, useful
 information, which the AST doesn't carry.

Such nuances would be lost, yes. However, the nuances are constantly
abused and misinterpreted anyway.


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


Re: PEP 8 : Maximum line Length :

2014-05-15 Thread Dave Angel

On 05/14/2014 10:12 PM, Roy Smith wrote:

In article mailman.10026.1400116640.18130.python-l...@python.org,
  Mark Lawrence breamore...@yahoo.co.uk wrote:


I still remember the cry of anguish when the guy in the computer
building at (the then) Portsmouth Polytechnic dropped his cardboard box
of punch cards that made up his end of course project.


That's why you punch sequence numbers in columns 73-80.  If the cards
get out of order, just run the deck through the sorter.



And of course, don't forget to increment them by 10's, so you can insert 
new cards without resequencing the remainder.


I recall having to buy two tapes, because the operators were very 
resistant to taking several boxes of cards at one shot.  (A box was 2000 
cards) At that point, the card decks were instructions to the editor, 
how to turn the version of the code on tape1 into the new version, to be 
written to tape2.  (And on every run, don't forget to reverse the lines 
describing which tape is tape1 and which is tape2.)


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


Re: PEP 8 : Maximum line Length :

2014-05-15 Thread Johannes Bauer
On 15.05.2014 04:43, Ben Finney wrote:
 Rustom Mody rustompm...@gmail.com writes:
 
 Until then may we relegate '79' to quaint historical curiosities
 
 Not until the general capacity of human cognition advances to make
 longer lines easier to read.

I find it surprising how you can make such a claim about the whole of
humanity (!) without even feeling the need to have a pro forma study to
back it up. Also, not everything that applies to prose also equally
applies to code.

Personally I find overly narrow code (80 cols) to be much *harder* to
read than code that is 100 cols wide. Keep in mind that even if the
break is at 100 cols, lines will rarely exceed that limit. And if they
do to *understand* the code, the further down the line it is the less
important are the details usually.

I don't know why anyone would force a display issue onto everyone. It
imples the arrogant stance that every human being has the exact way of
reading and writing code. Everyone can configure her editor to what she
wants (including line breaks and such).

If people were to force pixel sizes of editor fonts, everyone would
immediately recognize what a stupid idea this would be. Even though I
could claim that the vertical formatting is all messed up when you don't
display my code with the correct font size! Ridiculous, right?

Regards,
Johannes


-- 
 Wo hattest Du das Beben nochmal GENAU vorhergesagt?
 Zumindest nicht öffentlich!
Ah, der neueste und bis heute genialste Streich unsere großen
Kosmologen: Die Geheim-Vorhersage.
 - Karl Kaos über Rüdiger Thomas in dsa hidbv3$om2$1...@speranza.aioe.org
-- 
https://mail.python.org/mailman/listinfo/python-list


Re: PEP 8 : Maximum line Length :

2014-05-15 Thread Marko Rauhamaa
Johannes Bauer dfnsonfsdu...@gmx.de:

 I don't know why anyone would force a display issue onto everyone.

Well, if I have to work with your code, you are forcing your style on
me.

 It imples the arrogant stance that every human being has the exact way
 of reading and writing code. Everyone can configure her editor to what
 she wants (including line breaks and such).

That's a good point: why aren't we just exchanging AST's and configuring
the editor to display them in our preferred format?

Well, we're not there yet.

Objective readability is not the main issue here, IMO. It's the screen
estate. I know the idea of windows is fast disappearing from modern
(mobile) computing; you have apps instead that commandeer the whole
screen. Personally, I find that a big step backwards. I want to be able
to subdivide the screen for many windows that represent different
contexts and tasks.


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


Re: PEP 8 : Maximum line Length :

2014-05-15 Thread Chris Angelico
On Thu, May 15, 2014 at 10:32 PM, Johannes Bauer dfnsonfsdu...@gmx.de wrote:
 Personally I find overly narrow code (80 cols) to be much *harder* to
 read than code that is 100 cols wide. Keep in mind that even if the
 break is at 100 cols, lines will rarely exceed that limit. And if they
 do to *understand* the code, the further down the line it is the less
 important are the details usually.

The limit of human readability is generally given to be somewhere in
the range of 60-120. It's not a single specific value that's exactly
the same for everyone; personally, I like my lines of code to be a bit
longer than 80, and will happily go to 90-100, but in the interests of
interoperability, it's helpful to standardize on one common value -
especially for large shared codebases.

You're arguing against the specific value of 80, but 100 is still
pretty close to that. There are two key boundaries: the point at which
your eye can no longer comfortably read the text, and the point at
which you need to scroll horizontally. The latter of course depends on
your screen, but it's an EXTREMELY important barrier; the former is
the soft boundary, as you won't instantly know when you're over it.
(The two can be in either order, of course. I could easily read 90
char lines, but if I'm in a standard 80x24-25 terminal window, that's
going to scroll.) Both boundaries are almost certainly exceeded by a
500-character line; if you're doing your code like that, you obviously
do not want anyone reading it. [1] Whether you cut it off at 70, 80,
100, or some other figure, you still want to put some kind of limit on
it.

ChrisA

[1] That doesn't mean never do this. I've sometimes had code with
insanely long lines - for instance, an auto-generated list of names -
and it wasn't meant to be human-readable. Breaking it onto multiple
lines would have complicated matters unnecessarily, and if you wanted
to read the code, you should be reading the other file anyway.
-- 
https://mail.python.org/mailman/listinfo/python-list


Re: PEP 8 : Maximum line Length :

2014-05-15 Thread Chris Angelico
On Thu, May 15, 2014 at 11:07 PM, Marko Rauhamaa ma...@pacujo.net wrote:
 I know the idea of windows is fast disappearing from modern
 (mobile) computing; you have apps instead that commandeer the whole
 screen. Personally, I find that a big step backwards. I want to be able
 to subdivide the screen for many windows that represent different
 contexts and tasks.

Duh! :)

I'm currently working on Sikorsky (all my computers have names, of
course), with six Xfce workspaces. On those, my text editor (SciTE)
and MUD client (Gypsum) are set to Always on visible workspace;
everything else is whereever I choose to put it (VMs on workspace 2,
most of my primary activity on workspace 3, Alice: Madness Returns on
workspace 6, etc). Each workspace is subdivided into approximately
five million terminal windows, because that's what I do everything
with :) One web browser window, or maybe two; occasional other stuff;
but mainly, lots and lots of terminals. I can't imagine trying to get
any serious work done without loading up multiple consoles, some of
them SSH'd to other boxes, and being able to copy and paste between
them.

The Windows 8 / Unity / GNOME 3 model annoys me greatly. Can't get
work done like that.

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


Re: PEP 8 : Maximum line Length :

2014-05-15 Thread alister
On Thu, 15 May 2014 23:31:44 +1000, Chris Angelico wrote:
 The Windows 8 / Unity / GNOME 3 model annoys me greatly. Can't get work
 done like that.
 
 ChrisA
Windows 8/ Unity/ Gnome 3 are great on tablets (at least they look like 
they should be the only one I can confirm is Win 8) but lousy on a full 
pc with keyboard (Mouse optional)

I am with you  use either LXDE or XFCE or run level 3 on all of my 
systems.





-- 
Q: What do you call 50 Microsoft products at the bottom of the ocean?
A: A darned good start. 
-- 
https://mail.python.org/mailman/listinfo/python-list


Re: PEP 8 : Maximum line Length :

2014-05-15 Thread Chris Angelico
On Thu, May 15, 2014 at 11:38 PM, alister
alister.nospam.w...@ntlworld.com wrote:
 On Thu, 15 May 2014 23:31:44 +1000, Chris Angelico wrote:
 The Windows 8 / Unity / GNOME 3 model annoys me greatly. Can't get work
 done like that.

 ChrisA
 Windows 8/ Unity/ Gnome 3 are great on tablets (at least they look like
 they should be the only one I can confirm is Win 8) but lousy on a full
 pc with keyboard (Mouse optional)

 I am with you  use either LXDE or XFCE or run level 3 on all of my
 systems.

Sorry, I should clarify that I'm talking about desktop systems here. I
have no idea how good those UIs are on actual tablets; my beef with
them is that putting a tablet UI on a desktop is just as much a bad
idea as putting a desktop UI on a tablet. When I have a 1920x1080
display on a screen that's about a meter wide, running a single
application is seldom what I want to do.

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


Re: PEP 8 : Maximum line Length :

2014-05-15 Thread Rustom Mody
On Thursday, May 15, 2014 6:37:54 PM UTC+5:30, Marko Rauhamaa wrote:
 Johannes Bauer :
 
 
  I don't know why anyone would force a display issue onto everyone.
 
 
 Well, if I have to work with your code, you are forcing your style on
 me.
 
 
  It imples the arrogant stance that every human being has the exact way
  of reading and writing code. Everyone can configure her editor to what
  she wants (including line breaks and such).
 
 
 That's a good point: why aren't we just exchanging AST's and configuring
 the editor to display them in our preferred format?
 
 Well, we're not there yet.

Yes, regarding programmers using plain-text instead of hypertext
at http://blog.languager.org/2012/10/html-is-why-mess-in-programming-syntax.html

I wrote:

And yet programmers continue to be decades behind all other users of computers. 
 We continue to use flat text for our programs when all others have moved on.
-- 
https://mail.python.org/mailman/listinfo/python-list


Re: PEP 8 : Maximum line Length :

2014-05-15 Thread Roy Smith
In article 78ac407a-c429-4a7a-93c9-5d83e0f09...@googlegroups.com,
 Rustom Mody rustompm...@gmail.com wrote:

 And yet programmers continue to be decades behind all other users of 
 computers.  We continue to use flat text for our programs when all others 
 have moved on.

It's not like we haven't tried.  There have been a few attempts at using 
richer media to program (graphical UML editors, for example).  They've 
all pretty much been failures.

There *are* some places where non-text programming has won.  The biggest 
example would be GUI builders.  Nobody programs screen and window 
layouts by typing textual descriptions.  They push boxes around in a GUI 
builder.
-- 
https://mail.python.org/mailman/listinfo/python-list


Re: PEP 8 : Maximum line Length :

2014-05-15 Thread Rustom Mody
On Thursday, May 15, 2014 6:57:26 PM UTC+5:30, Chris Angelico wrote:
 The limit of human readability is generally given to be somewhere in
 the range of 60-120. It's not a single specific value that's exactly
 the same for everyone; personally, I like my lines of code to be a bit
 longer than 80, and will happily go to 90-100, but in the interests of
 interoperability, it's helpful to standardize on one common value -
 especially for large shared codebases.
 
 You're arguing against the specific value of 80, but 100 is still
 pretty close to that. There are two key boundaries: the point at which
 your eye can no longer comfortably read the text, and the point at
 which you need to scroll horizontally. The latter of course depends on
 your screen, but it's an EXTREMELY important barrier; the former is
 the soft boundary, as you won't instantly know when you're over it.
 

Thanks Chris for some sanity

As far as I can see the votaries of the mystical 79 have yet to explain
how/where it appeared from

JFTR the OP asked how to shorten a line and the shortest so far is what I 
suggested
-- 
https://mail.python.org/mailman/listinfo/python-list


Re: PEP 8 : Maximum line Length :

2014-05-15 Thread Chris Angelico
On Thu, May 15, 2014 at 11:58 PM, Roy Smith r...@panix.com wrote:
 There *are* some places where non-text programming has won.  The biggest
 example would be GUI builders.  Nobody programs screen and window
 layouts by typing textual descriptions.  They push boxes around in a GUI
 builder.

Hi, I'm Nobody, and I like warm hugs!

My GUI building is entirely by typing textual descriptions. Yes, there
are some good builders, but I do my layouts on a basis of rules rather
than strict pixel positions. Rules and bag-based layouts mean there's
no problem with something getting too big and messing up your layout.

Is it really helpful to drag objects into a nearly-invisible Vertical
Box container? Pushing boxes around is great when you attach
everything directly to the window, but that gets messed up pretty
quickly by a user's themes, font sizes, etc (not to mention a change
of platform). Explicitly putting things into their boxes, grids,
tables, etc means it's always right.

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


Re: PEP 8 : Maximum line Length :

2014-05-15 Thread Marko Rauhamaa
Rustom Mody rustompm...@gmail.com:

 We continue to use flat text for our programs when all others have
 moved on.

My more moderate and immediate point is, why should the physical
encoding of the program be also the presentation format?

A definitive Python source file could be binary, XML, .py, .ast,
whatever, and that would also be the file fed to the Python
compiler/interpreter. However, your editor could choose freely how to
present it to you.

IOW, shouldn't PEP8 be redundant?


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


Re: PEP 8 : Maximum line Length :

2014-05-15 Thread Rustom Mody
On Thursday, May 15, 2014 7:28:01 PM UTC+5:30, Roy Smith wrote:
 
  Rustom Mody wrote:
 
 
 
  And yet programmers continue to be decades behind all other users of 
  computers.  We continue to use flat text for our programs when all others 
  have moved on.
 
 
 
 It's not like we haven't tried.  There have been a few attempts at using 
 richer media to program (graphical UML editors, for example).  They've 
 all pretty much been failures.
 

In Fifth Discipline, Peter Senge starts by dilating on the length of time 
between
1903 when the Wright brothers first flew and 1935 when the DC-3 ushered in 
commercial air travel.

Five things were needed for that transition from pioneering to commercial:

| They were: the variable-pitch propeller, retractable landing gear, a type of 
| lightweight molded body construction called monocque, radial air-cooled 
| engine, and wing flaps. To succeed, the DC-3 needed all five; four were not 
| enough. One year earlier, the Boeing 247 was introduced with all of them 
except 
| wing flaps. Lacking wing flaps, Boeing's engineers found that the plane was 
| unstable on take-off and landing and had to downsize the engine.

So maybe you are just being pessimistic when in fact we are in the (equivalent 
of)
that 30 year period?

Two more examples:
Dijkstra pointed out that it typically takes an idea a hundred years from 
discovery 
to mainstream. Think Cantor inventing set theory in 1880s, modern math entering
schools in 1970s.

A more extreme example: Europeans learnt first of Hindu-Arabic numerals in 
around
1000 AD. IT took a good 500 years to give up on Roman numerals

 
 
 There *are* some places where non-text programming has won.  The biggest 
 example would be GUI builders.  Nobody programs screen and window 
 layouts by typing textual descriptions.  They push boxes around in a GUI 
 builder.

And yet you routinely find people on this list recommending writing python to 
using
a GUI-builder.
On the one hand I am tempted to say Sheesh!!
On the other, maybe the builders are still too half-assed... Dunno

[BTW is there any equivalent for html?]
-- 
https://mail.python.org/mailman/listinfo/python-list


Re: PEP 8 : Maximum line Length :

2014-05-15 Thread wxjmfauth
Le mardi 13 mai 2014 10:45:49 UTC+2, Peter Otten a écrit :
 Ganesh Pal wrote:
 
 
 
  Hi  Team ,
 
  
 
  
 
  what would be the best way to intent the below line .
 
  
 
  I have few lines in my program exceeding the allowed maximum line Length
 
  of 79./80 characters
 
  
 
  Example 1 :
 
  
 
 p =
 
  
 
 Subprocess.Popen(shlex.split(cmd),stdout=subprocess.PIPE,stderr=subprocess.PIPE)
 
  
 
  
 
  Iam running pylint and it says  the above line is tool long how do I limit
 
  it to 79 character without violating any rules
 
  
 
  * Module isi_corrupt
 
  C: 14,0: Line too long (88/80)
 
  W: 19,0: Bad indentation. Found 6 spaces, expected 8
 
 
 
 (1) Newlines are allowed inside an open (, [, or {. So:
 
 
 
 p = subprocess.Popen(
 
 shlex.split(cmd),
 
 stdout=subprocess.PIPE,
 
 stderr=subprocess.PIPE)
 
 
 
 Other techniques:
 
 
 
 (2) Introduce helper variables:
 
 
 
 cmd = shlex.split(cmd)
 
 p = subprocess.Popen(cmd, stdout=subprocess.PIPE, stderr=subprocess.PIPE)
 
 
 
 (3) Import names:
 
 
 
 from subprocess import PIPE
 
 p = subprocess.Popen(shlex.split(cmd), stdout=PIPE, stderr=PIPE)
 
 
 
 (4) Use aliases:
 
 
 
 import subprocess as sp
 
 p = sp.Popen(shlex.split(cmd), stdout=sp.PIPE, stderr=sp.PIPE)

=

One another trick is to drop spaces around keywords

 9and 12345or 99if 'a'in'a' else or 77
12345

and pray, the tools from those who are wasting their time in
writing code analyzers or syntax colorizers or doc strings
collectors or ... are finally working. Depending of the tools
the interpretation may vary, but definitely all are producing
erroneous results.

jmf

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


Re: PEP 8 : Maximum line Length :

2014-05-15 Thread Chris Angelico
On Fri, May 16, 2014 at 12:12 AM, Marko Rauhamaa ma...@pacujo.net wrote:
 A definitive Python source file could be binary, XML, .py, .ast,
 whatever, and that would also be the file fed to the Python
 compiler/interpreter. However, your editor could choose freely how to
 present it to you.

 IOW, shouldn't PEP8 be redundant?

I believe the Python interpreter happily accepts a zip file, which in
theory could be edited directly by a competent text editor. But that
has nothing to do with PEP 8. Compare a classic compiled language like
C - you have the bit you edit (the C source code) and the definitive
version that's fed to the program loader (the compiled binary). Style
guides apply to the edited version, not to the executed version.

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


Re: PEP 8 : Maximum line Length :

2014-05-15 Thread Marko Rauhamaa
Rustom Mody rustompm...@gmail.com:

 And yet you routinely find people on this list recommending writing
 python to using a GUI-builder. On the one hand I am tempted to say
 Sheesh!! On the other, maybe the builders are still too
 half-assed... Dunno

That's like diagnosing cancer without invasive procedures, lab tests and
interviews: the doctor should be able to look at how pale you look and
if your skin has any funny bulges.

Thing is, programs and even text documents and spreadsheets have a lot
more abstract structure, dynamics and dependencies than the visible
façade. Block diagrams and graphics can be great presentation tools, but
nothing beats text in concise, explicit expressiveness.

An everyday example: a word processor displays the word hello with
hel in boldface and lo in italics. You put the cursor between the
l's and type a letter. Should it be in boldface or italics?

Who of you hasn't sworn at a Web editor that gets the formatting all
messed up when you have typed a backspace in the wrong place?


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


Re: PEP 8 : Maximum line Length :

2014-05-15 Thread Chris Angelico
On Fri, May 16, 2014 at 12:17 AM,  wxjmfa...@gmail.com wrote:
 One another trick is to drop spaces around keywords

 9and 12345or 99if 'a'in'a' else or 77
 12345

 and pray, the tools from those who are wasting their time in
 writing code analyzers or syntax colorizers or doc strings
 collectors or ... are finally working. Depending of the tools
 the interpretation may vary, but definitely all are producing
 erroneous results.

Yes. Another very effective way to get your code below 80 characters
is to shorten all names to a single letter. Since you don't need to
restrict yourself to monocase Roman letters (as I had to in my
earliest programming days, in BASIC), it's actually quite practical to
uniquely name everything in a single character; you could save
enormous amounts of horizontal space. Then, aggressively import as
to do the same with remote symbols (you might need two characters for
those), and you'll be able to write everything in just a few tight
symbols!

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


Re: PEP 8 : Maximum line Length :

2014-05-15 Thread Skip Montanaro
On Thu, May 15, 2014 at 9:29 AM, Marko Rauhamaa ma...@pacujo.net wrote:
 Who of you hasn't sworn at a Web editor that gets the formatting all
 messed up when you have typed a backspace in the wrong place?

My current pet peeve is the Gmail composition pane. What a load of
crap (especially in rich text mode).

You set the font to Sans Serif, start typing. Everything is in
Courier. Select All, switch everything to Sans Serif, and it redraw
the text, still in Courier, but in a different version of Courier.
Switch back to plain text mode. It has not-too-helpfully inserted line
breaks everywhere the rich text editor surrounded text with div
tags. Go back and delete all of them. Edit your text. Proofread your
text. Switch back to rich text so you can insert the image you wanted
to display. Hit Send.

Haven't we had WYSIWYG editors for about 40 years?

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


Re: PEP 8 : Maximum line Length :

2014-05-15 Thread Marko Rauhamaa
Chris Angelico ros...@gmail.com:

 I believe the Python interpreter happily accepts a zip file, which in
 theory could be edited directly by a competent text editor. But that
 has nothing to do with PEP 8. Compare a classic compiled language like
 C - you have the bit you edit (the C source code) and the definitive
 version that's fed to the program loader (the compiled binary). Style
 guides apply to the edited version, not to the executed version.

My point applies to C as well. Shouldn't the .c file contain an AST?
Only when you open the file in your text editor, it makes it look like
you wrote it yourself in your favorite style?

You and I could have opened the same C file. Only you see:

   #include stdio.h

   int   ++
   main ( int argc,  | My first C program |
  char *const argv[] )   ++
   {
   (void) printf( Hello world\n );

   return(0);
   }

while I see:

   #include stdio.h

   /* My first C program */
   int main(int argc, char *const argv[]) {
 printf(Hello world\n);
 return 0;
   }


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


Re: PEP 8 : Maximum line Length :

2014-05-15 Thread Chris Angelico
On Fri, May 16, 2014 at 12:29 AM, Marko Rauhamaa ma...@pacujo.net wrote:
 An everyday example: a word processor displays the word hello with
 hel in boldface and lo in italics. You put the cursor between the
 l's and type a letter. Should it be in boldface or italics?

Impossible to say, and one of the perpetual annoyances. Here's a web
site that I host:

http://gilbertandsullivan.org.au/index.php?option=com_contentview=articleid=92:2001-patiencecatid=30:patienceItemid=102

(Tiny URL: http://tinyurl.com/pphpkuk )

Why is Lt Duke of Dunstable different from all the other character
names? (By the way, I just picked an article at random from the
archive, and the first random pick had an example of what I'm talking
about. It's fairly prevalent on that site.) Now, if this were
hand-written HTML2, this sort of thing wouldn't happen; and, even
better, if the structure and formatting were properly separated (as in
my proposed web site redesign), they'd not only be guaranteed
consistent within a page, but also *across* pages.

Tagged text works well. In HTML pages, that means literal
anglebrackettags; in programming, that's all our various
notations and things. I wouldn't want to write code by writing a bunch
of words and then marking This word is an assignment target, this one
is an object that you should find a method on, this one is the method
name, and these ones are the arguments. I want to put = . ( ) to mark
those. More efficient... MUCH more reliable. And, bonus: it's all
text.

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


Re: PEP 8 : Maximum line Length :

2014-05-15 Thread Chris Angelico
On Fri, May 16, 2014 at 12:36 AM, Marko Rauhamaa ma...@pacujo.net wrote:
 You and I could have opened the same C file. Only you see:

#include stdio.h

int   ++
main ( int argc,  | My first C program |
   char *const argv[] )   ++
{
(void) printf( Hello world\n );

return(0);
}

 while I see:

#include stdio.h

/* My first C program */
int main(int argc, char *const argv[]) {
  printf(Hello world\n);
  return 0;
}

Well no, for two reasons. Firstly, I think the first one looks
disgusting, so even if I had that feature, I wouldn't use it like that
:)

But more importantly: You can already do that sort of thing, and it's
a bad idea. Maybe there aren't any text editors that can do it, but
you can use source control that way. (I'm going to use git as my
example, as I don't know how it's done in hg or any other; but I'm
sure it won't be hard.) You just tell git that these files (probably
files matching glob *.c) are to be reformatted, and provide two
commands: one that cleans a file prior to it going into source
control, and one that smudges it at the other end. So you could
simply write a code reformatter and register it as your smudge
command, and (in the interests of readable diffs) have some
standardized reformatter as the clean command. Voila! You now can
check out my code with your formatting.

Which brings me to the second reason for not doing this. That
clean/smudge operation *destroys information*. Once you enforce code
formatting like that, you violate PEP 8's rule zero: sometimes, it's
better to break the rules. Sometimes, your nice code reformatting
operation will actually make the program worse... and there'll be no
way for you to get back from that.

Not to mention that any reformatting that inserts or deletes lines is
a pain for debugging. Line 42 on your screen and Line 42 in the
traceback won't be the same thing any more. If I run your code and
give you an exception trace, you'll have to check out my version of
the code to be able to understand anything. Theoretically that could
be solved (eg you absolutely always run the checked-in version - of
course, that assumes that everyone's smudge and clean will perfectly
recreate the exact same output), but even with editor support, where
you'd move the cursor around and the line number would go berserk
(press down-arrow three times and the line number goes 5, 6, 6, 10),
it would be a pain.

Code is a text file. So is music (I use GNU LilyPond, and everything
works like code). So is data, in many many cases. So is configuration,
often, although some programs prefer to work with an opaque format.
About the only thing that really definitely shouldn't be massaged into
text is actual 2D images. Can you turn this into a few lines of code?

https://lh3.googleusercontent.com/-_8upQkJcvjE/UhTJlDzW3ZI/BU8/QvExuUq47dI/s512/DSCF7600.JPG

Pretty much everything else, though, works better as plain text.

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


Re: PEP 8 : Maximum line Length :

2014-05-15 Thread wxjmfauth
Le jeudi 15 mai 2014 16:27:16 UTC+2, Chris Angelico a écrit :
 On Fri, May 16, 2014 at 12:17 AM,  wxjmfa...@gmail.com wrote:
 
  One another trick is to drop spaces around keywords
 
 
 
  9and 12345or 99if 'a'in'a' else or 77
 
  12345
 
 
 
  and pray, the tools from those who are wasting their time in
 
  writing code analyzers or syntax colorizers or doc strings
 
  collectors or ... are finally working. Depending of the tools
 
  the interpretation may vary, but definitely all are producing
 
  erroneous results.
 
 
 
 Yes. Another very effective way to get your code below 80 characters
 
 is to shorten all names to a single letter. Since you don't need to
 
 restrict yourself to monocase Roman letters (as I had to in my
 
 earliest programming days, in BASIC), it's actually quite practical to
 
 uniquely name everything in a single character; you could save
 
 enormous amounts of horizontal space. Then, aggressively import as
 
 to do the same with remote symbols (you might need two characters for
 
 those), and you'll be able to write everything in just a few tight

=

 1or 0
1


Short, but still a bug.

1

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


Re: PEP 8 : Maximum line Length :

2014-05-15 Thread Mark Lawrence

On 15/05/2014 14:58, Roy Smith wrote:

In article 78ac407a-c429-4a7a-93c9-5d83e0f09...@googlegroups.com,
  Rustom Mody rustompm...@gmail.com wrote:


And yet programmers continue to be decades behind all other users of
computers.  We continue to use flat text for our programs when all others
have moved on.


It's not like we haven't tried.  There have been a few attempts at using
richer media to program (graphical UML editors, for example).  They've
all pretty much been failures.



This http://sourceforge.net/projects/doublesvsoop/ was project of the 
month just a little while ago, so it's obviously overcome all of the 
known obstacles, in exactly the same way that all previous silver 
bullets have done.  At least I think it's the kind of thing that you're 
talking about.


--
My fellow Pythonistas, ask not what our language can do for you, ask 
what you can do for our language.


Mark Lawrence

---
This email is free from viruses and malware because avast! Antivirus protection 
is active.
http://www.avast.com


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


Re: PEP 8 : Maximum line Length :

2014-05-15 Thread alister
On Thu, 15 May 2014 23:44:34 +1000, Chris Angelico wrote:

 On Thu, May 15, 2014 at 11:38 PM, alister
 alister.nospam.w...@ntlworld.com wrote:
 On Thu, 15 May 2014 23:31:44 +1000, Chris Angelico wrote:
 The Windows 8 / Unity / GNOME 3 model annoys me greatly. Can't get
 work done like that.

 ChrisA
 Windows 8/ Unity/ Gnome 3 are great on tablets (at least they look like
 they should be the only one I can confirm is Win 8) but lousy on a full
 pc with keyboard (Mouse optional)

 I am with you  use either LXDE or XFCE or run level 3 on all of my
 systems.
 
 Sorry, I should clarify that I'm talking about desktop systems here. I
 have no idea how good those UIs are on actual tablets; my beef with them
 is that putting a tablet UI on a desktop is just as much a bad idea as
 putting a desktop UI on a tablet. When I have a 1920x1080 display on a
 screen that's about a meter wide, running a single application is seldom
 what I want to do.
 
 ChrisA

i think i was actually agreeing with you :-)



-- 
Afternoon very favorable for romance.  Try a single person for a change.
-- 
https://mail.python.org/mailman/listinfo/python-list


Re: PEP 8 : Maximum line Length :

2014-05-15 Thread Terry Reedy

On 5/15/2014 10:42 AM, Chris Angelico wrote:


Impossible to say, and one of the perpetual annoyances. Here's a web
site that I host:

http://gilbertandsullivan.org.au/index.php?option=com_contentview=articleid=92:2001-patiencecatid=30:patienceItemid=102

(Tiny URL: http://tinyurl.com/pphpkuk )

Why is Lt Duke of Dunstable different from all the other character
names?


For me, Windows FF, it is not different that I can see.


--
Terry Jan Reedy

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


Re: PEP 8 : Maximum line Length :

2014-05-15 Thread Terry Reedy

On 5/15/2014 9:58 AM, Rustom Mody wrote:


As far as I can see the votaries of the mystical 79 have yet to explain
how/where it appeared from


As has been explained before, and is implied in the PEP, 79 = 80 - 1.
80 chars - 1 character width cursor leaves 79 non-cursor characters. 
When enter is hit, the cursor replaced with \n. So you can think of 79 
as 79 visible + \n = 80.


PEP 8 says The limits are chosen to avoid wrapping in editors with the 
window width set to 80, and goes on about dynamic wrapping or not. To 
put is another way, all 80 char terminals work with 79 visible chars. 
Some but not all work with 80 visible, and some work with 80 on all 
lines except the last.


I admit that this would have been clearer when most everyone reading it 
would have had some experience with 80 char sceens (including DOS). 
Still, did you really not notice that 79 = 80 - 1?


--
Terry Jan Reedy

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


Re: PEP 8 : Maximum line Length :

2014-05-15 Thread Ben Finney
Johannes Bauer dfnsonfsdu...@gmx.de writes:

 On 15.05.2014 04:43, Ben Finney wrote:
  Rustom Mody rustompm...@gmail.com writes:
  
  Until then may we relegate '79' to quaint historical curiosities
  
  Not until the general capacity of human cognition advances to make
  longer lines easier to read.

 I find it surprising how you can make such a claim about the whole of
 humanity (!) without even feeling the need to have a pro forma study
 to back it up.

This is an informal discussion forum. Merely because I don't produce
citations every time I mention a fact doesn't imply that I'm not basing
my assertions on fact.

Here is one such study
URL:http://www.psychology.nottingham.ac.uk/staff/mxh/Papers/Dyson%20%20Haselgrove%20%282001%29.pdf.
But there is plenty of room for uninformed diverity of opinion
URL:http://skeptics.stackexchange.com/questions/5625/are-shorter-lines-easier-to-read.

The point is less about hard evidence about *precise* limits; I make no
claim about the superiority of 80 columns or 93 columns or 55 columns or
whatever.

Rather, the point is rather that human cognition *does* have limits, and
those limits are at the basis of limits we choose to impose on text
layout.

Those who claim “terminals just magically happened to be 80 columns wide
and we were slaves to that limit” have it completely backward: the
limits were imposed *onto* the terminals by human makers, based on their
understanding of the cognitive limits of the humans reading from them.

Those limits are with us still, and to my knowledge have not improved
with recent human generations.

 Also, not everything that applies to prose also equally applies to
 code.

If you're going to counter evidence of general human reading cognition
by making special claims about code, that would need to be backed up
with specific evidence.

 Personally I find overly narrow code (80 cols) to be much *harder* to
 read than code that is 100 cols wide.

I counter your anecdote with my own: I find 80 columns to be quite long,
and prefer code to be no more than around 60 columns. So what do we
learn? That attempts to generalise from personal anecdote doesn't get us
anywhere useful.

-- 
 \“I took a course in speed waiting. Now I can wait an hour in |
  `\ only ten minutes.” —Steven Wright |
_o__)  |
Ben Finney

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


Re: PEP 8 : Maximum line Length :

2014-05-15 Thread MRAB

On 2014-05-15 22:50, Terry Reedy wrote:

On 5/15/2014 10:42 AM, Chris Angelico wrote:


Impossible to say, and one of the perpetual annoyances. Here's a web
site that I host:

http://gilbertandsullivan.org.au/index.php?option=com_contentview=articleid=92:2001-patiencecatid=30:patienceItemid=102

(Tiny URL: http://tinyurl.com/pphpkuk )

Why is Lt Duke of Dunstable different from all the other character
names?


For me, Windows FF, it is not different that I can see.


For me, with Firefox on Windows, it's slightly bolder, but that's
probably because its colour is specified, unlike the others.
--
https://mail.python.org/mailman/listinfo/python-list


Re: PEP 8 : Maximum line Length :

2014-05-15 Thread Rustom Mody
On Friday, May 16, 2014 3:51:27 AM UTC+5:30, Terry Reedy wrote:
 On 5/15/2014 9:58 AM, Rustom Mody wrote:
 
 
  As far as I can see the votaries of the mystical 79 have yet to explain
  how/where it appeared from
 
 
 
 As has been explained before, and is implied in the PEP, 79 = 80 - 1.
 80 chars - 1 character width cursor leaves 79 non-cursor characters. 
 When enter is hit, the cursor replaced with \n. So you can think of 79 
 as 79 visible + \n = 80.
 
 
 
 PEP 8 says The limits are chosen to avoid wrapping in editors with the 
 window width set to 80, and goes on about dynamic wrapping or not. To 
 put is another way, all 80 char terminals work with 79 visible chars. 
 Some but not all work with 80 visible, and some work with 80 on all 
 lines except the last.
 
 
 
 I admit that this would have been clearer when most everyone reading it 
 would have had some experience with 80 char sceens (including DOS). 
 Still, did you really not notice that 79 = 80 - 1?

The claim being made is that 79/80 is a fundamental, cognitive limit and has 
no relation to technological changes.
-- 
https://mail.python.org/mailman/listinfo/python-list


Re: PEP 8 : Maximum line Length :

2014-05-15 Thread Ben Finney
Rustom Mody rustompm...@gmail.com writes:

 The claim being made is that 79/80 is a fundamental, cognitive limit
 and has no relation to technological changes.

Who has made that claim, and where? You appear to be attacking a straw
man.

Rather, I've claimed that the conventional lime length limit is *based
in* the real cognitive limits of human reading comprehension — and that
technologies have been designed with corresponding limitations.

Nowhere have I claimed 79 or 80 are somehow fundamental or encoded in
human cognition, and I have seen no-one else claim that. Please try to
work within your own cognitive limits and read what people write for
comprehension.

-- 
 \  “As soon as we abandon our own reason, and are content to rely |
  `\   upon authority, there is no end to our troubles.” —Bertrand |
_o__)Russell, _Unpopular Essays_, 1950 |
Ben Finney

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


Re: PEP 8 : Maximum line Length :

2014-05-15 Thread Steven D'Aprano
On Thu, 15 May 2014 16:07:54 +0300, Marko Rauhamaa wrote:

 Johannes Bauer dfnsonfsdu...@gmx.de:
 
 I don't know why anyone would force a display issue onto everyone.
 
 Well, if I have to work with your code, you are forcing your style on
 me.

+1


 It imples the arrogant stance that every human being has the exact way
 of reading and writing code. Everyone can configure her editor to what
 she wants (including line breaks and such).
 
 That's a good point: why aren't we just exchanging AST's and configuring
 the editor to display them in our preferred format?

Oh, I hope not. Sometimes information is carried by the layout. For 
example, if I write a class:

class Spam:

def foo(self): ...
def bar(self): ...
def baz(self): ...

def foobar(self): ...


then without me saying anything, the reader should realise that foo, bar 
and baz, but not foobar, go together in a weak sense. If it were a strong 
sense, foobar ought to go into a separate class.

A real example: writing getters and setters for property. Particularly if 
they are one or two line methods, I'll usually run them together with no 
separating blank lines to emphasize that they belong together.

ASTs often don't include comments, so that's a problem.


 Well, we're not there yet.
 
 Objective readability is not the main issue here, IMO. It's the screen
 estate. I know the idea of windows is fast disappearing from modern
 (mobile) computing; you have apps instead that commandeer the whole
 screen. Personally, I find that a big step backwards.

Yes. In my opinion, mobile computing is a huge step backwards for 
personal control of your own hardware, usability, and power. In my 
opinion, people will look back at the first decade of the 21st century as 
the golden age of personal computing.



-- 
Steven D'Aprano
http://import-that.dreamwidth.org/
-- 
https://mail.python.org/mailman/listinfo/python-list


Re: PEP 8 : Maximum line Length :

2014-05-15 Thread Steven D'Aprano
On Thu, 15 May 2014 06:58:53 -0700, Rustom Mody wrote:

 As far as I can see the votaries of the mystical 79 have yet to explain
 how/where it appeared from

You're either trolling, or haven't been reading this thread in any 
detail. That's already been explained, repeatedly both in this thread and 
many times over the years: 79 is one less than 80, which is the standard 
width of many editors, which in turn comes from old dedicated terminals.

Given your use of deliberately provocative terms like votaries and 
mystical, I would say you're trolling.

On the chance that you are asking an honest question, there's nothing 
mystical or magical about the number 79, or 80. 80 is a de facto 
standard. Had history turned out a bit different, that standard might 
have been 90 characters, or 70. Less likely (because people 
psychologically have a preference for multiples of ten over random 
numbers) it could have been 65, or 93, or any number somewhere in that 
range of 60 to 100 or thereabouts.

But once a standard is established, even an arbitrary standard like 80 
columns -- but not *entirely* arbitrary -- there is value in sticking to 
it *just because it is the standard*. There's nothing mystical about 
driving on the left hand side of the road (on the right hand side for 
Americans), but whatever choice everyone else has made, you really ought 
to do the same. Following the same standard simply makes interoperability 
easier and reduces friction.

But as I said, 80 isn't *entirely* arbitrary. 8 characters would be too 
few; 800 would be too many. Approximately 60 to 100 characters or 
thereabouts is the Goldilocks zone of not too few, not too many for 
most texts.

Think of it this way: every time the reader has to scroll horizontally, 
consider that as a page fault (it's an order of magnitude slower than 
scanning with the eyes). Every time a single logical expression has to be 
split over two lines, that's also a page fault. Every time you read a 
line of complicated code that does too much, that's also a page fault. We 
want to minimize the number of page faults.

A limit of 60 characters would minimize the number of horizontal 
scrolling page faults (hardly anyone has their editor to display fewer 
than 60 characters!), but increase the number of expression-splitting 
page faults. A limit of 120 characters would reduce the number of 
expression-splitting page faults, but increase the number of horizontal-
scrolling faults, and encourage people to write long lines of complicated 
code that does too much. Somewhere in between is a range that minimizes 
the number of page faults, hence maximizes readability.

There's unlikely to be One True Best Answer to maximize readability at 
N characters, because maximum readability is dependent on the context. 
One can only hope to get close to maximum readability for a range of 
typical text, including code. That's likely to be around 80 characters, 
which fits nicely with the historical standard. Reducing that to 80-1=79 
means you're protected from off-by-one errors in either your counting 
or your editor.



-- 
Steven D'Aprano
http://import-that.dreamwidth.org/
-- 
https://mail.python.org/mailman/listinfo/python-list


Re: PEP 8 : Maximum line Length :

2014-05-15 Thread Rustom Mody
On Friday, May 16, 2014 5:51:21 AM UTC+5:30, Ben Finney wrote:
 
 
 Rather, I've claimed that the conventional lime length limit is *based
 in* the real cognitive limits of human reading comprehension -- and that
 technologies have been designed with corresponding limitations.
 
 
 Nowhere have I claimed 79 or 80 are somehow fundamental or encoded in
 human cognition, and I have seen no-one else claim that. Please try to
 work within your own cognitive limits and read what people write for
 comprehension.
 

You said this:

 The 80 character line limit is *not* driven by a limitation of computer
 technology; it is driven by a limitation of human cognition. For that
 reason, it remains relevant until human cognition in the general reading
 population improves. 

And you answered:

 Until then may we relegate '79' to quaint historical curiosities...??

with

 Not until the general capacity of human cognition advances to make
 longer lines easier to read.
-- 
https://mail.python.org/mailman/listinfo/python-list


Re: PEP 8 : Maximum line Length :

2014-05-14 Thread Terry Reedy

On 5/13/2014 6:55 PM, Ben Finney wrote:

Steven D'Aprano steve+comp.lang.pyt...@pearwood.info writes:


On Tue, 13 May 2014 04:52:26 -0700, Rustom Mody wrote:


What this goes to show is that while 80 is ridiculously low by most
displays today,


Not for people who like to has two (or three, or four) windows side-by-
side. Or multiple views of the same document.


There's also the fact that, while the capacity of monitors to display
pixels has dramatically increased in recent decades, the capacity of
human cognition to scan long lines of text has not increased at all in
that time.



The 80 character line limit is *not* driven by a limitation of computer
technology; it is driven by a limitation of human cognition. For that
reason, it remains relevant until human cognition in the general reading
population improves.


I use the monitor capacity to have 2 or even 3 code windows open 
side-by-side. Really handy.


--
Terry Jan Reedy

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


Re: PEP 8 : Maximum line Length :

2014-05-14 Thread Albert van der Horst
In article a3253d6a-ef89-49d5-b866-8c06a7462...@googlegroups.com,
Rustom Mody  rustompm...@gmail.com wrote:
On Tuesday, May 13, 2014 12:37:24 PM UTC+5:30, Ganesh Pal wrote:
 Hi  Team ,


 what would be the best way to intent the below line .

 I have few lines in my program exceeding the allowed maximum line
Length of 79./80 characters


 Example 1 :


p =
Subprocess.Popen(shlex.split(cmd),stdout=subprocess.PIPE,stderr=subprocess.PIPE)


First rule of python-list: Pay careful attention to Peter Otten.

That said...

80-character limit?!

Sheesh! A relic of the days when terminals were ASCII and 80x24

80 character was the hard limit.
The soft limit for readability is 60..65 characters.
Think about it.

Just that a language accepts
#define MASK_SEPIA_INTERNAL_BLEEDING_WASHINGTON_DC_BLACK 0x147800fa
means that it is a good idea to do so.

Groetjes Albert
-- 
Albert van der Horst, UTRECHT,THE NETHERLANDS
Economic growth -- being exponential -- ultimately falters.
albert@spearc.xs4all.nl =n http://home.hccnet.nl/a.w.m.van.der.horst

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


Re: PEP 8 : Maximum line Length :

2014-05-14 Thread Gary Herron

On 05/14/2014 03:53 PM, Albert van der Horst wrote:

In article a3253d6a-ef89-49d5-b866-8c06a7462...@googlegroups.com,
Rustom Mody  rustompm...@gmail.com wrote:

On Tuesday, May 13, 2014 12:37:24 PM UTC+5:30, Ganesh Pal wrote:

Hi  Team ,


what would be the best way to intent the below line .

I have few lines in my program exceeding the allowed maximum line

Length of 79./80 characters


Example 1 :


p =

Subprocess.Popen(shlex.split(cmd),stdout=subprocess.PIPE,stderr=subprocess.PIPE)


First rule of python-list: Pay careful attention to Peter Otten.

That said...

80-character limit?!

Sheesh! A relic of the days when terminals were ASCII and 80x24


Which is a relic of the even older punch cards which contained one line 
of (up to) 80 characters.


Gary Herron



80 character was the hard limit.
The soft limit for readability is 60..65 characters.
Think about it.

Just that a language accepts
#define MASK_SEPIA_INTERNAL_BLEEDING_WASHINGTON_DC_BLACK 0x147800fa
means that it is a good idea to do so.

Groetjes Albert


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


Re: PEP 8 : Maximum line Length :

2014-05-14 Thread Mark Lawrence

On 15/05/2014 01:15, Gary Herron wrote:


Which is a relic of the even older punch cards which contained one line
of (up to) 80 characters.

Gary Herron



I still remember the cry of anguish when the guy in the computer 
building at (the then) Portsmouth Polytechnic dropped his cardboard box 
of punch cards that made up his end of course project.


--
My fellow Pythonistas, ask not what our language can do for you, ask 
what you can do for our language.


Mark Lawrence

---
This email is free from viruses and malware because avast! Antivirus protection 
is active.
http://www.avast.com


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


Re: PEP 8 : Maximum line Length :

2014-05-14 Thread Roy Smith
In article mailman.10026.1400116640.18130.python-l...@python.org,
 Mark Lawrence breamore...@yahoo.co.uk wrote:

 I still remember the cry of anguish when the guy in the computer 
 building at (the then) Portsmouth Polytechnic dropped his cardboard box 
 of punch cards that made up his end of course project.

That's why you punch sequence numbers in columns 73-80.  If the cards 
get out of order, just run the deck through the sorter.
-- 
https://mail.python.org/mailman/listinfo/python-list


Re: PEP 8 : Maximum line Length :

2014-05-14 Thread Rustom Mody
On Thursday, May 15, 2014 4:23:52 AM UTC+5:30, Albert van der Horst wrote:
 
 Rustom Mody  wrote:

 80-character limit?!
 Sheesh! A relic of the days when terminals were ASCII and 80x24
 
 
 80 character was the hard limit.
 The soft limit for readability is 60..65 characters.
 Think about it.
 
 
 Just that a language accepts
 #define MASK_SEPIA_INTERNAL_BLEEDING_WASHINGTON_DC_BLACK 0x147800fa
 means that it is a good idea to do so.

Yes there are fundamental but soft limits, eg
http://webtypography.net/2.1.2

And there are (semi)hard technological limits like if you post code longer 65 
chars out here it will fold at random unforeseen points.
These limits get irrelevant as the technology changes.

If any of these has any relation with the magic number '79' I'd be
curious to know.

Until then may we relegate '79' to quaint historical curiosities like: 
Continuation in 6th column, Comment is a C in 1st column, 7-72 for code
(ALONG WITH ALL CAPS CODE)?
-- 
https://mail.python.org/mailman/listinfo/python-list


Re: PEP 8 : Maximum line Length :

2014-05-14 Thread Ben Finney
Rustom Mody rustompm...@gmail.com writes:

 Until then may we relegate '79' to quaint historical curiosities

Not until the general capacity of human cognition advances to make
longer lines easier to read.

We humans may be historical curiosities some day; until then, let's
continue to write our code as though humans are the ones who will be
reading it.

-- 
 \“Stop — Drive sideways.” —detour sign, Kyushu, Japan |
  `\   |
_o__)  |
Ben Finney

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


Re: PEP 8 : Maximum line Length :

2014-05-14 Thread Steven D'Aprano
On Wed, 14 May 2014 19:36:13 -0700, Rustom Mody wrote:

 And there are (semi)hard technological limits like if you post code
 longer 65 chars out here it will fold at random unforeseen points. These
 limits get irrelevant as the technology changes.

The technological limits may become irrelevant, but the human limits do 
not. While there are no *hard* limits to readability, both excessively 
long and excessively short lines are hard to read. Comprehension and 
reading speed suffers.


 If any of these has any relation with the magic number '79' I'd be
 curious to know.

79 is one short of 80, which gives you a margin of error of 1: off-by-one 
errors won't matter if you aim for 79 characters but miscalculate by one.

People repeatedly state that 80 is the old, obsolete hard limit for 
ancient terminal systems, but the reason terminals standardised on 80 
rather than 70 or 90 (or for that matter 300 or 30) is at least in part 
-- and I maintain a big part -- because of human reading. 60 to 90 
characters per line is a comfortable range for human readability, which 
makes 80 a reasonable compromise that tends towards the upper end but 
without pushing hard up against it.

Keeping the monitor size and character size fixed, it's easy to show 
*fewer* characters per line if you choose a standard towards the upper 
end, if you so choose, but impossible to squeeze in more if you choose a 
standard at the lower end.

Just because the monitor (or the standard) *allows* up to 79 characters 
per line doesn't make it a good idea to regularly use that many. In my 
experience, given two or three indent levels, reasonably descriptive 
variable names, decently expressive expressions, I find that 60-70 
characters is *typically* enough horizontal space for the average line of 
code. Long lines are often (not always) a sign that you're doing too much 
in one line. This isn't Perl, and newlines are a renewable resource.


 Until then may we relegate '79' to quaint historical curiosities like:
 Continuation in 6th column, Comment is a C in 1st column, 7-72 for code
 (ALONG WITH ALL CAPS CODE)?

Nope. Because the main driving force for 79 characters is not technology 
but human reading.



-- 
Steven D'Aprano
http://import-that.dreamwidth.org/
-- 
https://mail.python.org/mailman/listinfo/python-list


Re: PEP 8 : Maximum line Length :

2014-05-14 Thread Mark Lawrence

On 15/05/2014 03:43, Ben Finney wrote:

Rustom Mody rustompm...@gmail.com writes:


Until then may we relegate '79' to quaint historical curiosities


Not until the general capacity of human cognition advances to make
longer lines easier to read.

We humans may be historical curiosities some day; until then, let's
continue to write our code as though humans are the ones who will be
reading it.



I thought code was meant to be read by programmers, not humans :)

--
My fellow Pythonistas, ask not what our language can do for you, ask 
what you can do for our language.


Mark Lawrence

---
This email is free from viruses and malware because avast! Antivirus protection 
is active.
http://www.avast.com


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


Re: PEP 8 : Maximum line Length :

2014-05-13 Thread Peter Otten
Ganesh Pal wrote:

 Hi  Team ,
 
 
 what would be the best way to intent the below line .
 
 I have few lines in my program exceeding the allowed maximum line Length
 of 79./80 characters
 
 Example 1 :
 
p =
 
Subprocess.Popen(shlex.split(cmd),stdout=subprocess.PIPE,stderr=subprocess.PIPE)
 
 
 Iam running pylint and it says  the above line is tool long how do I limit
 it to 79 character without violating any rules
 
 * Module isi_corrupt
 C: 14,0: Line too long (88/80)
 W: 19,0: Bad indentation. Found 6 spaces, expected 8

(1) Newlines are allowed inside an open (, [, or {. So:

p = subprocess.Popen(
shlex.split(cmd),
stdout=subprocess.PIPE,
stderr=subprocess.PIPE)

Other techniques:

(2) Introduce helper variables:

cmd = shlex.split(cmd)
p = subprocess.Popen(cmd, stdout=subprocess.PIPE, stderr=subprocess.PIPE)

(3) Import names:

from subprocess import PIPE
p = subprocess.Popen(shlex.split(cmd), stdout=PIPE, stderr=PIPE)

(4) Use aliases:

import subprocess as sp
p = sp.Popen(shlex.split(cmd), stdout=sp.PIPE, stderr=sp.PIPE)


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


Re: PEP 8 : Maximum line Length :

2014-05-13 Thread alister
On Tue, 13 May 2014 10:45:49 +0200, Peter Otten wrote:

 Ganesh Pal wrote:
 
 Hi  Team ,
 
 
 what would be the best way to intent the below line .
 
 I have few lines in my program exceeding the allowed maximum line
 Length of 79./80 characters
 
 Example 1 :
 
p =
 
 Subprocess.Popen(shlex.split
(cmd),stdout=subprocess.PIPE,stderr=subprocess.PIPE)
 
 
 Iam running pylint and it says  the above line is tool long how do I
 limit it to 79 character without violating any rules
 
 * Module isi_corrupt C: 14,0: Line too long (88/80)
 W: 19,0: Bad indentation. Found 6 spaces, expected 8
 
 (1) Newlines are allowed inside an open (, [, or {. So:
 
 p = subprocess.Popen(
 shlex.split(cmd), stdout=subprocess.PIPE,
 stderr=subprocess.PIPE)
 
 Other techniques:
 
 (2) Introduce helper variables:
 
 cmd = shlex.split(cmd)
 p = subprocess.Popen(cmd, stdout=subprocess.PIPE,
 stderr=subprocess.PIPE)
 
 (3) Import names:
 
 from subprocess import PIPE p = subprocess.Popen(shlex.split(cmd),
 stdout=PIPE, stderr=PIPE)
 
 (4) Use aliases:
 
 import subprocess as sp p = sp.Popen(shlex.split(cmd), stdout=sp.PIPE,
 stderr=sp.PIPE)

or simply leave it alone
Pep 8 is a guide not a Set in Stone rule  even pep 8 does say that the 
80 character limit can be exceeded if breaking the line would make the 
code less readable





-- 
Catastrophic failure of the IDE cable???.
What are you doing to the poor thing, jumping on it?

- Beau Kuiper on linux-kernel
-- 
https://mail.python.org/mailman/listinfo/python-list


Re: PEP 8 : Maximum line Length :

2014-05-13 Thread Rustom Mody
On Tuesday, May 13, 2014 12:37:24 PM UTC+5:30, Ganesh Pal wrote:
 Hi  Team ,
 
 
 what would be the best way to intent the below line .
 
 I have few lines in my program exceeding the allowed maximum line Length of 
 79./80 characters 
 
 
 Example 1 :
 
 
p = 
 Subprocess.Popen(shlex.split(cmd),stdout=subprocess.PIPE,stderr=subprocess.PIPE)


First rule of python-list: Pay careful attention to Peter Otten.

That said...

80-character limit?!

Sheesh! A relic of the days when terminals were ASCII and 80x24

I wrote about this
http://blog.languager.org/2012/10/layout-imperative-in-functional.html

While its mostly haskell oriented, the comments are amusingly related to this
question in any language:

Comment:
  It is kind of ironic that the blog format wraps your wide code examples at 65 
  chars.

What this goes to show is that while 80 is ridiculously low by most displays 
today,
it is too high for many web/mailing-list fora.

Of course a standard helps in removing superfluous variations.

Still... its 2014 and 80-columns is as current and relevant as ASCII.

PS.

Last rule of python list: Always listen to Peter Otten.
-- 
https://mail.python.org/mailman/listinfo/python-list


Re: PEP 8 : Maximum line Length :

2014-05-13 Thread Roy Smith
In article mailman.9945.1399965443.18130.python-l...@python.org,
 Ganesh Pal ganesh1...@gmail.com wrote:

 Hi  Team ,
 
 
 what would be the best way to intent the below line .
 
 I have few lines in my program exceeding the allowed maximum line Length of
 79./80 characters
 
 Example 1 :
 
p = 
 Subprocess.Popen(shlex.split(cmd),stdout=subprocess.PIPE,stderr=subprocess.PIPE)

The problem here is not so much that you've exceeded 80 columns, but that 
there's no logical
structure which gives your eyes (and your brain) hints about how to parse this. 
 I would
start by adding some white space

p = Subprocess.Popen(shlex.split(cmd), stdout=subprocess.PIPE, 
 stderr=subprocess.PIPE)

now, at least, it's easier to see where each argument stops and the next one 
starts.  But,
I would really break this up into multiple lines

p = Subprocess.Popen(shlex.split(cmd),
 stdout=subprocess.PIPE,
 stderr=subprocess.PIPE)
-- 
https://mail.python.org/mailman/listinfo/python-list


Re: PEP 8 : Maximum line Length :

2014-05-13 Thread Ben Finney
Ganesh Pal ganesh1...@gmail.com writes:

 what would be the best way to intent the below line .

You'd need to define “best” in order to get an objective answer.

So my answer will be based on my preferences, and general rules I've
observed for making code readable.

 Example 1 :

p =
 Subprocess.Popen(shlex.split(cmd),stdout=subprocess.PIPE,stderr=subprocess.PIPE)

(Your example violates PEP 8 also in not having a space after the
commas. I'll fix that in my response.)

Breaking a long line after bracketing syntax is a good way to do it.
Make sure to use sntadard indentation::

Subprocess.Popen(
shlex.split(cmd), stdout=subprocess.PIPE, stderr=subprocess.PIPE)

Alternatively, if the statement line is indented further::

Subprocess.Popen(
shlex.split(cmd),
stdout=subprocess.PIPE,
stderr=subprocess.PIPE)

 Iam running pylint and it says  the above line is tool long how do I limit
 it to 79 character without violating any rules

* Break after bracketing syntax::

  frobnicate(
  foo, bar, baz)

* Keep all the inside-the-brackets contents at the same indentation
  level (preferably 8 columns, to differentiate from a block of
  statements)

  if worzel:
  fnoop(wibble, wobble, wubble)
  frobnicate(
  foo, bar, baz)
  while True:
  gezunk()

Here's an answer I gave on StackOverflow for this question
URL:http://stackoverflow.com/questions/5931297/how-would-you-properly-break-this-line-to-match-pep8-rules/17246180#17246180
(URL:http://stackoverflow.com/a/17246180/70157).

-- 
 \   “If you're a cowboy and you're dragging a guy behind your |
  `\  horse, I bet it would really make you mad if you looked back |
_o__)and the guy was reading a magazine.” —Jack Handey |
Ben Finney

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


Re: PEP 8 : Maximum line Length :

2014-05-13 Thread Ben Finney
Roy Smith r...@panix.com writes:

 p = Subprocess.Popen(shlex.split(cmd),
  stdout=subprocess.PIPE,
  stderr=subprocess.PIPE)

That is PEP 8 conformant, but I find it hurts maintainability: it is far
too much indentation. Horizontal space is costly, because so much
indentation severely limits the length of names etc. that you can use on
the continuation lines.

Worse, it is also needlessly tying all the continuation lines to the
length of the text before the open paren. What if ‘p’ changes to some
other name?

With the style I've advocated::

p = Subprocess.Popen(
shlex.split(cmd),
stdout=subprocess.PIPE,
stderr=subprocess.PIPE)

Changing the name on the first line doesn't entail changing any other
line::

proc = Subprocess.Popen(
shlex.split(cmd),
stdout=subprocess.PIPE,
stderr=subprocess.PIPE)

special_process_map[this_process] = Subprocess.Popen(
shlex.split(cmd),
stdout=subprocess.PIPE,
stderr=subprocess.PIPE)

Whereas with your suggestion, every line would need to change simply
because the first one did::


special_process_map[this_process] = Subprocess.Popen(shlex.split(cmd),
 stdout=subprocess.PIPE,
 stderr=subprocess.PIPE)

Yes, that's contrived. But I prefer to use a style that doesn't need to
deal with the issue of when the indentation has gone too far for a
single statement.

It's for both those reasons that I recommend avoiding the “align with
open bracket” style, and instead use a standard eight-column indentation
for continuation lines.

-- 
 \  “One bad programmer can easily create two new jobs a year. |
  `\  Hiring more bad programmers will just increase our perceived |
_o__) need for them.” —David Lorge Parnas, 1999-03 |
Ben Finney

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


Re: PEP 8 : Maximum line Length :

2014-05-13 Thread Tim Chase
On 2014-05-13 22:26, Ben Finney wrote:
 Changing the name on the first line doesn't entail changing any
 other line::
 
 proc = Subprocess.Popen(
 shlex.split(cmd),
 stdout=subprocess.PIPE,
 stderr=subprocess.PIPE)
 
 special_process_map[this_process] = Subprocess.Popen(
 shlex.split(cmd),
 stdout=subprocess.PIPE,
 stderr=subprocess.PIPE)

I second the idea of just putting each-of-many-parameters on its own
line.  Not only that, I also like to tack on trailing commas and put
the closing paren on its own line to make diffs easier to read:

special_process_map[this_process] = Subprocess.Popen(
shlex.split(cmd),
stdout=subprocess.PIPE,
stderr=subprocess.PIPE,
)

so that when I add the inevitable parameter, the diff merely reads
like

  --- tim1.txt2014-05-13 07:44:42.441754319 -0500
  +++ tim2.txt2014-05-13 07:45:35.753755858 -0500
  @@ -2,4 +2,5 @@
   shlex.split(cmd),
   stdout=subprocess.PIPE,
   stderr=subprocess.PIPE,
  +bufsize=1024,
  )

which is quite clear that just one line was added, compared to

  --- ben1.txt2014-05-13 07:44:51.033754566 -0500
  +++ ben2.txt2014-05-13 07:45:46.737756176 -0500
  @@ -1,4 +1,5 @@
   special_process_map[this_process] = Subprocess.Popen(
   shlex.split(cmd),
   stdout=subprocess.PIPE,
  -stderr=subprocess.PIPE)
  +stderr=subprocess.PIPE,
  +bufsize=1024)

which makes me have to think/verify about whether anything else
changed between insertion and deletion of lines.

-tkc





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


Re: PEP 8 : Maximum line Length :

2014-05-13 Thread Rustom Mody
On Tuesday, May 13, 2014 2:15:49 PM UTC+5:30, Peter Otten wrote:
 Ganesh Pal wrote:
  what would be the best way to intent the below line .
 p = 
  Subprocess.Popen(shlex.split(cmd),stdout=subprocess.PIPE,stderr=subprocess.PIPE)
 (3) Import names:
 
 
 from subprocess import PIPE
 p = subprocess.Popen(shlex.split(cmd), stdout=PIPE, stderr=PIPE)

Am I missing something basic that nobody has suggested the above
technique iterated once more??

from subprocess import Popen, PIPE
p = Popen(shlex.split(cmd), stdout=PIPE, stderr=PIPE)
-- 
https://mail.python.org/mailman/listinfo/python-list


Re: PEP 8 : Maximum line Length :

2014-05-13 Thread Steven D'Aprano
On Tue, 13 May 2014 04:52:26 -0700, Rustom Mody wrote:

 What this goes to show is that while 80 is ridiculously low by most
 displays today, 

Not for people who like to has two (or three, or four) windows side-by-
side. Or multiple views of the same document.


 it is too high for many web/mailing-list fora.

And smart phones. 


[...]
 PS.
 Last rule of python list: Always listen to Peter Otten.

Yes. Peter is a treasure to the community, not just for his knowledge but 
for his patience and friendliness.


-- 
Steven D'Aprano

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


Re: PEP 8 : Maximum line Length :

2014-05-13 Thread Ben Finney
Steven D'Aprano steve+comp.lang.pyt...@pearwood.info writes:

 On Tue, 13 May 2014 04:52:26 -0700, Rustom Mody wrote:

  What this goes to show is that while 80 is ridiculously low by most
  displays today, 

 Not for people who like to has two (or three, or four) windows side-by-
 side. Or multiple views of the same document.

There's also the fact that, while the capacity of monitors to display
pixels has dramatically increased in recent decades, the capacity of
human cognition to scan long lines of text has not increased at all in
that time.

The 80 character line limit is *not* driven by a limitation of computer
technology; it is driven by a limitation of human cognition. For that
reason, it remains relevant until human cognition in the general reading
population improves.

-- 
 \   “Give a man a fish, and you'll feed him for a day; give him a |
  `\religion, and he'll starve to death while praying for a fish.” |
_o__)   —Anonymous |
Ben Finney

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


Re: PEP 8 : Maximum line Length :

2014-05-13 Thread Gregory Ewing

Ben Finney wrote:

The 80 character line limit is *not* driven by a limitation of computer
technology; it is driven by a limitation of human cognition. For that
reason, it remains relevant until human cognition in the general reading
population improves.


Another thing: Just because I may have 2048 pixes of
horizontal space available on my monitor, that doesn't
mean I want to devote all of them to displaying a
single source file.

I like to be able to put 2 or 3 source windows side
by side, or have a web browser showing documentation
alongside while I work, etc.

While the limit doesn't have to be exactly 80 chars,
something not too much bigger is a good idea for a
variety of reasons.

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


Re: PEP 8 : Maximum line Length :

2014-05-13 Thread Roy Smith
In article mailman.9961.1399984013.18130.python-l...@python.org,
 Ben Finney b...@benfinney.id.au wrote:

 Roy Smith r...@panix.com writes:
 
  p = Subprocess.Popen(shlex.split(cmd),
   stdout=subprocess.PIPE,
   stderr=subprocess.PIPE)
 
 That is PEP 8 conformant, but I find it hurts maintainability: it is far
 too much indentation. Horizontal space is costly, because so much
 indentation severely limits the length of names etc. that you can use on
 the continuation lines.

It only does that if you limit yourself to 80 character lines.
-- 
https://mail.python.org/mailman/listinfo/python-list