Re: PEP 8 : Maximum line Length :
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 :
On 17/05/2014 15:06, Roy Smith wrote: In article , Mark Lawrence 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 :
In article , Mark Lawrence 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 :
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 :
In article , Chris Angelico wrote: > On Sat, May 17, 2014 at 10:52 PM, Albert van der Horst > 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 :
In article ,
Tim Chase 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 :
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 :
On Sat, May 17, 2014 at 10:52 PM, Albert van der Horst 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 :
In article , Chris Angelico wrote: >On Fri, May 16, 2014 at 12:17 AM, 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@spe&ar&c.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 :
Chris Angelico : > 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 :
On Fri, May 16, 2014 at 7:18 PM, Marko Rauhamaa 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 :
Chris Angelico : > 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 :
On Fri, May 16, 2014 at 5:00 PM, Marko Rauhamaa 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 :
On Fri, May 16, 2014 at 4:25 PM, Steven D'Aprano 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 :
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 :
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". 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 :
Steven D'Aprano 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 :
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 :
Rustom Mody 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 :
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 :
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 :
On Thu, 15 May 2014 16:07:54 +0300, 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.
+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 :
Rustom Mody 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 :
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 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 :
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_content&view=article&id=92:2001-patience&catid=30:patience&Itemid=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 :
Johannes Bauer writes: > On 15.05.2014 04:43, Ben Finney wrote: > > Rustom Mody 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 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 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 :
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 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 :
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_content&view=article&id=92:2001-patience&catid=30:patience&Itemid=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 :
On Thu, 15 May 2014 23:44:34 +1000, Chris Angelico wrote: > On Thu, May 15, 2014 at 11:38 PM, alister > 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 :
On 15/05/2014 14:58, Roy Smith wrote: In article <78ac407a-c429-4a7a-93c9-5d83e0f09...@googlegroups.com>, 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. 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 :
Le jeudi 15 mai 2014 16:27:16 UTC+2, Chris Angelico a écrit : > On Fri, May 16, 2014 at 12:17 AM, 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 :
On Fri, May 16, 2014 at 12:36 AM, Marko Rauhamaa wrote:
> You and I could have opened the same C file. Only you see:
>
>#include
>
>int ++
>main ( int argc, | My first C program |
> char *const argv[] ) ++
>{
>(void) printf( "Hello world\n" );
>
>return(0);
>}
>
> while I see:
>
>#include
>
>/* 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 :
On Fri, May 16, 2014 at 12:29 AM, Marko Rauhamaa 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_content&view=article&id=92:2001-patience&catid=30:patience&Itemid=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 ; 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 :
Chris Angelico :
> 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
int ++
main ( int argc, | My first C program |
char *const argv[] ) ++
{
(void) printf( "Hello world\n" );
return(0);
}
while I see:
#include
/* 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 :
On Thu, May 15, 2014 at 9:29 AM, Marko Rauhamaa 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 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 :
On Fri, May 16, 2014 at 12:17 AM, 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 :
Rustom Mody : > 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 :
On Fri, May 16, 2014 at 12:12 AM, Marko Rauhamaa 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 :
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 :
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 :
Rustom Mody : > 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 :
On Thu, May 15, 2014 at 11:58 PM, Roy Smith 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 :
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 :
In article <78ac407a-c429-4a7a-93c9-5d83e0f09...@googlegroups.com>, 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. 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 :
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 :
On Thu, May 15, 2014 at 11:38 PM, alister 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 :
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 :
On Thu, May 15, 2014 at 11:07 PM, Marko Rauhamaa 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 :
On Thu, May 15, 2014 at 10:32 PM, Johannes Bauer 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 :
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.
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 :
On 15.05.2014 04:43, Ben Finney wrote: > Rustom Mody 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 -- https://mail.python.org/mailman/listinfo/python-list
Re: PEP 8 : Maximum line Length :
On 05/14/2014 10:12 PM, Roy Smith wrote: In article , Mark Lawrence 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 :
On 15/05/2014 03:43, Ben Finney wrote: Rustom Mody 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 :
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 :
Rustom Mody 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 :
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 :
In article , Mark Lawrence 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 :
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 :
On 05/14/2014 03:53 PM, Albert van der Horst wrote: In article , Rustom Mody 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 :
In article , Rustom Mody 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@spe&ar&c.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 :
On 5/13/2014 6:55 PM, Ben Finney wrote: Steven D'Aprano 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 :
In article , Ben Finney wrote: > Roy Smith 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
Re: PEP 8 : Maximum line Length :
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 :
Steven D'Aprano 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 :
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 :
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 :
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 :
Roy Smith 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 :
Ganesh Pal 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 http://stackoverflow.com/questions/5931297/how-would-you-properly-break-this-line-to-match-pep8-rules/17246180#17246180> (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 :
In article , 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) 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 :
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 :
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 :
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
