FAQ
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

Search Discussions

  • James Mills at Aug 17, 2010 at 2:42 am

    On Tue, Aug 17, 2010 at 12:35 PM, 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
    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"
  • AK at Aug 17, 2010 at 2:59 am

    On 08/16/2010 10:42 PM, James Mills wrote:
    On Tue, Aug 17, 2010 at 12:35 PM, AKwrote:
    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
  • Michael Torrie at Aug 17, 2010 at 5:15 am

    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.
  • Neil Cerutti at Aug 17, 2010 at 12:42 pm

    On 2010-08-17, Michael Torrie 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
  • Stefan Schwarzer at Aug 17, 2010 at 2:28 pm
    Hi Neil,
    On 2010-08-17 14:42, Neil Cerutti wrote:
    On 2010-08-17, Michael Torrie 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
  • Neil Cerutti at Aug 17, 2010 at 3:31 pm

    On 2010-08-17, Stefan Schwarzer 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
  • D'Arcy J.M. Cain at Aug 17, 2010 at 3:42 pm

    On Tue, 17 Aug 2010 16:28:02 +0200 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')
    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 <darcy at 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.
  • Jean-Michel Pichavant at Aug 18, 2010 at 8:57 am

    D'Arcy J.M. Cain wrote:
    On Tue, 17 Aug 2010 16:28:02 +0200
    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')
    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
  • D'Arcy J.M. Cain at Aug 18, 2010 at 2:49 pm

    On Wed, 18 Aug 2010 10:57:00 +0200 Jean-Michel Pichavant 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 <darcy at 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.
  • Roald de Vries at Aug 19, 2010 at 2:42 pm
    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
  • AK at Aug 17, 2010 at 3:44 pm

    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 Torriewrote:
    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
  • Stefan Schwarzer at Aug 17, 2010 at 4:21 pm

    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
  • AK at Aug 17, 2010 at 4:43 pm

    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
  • Almar Klein at Aug 17, 2010 at 6:26 pm

    On 17 August 2010 18:43, AK 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
    -------------- next part --------------
    An HTML attachment was scrubbed...
    URL: <http://mail.python.org/pipermail/python-list/attachments/20100817/b85376e9/attachment.html>
  • Terry Reedy at Aug 17, 2010 at 6:47 pm

    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
  • MRAB at Aug 17, 2010 at 6:56 pm
    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).
  • Almar Klein at Aug 17, 2010 at 7:33 pm

    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? :)
    -------------- next part --------------
    An HTML attachment was scrubbed...
    URL: <http://mail.python.org/pipermail/python-list/attachments/20100817/cac7df9f/attachment.html>
  • Neil Cerutti at Aug 17, 2010 at 5:07 pm

    On 2010-08-17, AK 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
  • Stefan Schwarzer at Aug 17, 2010 at 7:32 pm
    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
  • AK at Aug 17, 2010 at 7:54 pm

    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
  • Lawrence D'Oliveiro at Aug 18, 2010 at 11:18 am

    In message <4C6A9C72.4040708 at 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.
  • D'Arcy J.M. Cain at Aug 18, 2010 at 2:38 pm

    On Wed, 18 Aug 2010 23:18:06 +1200 Lawrence D'Oliveiro 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 <darcy at 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.
  • Neil Cerutti at Aug 18, 2010 at 5:37 pm

    On 2010-08-18, D'Arcy J.M. Cain 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
  • Bruno Desthuilliers at Aug 20, 2010 at 1:56 pm

    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 !-)
  • Neil Cerutti at Aug 20, 2010 at 2:00 pm

    On 2010-08-20, Bruno Desthuilliers 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
  • Lie Ryan at Aug 18, 2010 at 10:02 am

    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, AKwrote:
    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?
  • Stefan Schwarzer at Aug 18, 2010 at 9:11 am
    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
  • AK at Aug 18, 2010 at 2:01 pm

    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
  • Roy Smith at Aug 18, 2010 at 12:00 pm

    In article <4c6b956e at dnews.tpgi.com.au>, Lie Ryan 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, AKwrote:
    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.
  • Roy Smith at Aug 17, 2010 at 2:50 am
    In article <mailman.2213.1282012961.1673.python-list at python.org>,
    James Mills wrote:
    On Tue, Aug 17, 2010 at 12:35 PM, 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
    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.
  • James Mills at Aug 17, 2010 at 3:00 am

    On Tue, Aug 17, 2010 at 12:50 PM, Roy Smith 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"
  • Martin Gregorie at Aug 17, 2010 at 2:01 pm

    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 |
  • Lawrence D'Oliveiro at Aug 18, 2010 at 8:16 am

    In message <i4e4o6$gc1$1 at 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.
  • Steven D'Aprano at Aug 17, 2010 at 3:51 am

    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
  • AK at Aug 17, 2010 at 4:12 am

    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

  • James Mills at Aug 17, 2010 at 4:26 am

    On Tue, Aug 17, 2010 at 2:12 PM, AK 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"
  • AK at Aug 17, 2010 at 4:50 am

    On 08/17/2010 12:26 AM, James Mills wrote:
    On Tue, Aug 17, 2010 at 2:12 PM, AKwrote:
    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).
    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
  • James Mills at Aug 17, 2010 at 5:08 am

    On Tue, Aug 17, 2010 at 2:50 PM, AK 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"
  • Michael Torrie at Aug 17, 2010 at 5:20 am

    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.
  • Michele Simionato at Aug 17, 2010 at 7:59 am

    On Aug 17, 6:50?am, AK 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
  • Jean-Michel Pichavant at Aug 17, 2010 at 9:28 am

    Michele Simionato wrote:
    On Aug 17, 6:50 am, AK 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
  • Lawrence D'Oliveiro at Aug 21, 2010 at 3:19 am
    In message
    <mailman.2230.1282037319.1673.python-list at python.org>, Jean-Michel Pichavant
    wrote:
    Saying that, if one intend to distribute its code, he should stick to 80
    chars per line.
    Why?
  • Jean-Michel Pichavant at Aug 24, 2010 at 9:29 am

    Lawrence D'Oliveiro wrote:
    In message
    <mailman.2230.1282037319.1673.python-list at 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
  • Lawrence D'Oliveiro at Aug 24, 2010 at 10:13 am
    In message <mailman.0.1282642167.29448.python-list at python.org>, Jean-Michel
    Pichavant wrote:
    Lawrence D'Oliveiro wrote:
    In message
    <mailman.2230.1282037319.1673.python-list at 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?
  • BartC at Aug 17, 2010 at 10:50 am
    "James Mills" <prologic at shortcircuit.net.au> wrote in message
    news:mailman.2222.1282019212.1673.python-list at python.org...
    On Tue, Aug 17, 2010 at 2:12 PM, AK 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
  • Lawrence D'Oliveiro at Aug 17, 2010 at 7:47 am

    In message <mailman.2212.1282012525.1673.python-list at 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.
  • Roy Smith at Aug 17, 2010 at 1:05 pm
    In article <i4deqq$4em$2 at lust.ihug.co.nz>,
    Lawrence D'Oliveiro wrote:
    In message <mailman.2212.1282012525.1673.python-list at 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 :-)
  • BartC at Aug 18, 2010 at 10:38 am
    "Roy Smith" <roy at panix.com> wrote in message
    news:roy-319E47.09055017082010 at news.panix.com...
    In article <i4deqq$4em$2 at lust.ihug.co.nz>,
    Lawrence D'Oliveiro wrote:
    In message <mailman.2212.1282012525.1673.python-list at 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
  • Roy Smith at Aug 18, 2010 at 11:57 am
    In article <QKOao.53872$GQ5.12210 at hurricane>,
    "BartC" 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".
  • BartC at Aug 18, 2010 at 1:34 pm
    "Roy Smith" <roy at panix.com> wrote in message
    news:roy-181632.07571818082010 at news.panix.com...
    In article <QKOao.53872$GQ5.12210 at hurricane>,
    "BartC" 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

Related Discussions

People

Translate

site design / logo © 2022 Grokbase