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
