Re: 79 chars or more?
Lawrence D'Oliveiro wrote: In message mailman.2230.1282037319.1673.python-l...@python.org, Jean-Michel Pichavant wrote: Saying that, if one intend to distribute its code, he should stick to 80 chars per line. Why? Because some(many ?) people cannot deal with more than 80 chars, otherwise this rule would be pointless. JM -- http://mail.python.org/mailman/listinfo/python-list
Re: 79 chars or more?
In message mailman.0.1282642167.29448.python-l...@python.org, Jean-Michel Pichavant wrote: Lawrence D'Oliveiro wrote: In message mailman.2230.1282037319.1673.python-l...@python.org, Jean-Michel Pichavant wrote: Saying that, if one intend to distribute its code, he should stick to 80 chars per line. Why? Because some(many ?) people cannot deal with more than 80 chars, otherwise this rule would be pointless. So you assume the rule cannot be pointless? -- http://mail.python.org/mailman/listinfo/python-list
Re: 79 chars or more?
Roy Smith wrote: There was a fling a while ago with typesetting code in proportional spaced type. I think some of the Effective C++ series from Addison-Wesley did that. Yuck. I don't think proportional spacing is necessarily a problem, as long as a font is used that makes all characters clearly distinguishible. Unfortunately, most of the widely-used sans-serif proportional fonts fail to do this. -- Greg -- http://mail.python.org/mailman/listinfo/python-list
Re: 79 chars or more?
Gregory Ewing wrote: Roy Smith wrote: There was a fling a while ago with typesetting code in proportional spaced type. I think some of the Effective C++ series from Addison-Wesley did that. Yuck. I don't think proportional spacing is necessarily a problem, as long as a font is used that makes all characters clearly distinguishible. Unfortunately, most of the widely-used sans-serif proportional fonts fail to do this. I don't think proportional spacing is necessarily a problem, as long all the characters are the same width. :-) -- http://mail.python.org/mailman/listinfo/python-list
Re: 79 chars or more?
In article 4c6dfb31$0$1$c3e8...@news.astraweb.com, Steven D'Aprano st...@remove-this-cybersource.com.au wrote: Of course source code is written in a monospaced typeface, which is a little wider and consequently fewer characters per page. There was a fling a while ago with typesetting code in proportional spaced type. I think some of the Effective C++ series from Addison-Wesley did that. Yuck. -- http://mail.python.org/mailman/listinfo/python-list
Re: 79 chars or more?
On 2010-08-20, Roy Smith r...@panix.com wrote: In article 4c6dfb31$0$1$c3e8...@news.astraweb.com, Steven D'Aprano st...@remove-this-cybersource.com.au wrote: Of course source code is written in a monospaced typeface, which is a little wider and consequently fewer characters per page. There was a fling a while ago with typesetting code in proportional spaced type. I think some of the Effective C++ series from Addison-Wesley did that. Yuck. It's probably influenced by The C++ Programming Language. Stroustrup likes it. -- Neil Cerutti -- http://mail.python.org/mailman/listinfo/python-list
Re: 79 chars or more?
Stefan Schwarzer a écrit : Hi Neil, On 2010-08-17 14:42, Neil Cerutti wrote: (snip) Looking through my code, the split-up lines almost always include string literals or elimination of meaningless temporary variables, e.g.: self.expiration_date = translate_date(find(response, 'MPNExpirationDate').text, '%Y-%m-%d', '%m%d%Y') I'd probably reformat this to self.expiration_date = translate_date( find(response, 'MPNExpirationDate').text, '%Y-%m-%d', '%m%d%Y') or even self.expiration_date = translate_date( find(response, 'MPNExpirationDate').text, '%Y-%m-%d', '%m%d%Y') make this : self.expiration_date = translate_date( find(response, 'MPNExpirationDate').text, '%Y-%m-%d', '%m%d%Y' ) I just HATE closing parens on the same line when the args don't fit on one single line. Significant indentation only solves one single issue when it comes to coding conventions war !-) -- http://mail.python.org/mailman/listinfo/python-list
Re: 79 chars or more?
On 2010-08-20, Bruno Desthuilliers bruno.42.desthuilli...@websiteburo.invalid wrote: make this : self.expiration_date = translate_date( find(response, 'MPNExpirationDate').text, '%Y-%m-%d', '%m%d%Y' ) I just HATE closing parens on the same line when the args don't fit on one single line. It's been interesting to see my code scrutinized like this. Thanks all. As a result of the discussion, I changed translate_date to trans_date_from_to to make the order of arguments clear. find is just a small wrapper around Element.find calls, inserting the namespace. -- Neil Cerutti -- http://mail.python.org/mailman/listinfo/python-list
Re: 79 chars or more?
In message mailman.2230.1282037319.1673.python-l...@python.org, Jean-Michel Pichavant wrote: Saying that, if one intend to distribute its code, he should stick to 80 chars per line. Why? -- http://mail.python.org/mailman/listinfo/python-list
Re: 79 chars or more?
Dear Jean-Michel, On Aug 18, 2010, at 10:57 AM, Jean-Michel Pichavant wrote: At least, if you still want to stick with 79 chars, do something like text = find(response, 'MPNExpirationDate', ).text self.expiration_date = translate_date(text,'%Y-%m-%d', '%m%d%Y') I don't necessarily like this example *so* much. I have no real problem with it, and maybe would write it myself sometimes, but I'm curious what people think of the following reasoning. I think that, for optimal readability, variable names should reflect the role if the function/class/module of the variable they refer to. If you stick to this convention, a function can normally be read very easily by just scanning through the left part of assignment statements. In your case, it looks like text would better be called expiration_text, or something like that. But what I would like better, is: self.expiration_date = translate_date( text= find(response, 'MPNExpirationDate', ).text, format1 = '%Y-%m-%d', # I don't know the argument name format2 = '%m%d%Y', # ... and of this one neither ) Moreover, the 'text = ...'-like statement, that are only used in the one statement after it, often interrupt a (more) logical sequence of variable assignments, and make your program a bit less readable. Cheers, Roald -- http://mail.python.org/mailman/listinfo/python-list
Re: 79 chars or more?
On Fri, 20 Aug 2010 15:09:39 +1200, Lawrence D'Oliveiro wrote: In message mailman.2242.1282071458.1673.python-l...@python.org, Terry Reedy wrote: A reason not mentioned much is that some people have trouble following packed lines that are too much longer. Wide-page textbooks routinely put text in two columns for easier reading. But even 79 columns is too wide for them. So what? I think you're wrong. I just opened a random text book at a random page, and the first line I counted had 84 columns of text. (Data Structures and Program Design, 2nd Edition, by Robert L Kruse.) Of course source code is written in a monospaced typeface, which is a little wider and consequently fewer characters per page. The book uses right-justified comments, making it easy to count that the maximum line- width used for source code is 79 columns. Most lines are *much* shorter. Excluding comments, the longest line of code I spotted was 64 columns, with a typical line being more like 40 columns. -- Steven -- http://mail.python.org/mailman/listinfo/python-list
Re: 79 chars or more?
On 08/17/10 12:59, AK wrote: On 08/16/2010 10:42 PM, James Mills wrote: On Tue, Aug 17, 2010 at 12:35 PM, AKandrei@gmail.com wrote: As monitors are getting bigger, is there a general change in opinion on the 79 chars limit in source files? I've experimented with 98 characters per line and I find it quite a bit more comfortable to work with that length, even though sometimes I have to edit files in 80 width terminals, it's still easier to adapt to some inconvenience when that happens than the other way around, since about 95% of time or more, I do use wider editor window or terminal. Is going over 79 still a terrible thing to do? -andrei My personal opinion (despite monitors being wider) is the horizontal scrolling isn't worth it. Stick to a 80-char width. But.. why horizontal scrolling, isn't autowrap much better than that? Do you seriously use autowrapper when writing code? -- http://mail.python.org/mailman/listinfo/python-list
Re: 79 chars or more?
In message i4e4o6$gc...@localhost.localdomain, Martin Gregorie wrote: 1) ssh terminal windows generally come up as 24 x 80 My terminal windows come up by default at something like 40 lines by 100 characters. 2) at 24 x 80 I can get more ssh terminal windows on the desktop with minimal overlap than I can do with longer/wider windows. I have 8 terminal windows open at once, they all fit fine, with room for an Emacs window and whatever else I might occasionally squeeze into there. Hint: I use tabs as well as windows. -- http://mail.python.org/mailman/listinfo/python-list
Re: 79 chars or more?
D'Arcy J.M. Cain wrote: On Tue, 17 Aug 2010 16:28:02 +0200 Stefan Schwarzer sschwar...@sschwarzer.net wrote: I'd probably reformat this to self.expiration_date = translate_date( find(response, 'MPNExpirationDate').text, '%Y-%m-%d', '%m%d%Y') or even self.expiration_date = translate_date( find(response, 'MPNExpirationDate').text, '%Y-%m-%d', '%m%d%Y') You can extend this if there are complicated sub-calls. Probably overkill for this example but here is the idea. self.expiration_date = translate_date( find( response, 'MPNExpirationDate', ).text, '%Y-%m-%d', '%m%d%Y' ) I also moved the closing brace down to align with the line that opened that block. If this is supposed to convice 80+ chars users, that's an epic failure :) This is exactly the kind of layout I'm happy to not use by not caring about the line width. At least, if you still want to stick with 79 chars, do something like text = find(response, 'MPNExpirationDate', ).text self.expiration_date = translate_date(text,'%Y-%m-%d', '%m%d%Y') JM -- http://mail.python.org/mailman/listinfo/python-list
Re: 79 chars or more?
Hi Lie, On 2010-08-18 12:02, Lie Ryan wrote: On 08/17/10 12:59, AK wrote: On 08/16/2010 10:42 PM, James Mills wrote: My personal opinion (despite monitors being wider) is the horizontal scrolling isn't worth it. Stick to a 80-char width. But.. why horizontal scrolling, isn't autowrap much better than that? Do you seriously use autowrapper when writing code? I think he means wrapping on the screen, not actually inserting line breaks. Stefan -- http://mail.python.org/mailman/listinfo/python-list
Re: 79 chars or more?
Roy Smith r...@panix.com wrote in message news:roy-319e47.09055017082...@news.panix.com... In article i4deqq$4e...@lust.ihug.co.nz, Lawrence D'Oliveiro l...@geek-central.gen.new_zealand wrote: In message mailman.2212.1282012525.1673.python-l...@python.org, AK wrote: As monitors are getting bigger, is there a general change in opinion on the 79 chars limit in source files? WHAT 79-character limit in source files? I currently have my Emacs windows set at 100 characters wide, and Iâ?Tm thinking of going wider. Remember, the old hardcopy terminals used to produce 132-character-wide listings. Those of you who think old hardcopy terminals did 132 wide obviously don't remember the ASR-33 :-) ASR33s I think might have been 72 columns wide (and punched cards had a similar restriction). However, lineprinter output was more likely to be 132 columns. -- bartc -- http://mail.python.org/mailman/listinfo/python-list
Re: 79 chars or more?
In message 4c6a9c72.4040...@sschwarzer.net, Stefan Schwarzer wrote: self.expiration_date = translate_date( find(response, 'MPNExpirationDate').text, '%Y-%m-%d', '%m%d%Y') Might I suggest (guessing at the argument keywords here) : self.expiration_date = translate_date \ ( TheText = find(response, 'MPNExpirationDate').text, ToFormat ='%Y-%m-%d', FromFormat ='%m%d%Y' ) Presumably FromFormat should be localizable, rather than hard-coded. See, that’s the kind of thing you notice when you think about the code in this way. -- http://mail.python.org/mailman/listinfo/python-list
Re: 79 chars or more?
In article qkoao.53872$gq5.12...@hurricane, BartC ba...@freeuk.com wrote: Remember, the old hardcopy terminals used to produce 132-character-wide listings. Those of you who think old hardcopy terminals did 132 wide obviously don't remember the ASR-33 :-) ASR33s I think might have been 72 columns wide (and punched cards had a similar restriction). Yeah, I was trying to remember if it was 72 or 80. Hmmm, looks like you're right, it *is* 72 (http://www.pdp8.net/asr33/asr33.shtml). Punched cards (at least the common ones used by an 029 or 129 punch machine) were 80 columns. The 72 column restriction was an artificial one imposed by some programming languages such as Fortran. Columns 73-80 could be used to punch a sequence number, so that if you dropped your deck, you could re-assemble it by running it through a card sorter. However, lineprinter output was more likely to be 132 columns. Yeah, but I wouldn't call a line printer a terminal. -- http://mail.python.org/mailman/listinfo/python-list
Re: 79 chars or more?
In article 4c6b9...@dnews.tpgi.com.au, Lie Ryan lie.1...@gmail.com wrote: On 08/17/10 12:59, AK wrote: On 08/16/2010 10:42 PM, James Mills wrote: On Tue, Aug 17, 2010 at 12:35 PM, AKandrei@gmail.com wrote: As monitors are getting bigger, is there a general change in opinion on the 79 chars limit in source files? I've experimented with 98 characters per line and I find it quite a bit more comfortable to work with that length, even though sometimes I have to edit files in 80 width terminals, it's still easier to adapt to some inconvenience when that happens than the other way around, since about 95% of time or more, I do use wider editor window or terminal. Is going over 79 still a terrible thing to do? -andrei My personal opinion (despite monitors being wider) is the horizontal scrolling isn't worth it. Stick to a 80-char width. But.. why horizontal scrolling, isn't autowrap much better than that? Do you seriously use autowrapper when writing code? I absolutely use auto-indent, parenthesis matching, and syntax coloring. From time to time, I turn on auto-wrap, but generally find it more annoying than useful and turn it back off again. -- http://mail.python.org/mailman/listinfo/python-list
Re: 79 chars or more?
Roy Smith r...@panix.com wrote in message news:roy-181632.07571818082...@news.panix.com... In article qkoao.53872$gq5.12...@hurricane, BartC ba...@freeuk.com wrote: Remember, the old hardcopy terminals used to produce 132-character-wide listings. Those of you who think old hardcopy terminals did 132 wide obviously don't remember the ASR-33 :-) ASR33s I think might have been 72 columns wide (and punched cards had a similar restriction). Yeah, I was trying to remember if it was 72 or 80. Hmmm, looks like you're right, it *is* 72 (http://www.pdp8.net/asr33/asr33.shtml). Punched cards (at least the common ones used by an 029 or 129 punch machine) were 80 columns. The 72 column restriction was an artificial one imposed by some programming languages such as Fortran. Columns 73-80 could be used to punch a sequence number, so that if you dropped your deck, you could re-assemble it by running it through a card sorter. I'm sure there was a continuation column too. That would mean long lines had to be split up, but if the width was longer, that would not be necessary. However, lineprinter output was more likely to be 132 columns. Yeah, but I wouldn't call a line printer a terminal. Source code tended to be perused and marked up on a printout, then corrected at a terminal. So the terminal's width was less important, until fast VDUs came in then printouts were used less, and it made sense to adjust to common 25x80 displays. (I tend to use 60x100 now, sometimes even wider; editing using 25x80 now is like doing keyhole surgery...) -- bartc -- http://mail.python.org/mailman/listinfo/python-list
Re: 79 chars or more?
On 08/18/2010 05:11 AM, Stefan Schwarzer wrote: Hi Lie, On 2010-08-18 12:02, Lie Ryan wrote: On 08/17/10 12:59, AK wrote: On 08/16/2010 10:42 PM, James Mills wrote: My personal opinion (despite monitors being wider) is the horizontal scrolling isn't worth it. Stick to a 80-char width. But.. why horizontal scrolling, isn't autowrap much better than that? Do you seriously use autowrapper when writing code? I think he means wrapping on the screen, not actually inserting line breaks. Stefan Yes, exactly (:set wrap in Vim). -andrei -- http://mail.python.org/mailman/listinfo/python-list
Re: 79 chars or more?
On Wed, 18 Aug 2010 23:18:06 +1200 Lawrence D'Oliveiro l...@geek-central.gen.new_zealand wrote: Might I suggest (guessing at the argument keywords here) : self.expiration_date = translate_date \ ( TheText = find(response, 'MPNExpirationDate').text, ToFormat ='%Y-%m-%d', FromFormat ='%m%d%Y' ) I sometimes use a backslash continuation but it always feels like a failure to me. It's an irrational reaction and I'm not sure why I feel like that. However, if you are going to do it in order to line up the parenthese I would prefer this style. self.expiration_date = translate_date \ ( TheText = find(response, 'MPNExpirationDate').text, ToFormat ='%Y-%m-%d', FromFormat ='%m%d%Y' ) This way you can see not only the block structure at a glance but also the block starter that it is part of. Presumably FromFormat should be localizable, rather than hard-coded. See, that’s the kind of thing you notice when you think about the code in this way. The other thing that jumps out at me is having the input format different than the output format. In any case you need a better date input function. There's no reason in this day and age to force users into a particular input form. You should think about creating a utility function that converts any date that is unambiguous. My scripts generally accept all of the following. Sep 1 2010 september 1, 2010 2010-9-1 (I have never seen Y/D/M format) 2010/9/1 2010 9 1 12/25/2010 25/12/2010 2010/12/25 It fails on the following. sep 31 2010 (impossible) 2010/25/12 (impossible - Y/D/M never happens) 9/1/2010 (ambiguous - there is no consistiency when year is last field) foo (not a date) -- D'Arcy J.M. Cain da...@druid.net | Democracy is three wolves http://www.druid.net/darcy/| and a sheep voting on +1 416 425 1212 (DoD#0082)(eNTP) | what's for dinner. -- http://mail.python.org/mailman/listinfo/python-list
Re: 79 chars or more?
On Wed, 18 Aug 2010 10:57:00 +0200 Jean-Michel Pichavant jeanmic...@sequans.com wrote: D'Arcy J.M. Cain wrote: You can extend this if there are complicated sub-calls. Probably overkill for this example but here is the idea. self.expiration_date = translate_date( find( response, 'MPNExpirationDate', ).text, '%Y-%m-%d', '%m%d%Y' ) I also moved the closing brace down to align with the line that opened that block. If this is supposed to convice 80+ chars users, that's an epic failure :) This is exactly the kind of layout I'm happy to not use by not caring about the line width. As I said above, this was overkill designed to show the idea. Of course I would never split up short calls like that in real code. -- D'Arcy J.M. Cain da...@druid.net | Democracy is three wolves http://www.druid.net/darcy/| and a sheep voting on +1 416 425 1212 (DoD#0082)(eNTP) | what's for dinner. -- http://mail.python.org/mailman/listinfo/python-list
Re: 79 chars or more?
On 2010-08-18, D'Arcy J.M. Cain da...@druid.net wrote: The other thing that jumps out at me is having the input format different than the output format. In any case you need a better date input function. There's no reason in this day and age to force users into a particular input form. You should think about creating a utility function that converts any date that is unambiguous. My scripts generally accept all of the following. Under the hood, translate_date just use strptime and strftime, so the formats are whatever those functions support. Moreover, I'm converting one known format (the one in the XML) to another required format (the one required by another program). There's no need to guess the format. -- Neil Cerutti -- http://mail.python.org/mailman/listinfo/python-list
Re: 79 chars or more?
In message mailman.2212.1282012525.1673.python-l...@python.org, AK wrote: As monitors are getting bigger, is there a general change in opinion on the 79 chars limit in source files? WHAT 79-character limit in source files? I currently have my Emacs windows set at 100 characters wide, and I’m thinking of going wider. Remember, the old hardcopy terminals used to produce 132-character-wide listings. -- http://mail.python.org/mailman/listinfo/python-list
Re: 79 chars or more?
On Aug 17, 6:50 am, AK andrei@gmail.com wrote: On 08/17/2010 12:26 AM, James Mills wrote: By the way, the reason I asked is that we're working on a python tutorial and I realized that even though I'm used to 99, I wasn't sure if it's ok to teach that to new users or not.. -andrei It is certainly NOT useful to teach a convention which is explicitly discouraged in the Python guidelines (PEP 8). Having said that, I particularly *hate* people using long lines, and I usually reindent the code of my coworkers not following that convention. The reason is that my Emacs is set to 79 chars and longer code looks ugly, that I look at two-side diffs all the time, and that sometimes I want to print on paper the code I have to work with. OTOH, I do not see a single advantage in using long lines. Michele Simionato -- http://mail.python.org/mailman/listinfo/python-list
Re: 79 chars or more?
Michele Simionato wrote: On Aug 17, 6:50 am, AK andrei@gmail.com wrote: On 08/17/2010 12:26 AM, James Mills wrote: By the way, the reason I asked is that we're working on a python tutorial and I realized that even though I'm used to 99, I wasn't sure if it's ok to teach that to new users or not.. -andrei It is certainly NOT useful to teach a convention which is explicitly discouraged in the Python guidelines (PEP 8). Having said that, I particularly *hate* people using long lines, and I usually reindent the code of my coworkers not following that convention. The reason is that my Emacs is set to 79 chars and longer code looks ugly, that I look at two-side diffs all the time, and that sometimes I want to print on paper the code I have to work with. OTOH, I do not see a single advantage in using long lines. Michele Simionato Using long lines can sometimes improve readability, procude better shaped code, 'cause wrapping code to 79 chars may not be natural in all cases. We do have a strong habit using meaningfull plain names in our code, no i, j, k ; cmdLine is always replaced by commandLine. So lines can easily exceed 79 chars and wrapping it would'nt be easy. I'm not saying wrapping to 79 is wrong, I'm just saying that they are advantages of using long lines (the 1st obvious one being not to care about wrapping text). Saying that, if one intend to distribute its code, he should stick to 80 chars per line. JM -- http://mail.python.org/mailman/listinfo/python-list
Re: 79 chars or more?
James Mills prolo...@shortcircuit.net.au wrote in message news:mailman..1282019212.1673.python-l...@python.org... On Tue, Aug 17, 2010 at 2:12 PM, AK andrei@gmail.com wrote: There's no doubt that there are pro's and con's, but to be fair, it's not like code becomes unreadable over 79 chars - the difference is that when your terminal is 80 chars, it's less convenient for you to read code that's wider and when your terminal is wider, it's less convenient to read code that's 79 chars. I guess there are two-sides to the coin here so to speak. See I'm vision impaired so I prefer a 79 char width in my own projects That's not a good argument for everyone else to do the same. Someone else might prefer 40 columns for similar reasons. (Anyway can't a 100-column width be squeezed into the same angular field as 80-columns, just by using a narrower font, when necessary? Assuming the problem is field width rather than acuity) The other side is this... I'm of the opinion that if you're writing a line of code that's excessively long (80char or say 100chars), then you might want to reconsider what you're doing :) (It might be wrong). I generally use 100 columns. It's useful for being able to write same-line comments with meaningful content... (I've used 80-column hardware (teletypes and such) years ago, I thought such restrictions had vanished long ago) -- Bartc -- http://mail.python.org/mailman/listinfo/python-list
Re: 79 chars or more?
On 2010-08-17, Michael Torrie torr...@gmail.com wrote: In general if I find myself consistently going longer than 75 or 80 characters, I need to refactor my code to make it more manageable. If I have to scroll up five pages to find the beginning of a block, that normally means my code could be simplified and improved. Looking through my code, the split-up lines almost always include string literals or elimination of meaningless temporary variables, e.g.: self.expiration_date = translate_date(find(response, 'MPNExpirationDate').text, '%Y-%m-%d', '%m%d%Y') The other cases are when indentation levels get the best of me, but I'm too lazy to refactor. -- Neil Cerutti -- http://mail.python.org/mailman/listinfo/python-list
Re: 79 chars or more?
In article i4deqq$4e...@lust.ihug.co.nz, Lawrence D'Oliveiro l...@geek-central.gen.new_zealand wrote: In message mailman.2212.1282012525.1673.python-l...@python.org, AK wrote: As monitors are getting bigger, is there a general change in opinion on the 79 chars limit in source files? WHAT 79-character limit in source files? I currently have my Emacs windows set at 100 characters wide, and Iâm thinking of going wider. Remember, the old hardcopy terminals used to produce 132-character-wide listings. Those of you who think old hardcopy terminals did 132 wide obviously don't remember the ASR-33 :-) -- http://mail.python.org/mailman/listinfo/python-list
Re: 79 chars or more?
On Tue, 17 Aug 2010 13:00:51 +1000, James Mills wrote: Roy, under normal circumstances I would agree with you and have a different opinion. However being vision impaired restricts the available width (irregardless of the width of the monitor) of text I'm able to view at once. I'm with James here because: 1) ssh terminal windows generally come up as 24 x 80 2) at 24 x 80 I can get more ssh terminal windows on the desktop with minimal overlap than I can do with longer/wider windows. BTW, James, would it be a bore to add a space after the two hyphens at the top of your sig, i.e. use -- , not --? That way most news readers will automatically remove your sig when replying to your post. -- martin@ | Martin Gregorie gregorie. | Essex, UK org | -- http://mail.python.org/mailman/listinfo/python-list
Re: 79 chars or more?
Hi Neil, On 2010-08-17 14:42, Neil Cerutti wrote: On 2010-08-17, Michael Torrie torr...@gmail.com wrote: In general if I find myself consistently going longer than 75 or 80 characters, I need to refactor my code to make it more manageable. If I have to scroll up five pages to find the beginning of a block, that normally means my code could be simplified and improved. Looking through my code, the split-up lines almost always include string literals or elimination of meaningless temporary variables, e.g.: self.expiration_date = translate_date(find(response, 'MPNExpirationDate').text, '%Y-%m-%d', '%m%d%Y') I'd probably reformat this to self.expiration_date = translate_date( find(response, 'MPNExpirationDate').text, '%Y-%m-%d', '%m%d%Y') or even self.expiration_date = translate_date( find(response, 'MPNExpirationDate').text, '%Y-%m-%d', '%m%d%Y') for consistency. This not only limits the width but also makes the nesting of the calls more visible. Stefan -- http://mail.python.org/mailman/listinfo/python-list
Re: 79 chars or more?
On 2010-08-17, Stefan Schwarzer sschwar...@sschwarzer.net wrote: Hi Neil, On 2010-08-17 14:42, Neil Cerutti wrote: Looking through my code, the split-up lines almost always include string literals or elimination of meaningless temporary variables, e.g.: self.expiration_date = translate_date(find(response, 'MPNExpirationDate').text, '%Y-%m-%d', '%m%d%Y') I'd probably reformat this to self.expiration_date = translate_date( find(response, 'MPNExpirationDate').text, '%Y-%m-%d', '%m%d%Y') or even self.expiration_date = translate_date( find(response, 'MPNExpirationDate').text, '%Y-%m-%d', '%m%d%Y') for consistency. This not only limits the width but also makes the nesting of the calls more visible. Those are nice improvements. Thanks! -- Neil Cerutti -- http://mail.python.org/mailman/listinfo/python-list
Re: 79 chars or more?
On 08/17/2010 10:28 AM, Stefan Schwarzer wrote: Hi Neil, On 2010-08-17 14:42, Neil Cerutti wrote: On 2010-08-17, Michael Torrietorr...@gmail.com wrote: In general if I find myself consistently going longer than 75 or 80 characters, I need to refactor my code to make it more manageable. If I have to scroll up five pages to find the beginning of a block, that normally means my code could be simplified and improved. Looking through my code, the split-up lines almost always include string literals or elimination of meaningless temporary variables, e.g.: self.expiration_date = translate_date(find(response, 'MPNExpirationDate').text, '%Y-%m-%d', '%m%d%Y') I'd probably reformat this to self.expiration_date = translate_date( find(response, 'MPNExpirationDate').text, '%Y-%m-%d', '%m%d%Y') or even self.expiration_date = translate_date( find(response, 'MPNExpirationDate').text, '%Y-%m-%d', '%m%d%Y') for consistency. This not only limits the width but also makes the nesting of the calls more visible. Stefan Doesn't this create the problem of functions growing too long to fit in a screen? I think it's very useful to try to keep function size low enough so that you can view the whole function without having to scroll up and down. (even though that's not always possible) -ak -- http://mail.python.org/mailman/listinfo/python-list
Re: 79 chars or more?
On Tue, 17 Aug 2010 16:28:02 +0200 Stefan Schwarzer sschwar...@sschwarzer.net wrote: I'd probably reformat this to self.expiration_date = translate_date( find(response, 'MPNExpirationDate').text, '%Y-%m-%d', '%m%d%Y') or even self.expiration_date = translate_date( find(response, 'MPNExpirationDate').text, '%Y-%m-%d', '%m%d%Y') You can extend this if there are complicated sub-calls. Probably overkill for this example but here is the idea. self.expiration_date = translate_date( find( response, 'MPNExpirationDate', ).text, '%Y-%m-%d', '%m%d%Y' ) I also moved the closing brace down to align with the line that opened that block. -- D'Arcy J.M. Cain da...@druid.net | Democracy is three wolves http://www.druid.net/darcy/| and a sheep voting on +1 416 425 1212 (DoD#0082)(eNTP) | what's for dinner. -- http://mail.python.org/mailman/listinfo/python-list
Re: 79 chars or more?
On 2010-08-17 17:44, AK wrote: On 08/17/2010 10:28 AM, Stefan Schwarzer wrote: I'd probably reformat this to self.expiration_date = translate_date( find(response, 'MPNExpirationDate').text, '%Y-%m-%d', '%m%d%Y') or even self.expiration_date = translate_date( find(response, 'MPNExpirationDate').text, '%Y-%m-%d', '%m%d%Y') for consistency. This not only limits the width but also makes the nesting of the calls more visible. Doesn't this create the problem of functions growing too long to fit in a screen? I think it's very useful to try to keep function size low enough so that you can view the whole function without having to scroll up and down. (even though that's not always possible) -ak I think I'd extract some part of the function into a new function then. In my opinion, the reasoning is similar to the case, Can't I use two spaces per indentation level? That way I don't run so easily into the right margin if I have more than five indentations in a function. ;-) Stefan -- http://mail.python.org/mailman/listinfo/python-list
Re: 79 chars or more?
On 08/17/2010 12:21 PM, Stefan Schwarzer wrote: On 2010-08-17 17:44, AK wrote: On 08/17/2010 10:28 AM, Stefan Schwarzer wrote: I'd probably reformat this to self.expiration_date = translate_date( find(response, 'MPNExpirationDate').text, '%Y-%m-%d', '%m%d%Y') or even self.expiration_date = translate_date( find(response, 'MPNExpirationDate').text, '%Y-%m-%d', '%m%d%Y') for consistency. This not only limits the width but also makes the nesting of the calls more visible. Doesn't this create the problem of functions growing too long to fit in a screen? I think it's very useful to try to keep function size low enough so that you can view the whole function without having to scroll up and down. (even though that's not always possible) -ak I think I'd extract some part of the function into a new function then. In my opinion, the reasoning is similar to the case, Can't I use two spaces per indentation level? That way I don't run so easily into the right margin if I have more than five indentations in a function. ;-) I think to some extent it's a matter of taste. I bet most people would agree that on the balance, 2-space indentations makes code much less readable, despite saving a bit of space. But let me ask you, would you really prefer to have: self.expiration_date = translate_date( find(response, 'MPNExpirationDate').text, '%Y-%m-%d', '%m%d%Y') (or the 4-line version of this above), even when it necessitates creation of a new function, rather than have this code on two lines? After all, I think it's a matter of balance between readability, expressiveness and succinctness. If I split a function in two, that still means that understanding the functionality of the code will require scrolling around and looking at the second function. I guess what I'm trying to say that we shouldn't just care about readability of lines but also readability of functions and blocks of functionality (that may include several functions that accomplish a single task.) -andrei -- http://mail.python.org/mailman/listinfo/python-list
Re: 79 chars or more?
On 2010-08-17, AK andrei@gmail.com wrote: After all, I think it's a matter of balance between readability, expressiveness and succinctness. If I split a function in two, that still means that understanding the functionality of the code will require scrolling around and looking at the second function. I guess what I'm trying to say that we shouldn't just care about readability of lines but also readability of functions and blocks of functionality (that may include several functions that accomplish a single task.) When considering creating variables and functions, I try to use the same rule of thumb: If I can come up with a good name for it relatively quickly, then it probably deserves to exist. If all I can think of is 'func' or 'x', then it's an artifact that I hope to avoid. Splitting a function in two need not obscure the meaning, and may even improve it, *if* the names of the new functions are good. -- Neil Cerutti -- http://mail.python.org/mailman/listinfo/python-list
Re: 79 chars or more?
On 17 August 2010 18:43, AK andrei@gmail.com wrote: On 08/17/2010 12:21 PM, Stefan Schwarzer wrote: On 2010-08-17 17:44, AK wrote: On 08/17/2010 10:28 AM, Stefan Schwarzer wrote: I'd probably reformat this to self.expiration_date = translate_date( find(response, 'MPNExpirationDate').text, '%Y-%m-%d', '%m%d%Y') or even self.expiration_date = translate_date( find(response, 'MPNExpirationDate').text, '%Y-%m-%d', '%m%d%Y') for consistency. This not only limits the width but also makes the nesting of the calls more visible. Doesn't this create the problem of functions growing too long to fit in a screen? I think it's very useful to try to keep function size low enough so that you can view the whole function without having to scroll up and down. (even though that's not always possible) -ak I think I'd extract some part of the function into a new function then. In my opinion, the reasoning is similar to the case, Can't I use two spaces per indentation level? That way I don't run so easily into the right margin if I have more than five indentations in a function. ;-) I think to some extent it's a matter of taste. I bet most people would agree that on the balance, 2-space indentations makes code much less readable, despite saving a bit of space. But let me ask you, would you really prefer to have: self.expiration_date = translate_date( find(response, 'MPNExpirationDate').text, '%Y-%m-%d', '%m%d%Y') (or the 4-line version of this above), even when it necessitates creation of a new function, rather than have this code on two lines? After all, I think it's a matter of balance between readability, expressiveness and succinctness. If I split a function in two, that still means that understanding the functionality of the code will require scrolling around and looking at the second function. I guess what I'm trying to say that we shouldn't just care about readability of lines but also readability of functions and blocks of functionality (that may include several functions that accomplish a single task.) -andrei -- http://mail.python.org/mailman/listinfo/python-list I am in favor of the 80-char limit also. Besides the arguments listed above, when using an IDE it gives you that extra horizontal space to fit some IDE specific tools (such as source structure). I must admit that I'm sometimes slightly frustrated when an expression is JUST 81 chars, and I *need* to reformat to two lines. On the other hand, very long lines are hard to read also. I guess the limit must be placed somewhere, and for historical reasons, 80 chars makes the most sense IMO. On a related note, why is the limit mentioned in PEP8 79 chars, and not 80? I never understood this :) Cheers, Almar -- http://mail.python.org/mailman/listinfo/python-list
Re: 79 chars or more?
On 8/17/2010 2:26 PM, Almar Klein wrote: On a related note, why is the limit mentioned in PEP8 79 chars, and not 80? I never understood this :) A newline char or block or underline cursor makes 80. The importance depended on the terminal. 80 chars on the last line could especially be a problem. -- Terry Jan Reedy -- http://mail.python.org/mailman/listinfo/python-list
Re: 79 chars or more?
Almar Klein wrote: [snip] I am in favor of the 80-char limit also. Besides the arguments listed above, when using an IDE it gives you that extra horizontal space to fit some IDE specific tools (such as source structure). I must admit that I'm sometimes slightly frustrated when an expression is JUST 81 chars, and I *need* to reformat to two lines. On the other hand, very long lines are hard to read also. I guess the limit must be placed somewhere, and for historical reasons, 80 chars makes the most sense IMO. On a related note, why is the limit mentioned in PEP8 79 chars, and not 80? I never understood this :) If the display is limited to 80 characters then after printing the 80th the cursor will be at the start of the next line and the newline will cause the display to leave a blank line (unless the display has some intelligence and supports pending newlines, of course). -- http://mail.python.org/mailman/listinfo/python-list
Re: 79 chars or more?
On 8/17/2010 3:47 AM, Lawrence D'Oliveiro wrote: In messagemailman.2212.1282012525.1673.python-l...@python.org, AK wrote: As monitors are getting bigger, is there a general change in opinion on the 79 chars limit in source files? WHAT 79-character limit in source files? Only for stdlib. Python itself has no particular limit. The dev discussed the issue perhaps a year ago. Enough people wanted or needed the current stdlib limit that they decided to stick with it. A reason not mentioned much is that some people have trouble following packed lines that are too much longer. Wide-page textbooks routinely put text in two columns for easier reading. This is less of a factor with jagged edge text, but if the limit were increased to say 150, there would be people writing multi-line 150 char wide text blocks. -- Terry Jan Reedy -- http://mail.python.org/mailman/listinfo/python-list
Re: 79 chars or more?
A reason not mentioned much is that some people have trouble following packed lines that are too much longer. Wide-page textbooks routinely put text in two columns for easier reading. This is less of a factor with jagged edge text, but if the limit were increased to say 150, there would be people writing multi-line 150 char wide text blocks. You're right. From Lshort (the introduction to Latex): On average, no line should be longer than 66 characters. This applies to regular text, not for code per see, but it makes a strong case against (very) long lines. Almar -- http://mail.python.org/mailman/listinfo/python-list
Re: 79 chars or more?
If the display is limited to 80 characters then after printing the 80th the cursor will be at the start of the next line and the newline will cause the display to leave a blank line (unless the display has some intelligence and supports pending newlines, of course). Ahah! So Windows users should actually limit their text to 78 chars? :) -- http://mail.python.org/mailman/listinfo/python-list
Re: 79 chars or more?
Hi Andrei, On 2010-08-17 18:43, AK wrote: But let me ask you, would you really prefer to have: self.expiration_date = translate_date( find(response, 'MPNExpirationDate').text, '%Y-%m-%d', '%m%d%Y') (or the 4-line version of this above), even when it necessitates creation of a new function, rather than have this code on two lines? Given that the reformatted code is three lines and the former code two lines, I probably wouldn't change anything but the formatting as shown. :) After all, I think it's a matter of balance between readability, expressiveness and succinctness. If I split a function in two, that still means that understanding the functionality of the code will require scrolling around and looking at the second function. I guess what I'm trying to say that we shouldn't just care about readability of lines but also readability of functions and blocks of functionality (that may include several functions that accomplish a single task.) I think you're right here; you should keep the overall readability or (maintainability on the whole) in mind. I agree with Neil that good refactoring can _improve_ the understandability of the code, and it won't necessarily require you to look up the code of the extracted function or method. Stefan -- http://mail.python.org/mailman/listinfo/python-list
Re: 79 chars or more?
On 08/17/2010 03:32 PM, Stefan Schwarzer wrote: Hi Andrei, On 2010-08-17 18:43, AK wrote: But let me ask you, would you really prefer to have: self.expiration_date = translate_date( find(response, 'MPNExpirationDate').text, '%Y-%m-%d', '%m%d%Y') (or the 4-line version of this above), even when it necessitates creation of a new function, rather than have this code on two lines? Given that the reformatted code is three lines and the former code two lines, I probably wouldn't change anything but the formatting as shown. :) After all, I think it's a matter of balance between readability, expressiveness and succinctness. If I split a function in two, that still means that understanding the functionality of the code will require scrolling around and looking at the second function. I guess what I'm trying to say that we shouldn't just care about readability of lines but also readability of functions and blocks of functionality (that may include several functions that accomplish a single task.) I think you're right here; you should keep the overall readability or (maintainability on the whole) in mind. I agree with Neil that good refactoring can _improve_ the understandability of the code, and it won't necessarily require you to look up the code of the extracted function or method. I can certainly agree with that - although this sort of refactoring (when I do it) is driven by the logic of the code rather than the need to spread a long line over several lines :-). -andrei -- http://mail.python.org/mailman/listinfo/python-list
Re: 79 chars or more?
On Mon, 16 Aug 2010 22:35:49 -0400, AK wrote: As monitors are getting bigger, is there a general change in opinion on the 79 chars limit in source files? I've experimented with 98 characters per line and I find it quite a bit more comfortable to work with that length, even though sometimes I have to edit files in 80 width terminals, it's still easier to adapt to some inconvenience when that happens than the other way around, since about 95% of time or more, I do use wider editor window or terminal. Is going over 79 still a terrible thing to do? -andrei If the the limit isn't 79, then what is it? Or are 1000-column lines okay? Often, simply having a convention is more important than the precise details. E.g. I don't particularly care how I configure my text editor's auto-formatting settings, but I do care about not having to change those settings for each file. For code which will never be read or edited by anyone other than yourself, use whatever conventions you want. If you're going to publish the code, it's a good idea to stick to established standards (80-column lines, 8-column tabs, no gratuitous use of non-ASCII characters, etc). Apart from altruistic reasons, bear in mind that the next time you apply for a job, the employer may look at your code not just to determine your programming competence, but also whether you're likely to be a team player. Code which doesn't follow normal conventions says I've only ever worked on my own, not with other people. I can't stress enough how big a factor this is. Writing code by yourself and working as part of a team are almost entirely different skills. Anyone who regularly hires programmers will be only too aware of the difference. -- http://mail.python.org/mailman/listinfo/python-list
Re: 79 chars or more?
On Tue, Aug 17, 2010 at 12:35 PM, AK andrei@gmail.com wrote: As monitors are getting bigger, is there a general change in opinion on the 79 chars limit in source files? I've experimented with 98 characters per line and I find it quite a bit more comfortable to work with that length, even though sometimes I have to edit files in 80 width terminals, it's still easier to adapt to some inconvenience when that happens than the other way around, since about 95% of time or more, I do use wider editor window or terminal. Is going over 79 still a terrible thing to do? -andrei My personal opinion (despite monitors being wider) is the horizontal scrolling isn't worth it. Stick to a 80-char width. cheers james -- -- James Mills -- -- Problems are solved by method -- http://mail.python.org/mailman/listinfo/python-list
Re: 79 chars or more?
In article mailman.2213.1282012961.1673.python-l...@python.org, James Mills prolo...@shortcircuit.net.au wrote: On Tue, Aug 17, 2010 at 12:35 PM, AK andrei@gmail.com wrote: As monitors are getting bigger, is there a general change in opinion on the 79 chars limit in source files? I've experimented with 98 characters per line and I find it quite a bit more comfortable to work with that length, even though sometimes I have to edit files in 80 width terminals, it's still easier to adapt to some inconvenience when that happens than the other way around, since about 95% of time or more, I do use wider editor window or terminal. Is going over 79 still a terrible thing to do? Â -andrei My personal opinion (despite monitors being wider) is the horizontal scrolling isn't worth it. Stick to a 80-char width. I disagree with James. I have no problem with going wider than 80, if it improves readability by not forcing you to fold lines in unnatural places. There's more important things to worry about. -- http://mail.python.org/mailman/listinfo/python-list
Re: 79 chars or more?
On 08/16/2010 10:42 PM, James Mills wrote: On Tue, Aug 17, 2010 at 12:35 PM, AKandrei@gmail.com wrote: As monitors are getting bigger, is there a general change in opinion on the 79 chars limit in source files? I've experimented with 98 characters per line and I find it quite a bit more comfortable to work with that length, even though sometimes I have to edit files in 80 width terminals, it's still easier to adapt to some inconvenience when that happens than the other way around, since about 95% of time or more, I do use wider editor window or terminal. Is going over 79 still a terrible thing to do? -andrei My personal opinion (despite monitors being wider) is the horizontal scrolling isn't worth it. Stick to a 80-char width. But.. why horizontal scrolling, isn't autowrap much better than that? -andrei -- http://mail.python.org/mailman/listinfo/python-list
Re: 79 chars or more?
On Tue, Aug 17, 2010 at 12:50 PM, Roy Smith r...@panix.com wrote: I disagree with James. I have no problem with going wider than 80, if it improves readability by not forcing you to fold lines in unnatural places. There's more important things to worry about. Roy, under normal circumstances I would agree with you and have a different opinion. However being vision impaired restricts the available width (irregardless of the width of the monitor) of text I'm able to view at once. :) cheers James -- -- James Mills -- -- Problems are solved by method -- http://mail.python.org/mailman/listinfo/python-list
Re: 79 chars or more?
On Mon, 16 Aug 2010 22:35:49 -0400, AK wrote: As monitors are getting bigger, is there a general change in opinion on the 79 chars limit in source files? I've experimented with 98 characters per line and I find it quite a bit more comfortable to work with that length, even though sometimes I have to edit files in 80 width terminals, it's still easier to adapt to some inconvenience when that happens than the other way around, since about 95% of time or more, I do use wider editor window or terminal. Is going over 79 still a terrible thing to do? -andrei For your own code, you are free to do anything you like :) But if you want to submit code to the Python standard library, you have to restrict lines to 79 characters. This is no different from any other project -- you need to stick to the project's coding conventions. There are still good reasons to stick with 79 chars, even on large screen monitors. People with poor vision will appreciate being able to increase the font size. Others might like to have two windows side-by-side, each showing 79 characters. Some people don't have wide monitors. -- Steven -- http://mail.python.org/mailman/listinfo/python-list
Re: 79 chars or more?
On 08/16/2010 11:51 PM, Steven D'Aprano wrote: On Mon, 16 Aug 2010 22:35:49 -0400, AK wrote: As monitors are getting bigger, is there a general change in opinion on the 79 chars limit in source files? I've experimented with 98 characters per line and I find it quite a bit more comfortable to work with that length, even though sometimes I have to edit files in 80 width terminals, it's still easier to adapt to some inconvenience when that happens than the other way around, since about 95% of time or more, I do use wider editor window or terminal. Is going over 79 still a terrible thing to do? -andrei For your own code, you are free to do anything you like :) But if you want to submit code to the Python standard library, you have to restrict lines to 79 characters. This is no different from any other project -- you need to stick to the project's coding conventions. There are still good reasons to stick with 79 chars, even on large screen monitors. People with poor vision will appreciate being able to increase the font size. Others might like to have two windows side-by-side, each showing 79 characters. Some people don't have wide monitors. There's no doubt that there are pro's and con's, but to be fair, it's not like code becomes unreadable over 79 chars - the difference is that when your terminal is 80 chars, it's less convenient for you to read code that's wider and when your terminal is wider, it's less convenient to read code that's 79 chars. I guess I'm just curious what percentage of people prefer 79chars - is it 5/95% or 15/85% or 50/50? -andrei -- http://mail.python.org/mailman/listinfo/python-list
Re: 79 chars or more?
On Tue, Aug 17, 2010 at 2:12 PM, AK andrei@gmail.com wrote: There's no doubt that there are pro's and con's, but to be fair, it's not like code becomes unreadable over 79 chars - the difference is that when your terminal is 80 chars, it's less convenient for you to read code that's wider and when your terminal is wider, it's less convenient to read code that's 79 chars. I guess there are two-sides to the coin here so to speak. See I'm vision impaired so I prefer a 79 char width in my own projects and expect those that work with me to use the same standards (stick to project standards as Steven says). The other side is this... I'm of the opinion that if you're writing a line of code that's excessively long (80char or say 100chars), then you might want to reconsider what you're doing :) (It might be wrong). cheers james -- -- James Mills -- -- Problems are solved by method -- http://mail.python.org/mailman/listinfo/python-list
Re: 79 chars or more?
On 08/17/2010 12:26 AM, James Mills wrote: On Tue, Aug 17, 2010 at 2:12 PM, AKandrei@gmail.com wrote: There's no doubt that there are pro's and con's, but to be fair, it's not like code becomes unreadable over 79 chars - the difference is that when your terminal is 80 chars, it's less convenient for you to read code that's wider and when your terminal is wider, it's less convenient to read code that's 79 chars. I guess there are two-sides to the coin here so to speak. See I'm vision impaired so I prefer a 79 char width in my own projects and expect those that work with me to use the same standards (stick to project standards as Steven says). The other side is this... I'm of the opinion that if you're writing a line of code that's excessively long (80char or say100chars), then you might want to reconsider what you're doing :) (It might be wrong). I stay away from ugly cramped one-liners; I mostly run over 79 when I have a few `and` and `or` clauses or long strings. I've also noticed something interesting: going from 79 to 99 affects a relatively large number of lines, but going over 99 (i.e. 99 to 132) is much, much rarer. By the way, the reason I asked is that we're working on a python tutorial and I realized that even though I'm used to 99, I wasn't sure if it's ok to teach that to new users or not.. -andrei -- http://mail.python.org/mailman/listinfo/python-list
Re: 79 chars or more?
On Tue, Aug 17, 2010 at 2:50 PM, AK andrei@gmail.com wrote: By the way, the reason I asked is that we're working on a python tutorial and I realized that even though I'm used to 99, I wasn't sure if it's ok to teach that to new users or not.. In my opinion it would be okay to teach. However: Bare in mind other considerations for smaller width conventions and the reasons for them. Make your students aware of standards and get them into the habit of following standards early on. cheers James -- -- James Mills -- -- Problems are solved by method -- http://mail.python.org/mailman/listinfo/python-list
Re: 79 chars or more?
On 08/16/2010 08:59 PM, AK wrote: But.. why horizontal scrolling, isn't autowrap much better than that? Wouldn't it really make a visual mess of Python code if lines wrapped? Maybe if they wrapped smartly. In general, the only time I find my lines longer than 75 characters are strings or sometimes conditionals for if statements. But normally I can wrap them manually so that things look neat and tidy. In general if I find myself consistently going longer than 75 or 80 characters, I need to refactor my code to make it more manageable. If I have to scroll up five pages to find the beginning of a block, that normally means my code could be simplified and improved. -- http://mail.python.org/mailman/listinfo/python-list
Re: 79 chars or more?
On 08/16/2010 10:50 PM, AK wrote: I stay away from ugly cramped one-liners; I mostly run over 79 when I have a few `and` and `or` clauses or long strings. I've also noticed something interesting: going from 79 to 99 affects a relatively large number of lines, but going over 99 (i.e. 99 to 132) is much, much rarer. I have found something similar, despite my previous post. But you can normally break the and and or long clauses with backslash line-continuators. You can also break strings similarly: a = This is a really long line that ordinarily would \ be long. Test message: %s % ( message_string) By the way, the reason I asked is that we're working on a python tutorial and I realized that even though I'm used to 99, I wasn't sure if it's ok to teach that to new users or not.. I wouldn't worry about it if I were you. Once they know how to program in Python then you can work on that. Probably more important to be taught the reasons behind PEP8. You could probably say that many coders recommend that lines not exceed 80 characters, and state that code in the standard library has to be less than that, but that on occasion longer lines are probably not going to kill them. -- http://mail.python.org/mailman/listinfo/python-list
