PEP 8 update on line length
Hello, I'd like to propose an update to PEP8. Indeed, the 80 characters per line guideline is, I feel, outdated. I understand the need for it, back when monitors were small, and everyone coded on terminals, but nowadays, I feel like that guideline is more of a hinderance, and that it promotes poor code. Indeed, people abiding by this rule tend to choose shorter variable names, reduce the amount of indentation, and other tricks to just keep the character count under 80. I think a 100 or even 120 suggested characters per line count is much more realistic by today's standards. It still allow for the code to be completely displayed, even on just half of a screen.
You either have much better eyes to read tiny fonts than I do, or maybe a much larger monitor (it's hard for me to fit a 30"" monitor in my laptop bag). But that's not even the real issue. If the characters were in giant letters on billboards, I still would never want more than 80 of them on a line (well, rarely, I violate PEP 8 sometimes). Centuries if not millennia of experience with writing show that cognitive burden goes up exponentially, not linearly, as lines get to be more than about 60 characters. This is why it's not just code on screen. Magazines, books, wall signs, billboards, and every other written form, insists on similar limits on line length. In printed matter this often means using multiple columns to avoid overly long lines. The issue isn't resolution or size, it's that the human brain simply doesn't process long lines of text will. On Mon, Feb 18, 2019, 11:38 PM Simon <simon.bordeyne@gmail.com wrote:
If that is the issue then we should be talking about non-space characters, not a 68 column limit right? No way does 40 spaces due to indent count towards the cognitive burden :) Also, if the cognitive burden is the issue then we should talk about short forms for keyword arguments again. The way the 68 column limit works in practice is that people avoid keyword arguments because of line length, plus the issues already mentioned. / Anders
From: Python-ideas <python-ideas-bounces+gadgetsteve=live.co.uk@python.org> On Behalf Of Anders Hovmöller Sent: 19 February 2019 06:11 To: David Mertz <mertz@gnosis.cx> Cc: Simon <simon.bordeyne@gmail.com>; python-ideas <python-ideas@python.org> Subject: Re: [Python-ideas] PEP 8 update on line length
If that is the issue then we should be talking about non-space characters, not a 68 column limit right? No way does 40 spaces due to indent count towards the cognitive burden :) Also, if the cognitive burden is the issue then we should talk about short forms for keyword arguments again. The way the 68 column limit works in practice is that people avoid keyword arguments because of line length, plus the issues already mentioned. / Anders [Steve Barnes] If you are getting to 40 spaces of indent, (for _most_ people that is 10 scope changes, e.g. fn then 9 levels of if), then you are already facing a major cognitive burden and should probably be refactoring.
60, or 68, or 80 characters, is not per se a cognitive limit. Yes, sure whitespace counts much less towards that burden than do regular characters. And to a significant degrees, punctuation vs. letters vs. numbers matter. And sure familiar words such as keywords scan a bit easier than unfamiliar names of variables. And so on. But 80 characters in general is already too wide most of the time. 65 is a better goal as a rule of thumb, with 80 already being for exceptionally long lines. Python keywords are already short, there's not much improvement to be had there. Saving two characters for acryptic WHL isn't better than the word 'while', for example. Pretty much the only time my code how's more than 80 characters is when it includes string literally that occupy a large chunk of the width. But if that 50 character string is the last argument of a function call, the reader can mostly stop scanning at it's beginning, so it's not terrible. When I have many keyword arguments, I break them into multiple physical lines using parents too continue the logical line. Or if I have complex compound conditions, I give the subclauses short but descriptive names before the if/elif. On Tue, Feb 19, 2019, 1:11 AM Anders Hovmöller <boxed@killingar.net wrote:
I find that 100 to 120 characters is ideal as far as line length goes. In my opinion, splitting lines is much worse in terms of cognitive burden than just a longer line. On top of that, it's not uncommon to reach 6, even 7 indentation levels. All it takes is a loop in a loop (looping through an array for instance), a condition and all of that inside a class' method. Just in that example, which is a very common occurence, an doesn't warrant refactoring, there is 5 indentation level, eg a quarter of the recommended line length. Defining decorators also goes up there in terms of number of indents by the way. As far as monitor size goes, I agree that on a laptop is not ideal for 100+ characters per line if you want two pieces of code side by side. And, fyi, I work on a 23" monitor at home and on a 15.6" monitor on the go. Both are perfectly fine with 100 characters a line. A good middle ground would be to enforce customization of that rule in the most used python linters. A simple setting to set the number of characters before a linting warning occurs would be acceptable. Envoyé depuis mon smartphone Samsung Galaxy. -------- Message d'origine --------De : David Mertz <mertz@gnosis.cx> Date : 19/02/2019 07:28 (GMT+01:00) À : Anders Hovmöller <boxed@killingar.net> Cc : Simon <simon.bordeyne@gmail.com>, python-ideas <python-ideas@python.org> Objet : Re: [Python-ideas] PEP 8 update on line length 60, or 68, or 80 characters, is not per se a cognitive limit. Yes, sure whitespace counts much less towards that burden than do regular characters. And to a significant degrees, punctuation vs. letters vs. numbers matter. And sure familiar words such as keywords scan a bit easier than unfamiliar names of variables. And so on.But 80 characters in general is already too wide most of the time. 65 is a better goal as a rule of thumb, with 80 already being for exceptionally long lines. Python keywords are already short, there's not much improvement to be had there. Saving two characters for acryptic WHL isn't better than the word 'while', for example.Pretty much the only time my code how's more than 80 characters is when it includes string literally that occupy a large chunk of the width. But if that 50 character string is the last argument of a function call, the reader can mostly stop scanning at it's beginning, so it's not terrible. When I have many keyword arguments, I break them into multiple physical lines using parents too continue the logical line. Or if I have complex compound conditions, I give the subclauses short but descriptive names before the if/elif.On Tue, Feb 19, 2019, 1:11 AM Anders Hovmöller <boxed@killingar.net wrote:
If that is the issue then we should be talking about non-space characters, not a 68 column limit right? No way does 40 spaces due to indent count towards the cognitive burden :) Also, if the cognitive burden is the issue then we should talk about short forms for keyword arguments again. The way the 68 column limit works in practice is that people avoid keyword arguments because of line length, plus the issues already mentioned. / Anders
On Tue, 19 Feb 2019 at 14:08, simon.bordeyne <simon.bordeyne@gmail.com> wrote:
A good middle ground would be to enforce customization of that rule in the most used python linters. A simple setting to set the number of characters before a linting warning occurs would be acceptable.
Any linter or project that treats PEP 8 as mandatory has *already* failed, as PEP 8 itself states that the rules can be broken as needed. Of course individual projects are entirely allowed to impose whatever draconian and inflexible rules they choose on source code formatting, but please don't pretend that PEP 8 made you do it ;-) Paul
I too would argue that it's time to reconsider line length limits. But the reason is not monitor changes, or any particularly strong personal opinion, but changes to python: Let's take a real life example from here <https://github.com/samuelcolvin/pydantic/blob/master/pydantic/utils.py#L246> (changed very slightly for this example), in tranitional python the signature might be: def resolve_annotations(raw_annotations, module_name): 55 characters, all fine. Now let's look at that same function in modern python with type hints: def resolve_annotations(*, raw_annotations: Dict[str, Type[Any]], module_name: Optional[str]) -> Dict[str, Type[Any]]: 119 characters! No daft 5-word variable names, just a clean (if strict) function definition. I don't see how anyone can say that would be more readable with a 80 character line limit. And that's not even an extreme case, we don't have lots of "Optional[..]" or "Tuple[ThingA, ThingB, ThingC]". Type hints (for good or bad depending on your view point) have made python code more verbose, that's just a fact. Code that used to fit on one line with 80char limit now require 120 (or more), therefore in my opinion the recommendation should change to keep up with changes in python. My preference is 120 characters (that's also the default in pycharm I believe). It works well on a desktop monitor, leaving room for a file browser and part of another window, it's also fine on a 13" laptop screen. Then again, every IDE and linter I've used (even black) allows the line length to be varried, so this is only really a problem in the standard library and libraries which adhere closely to pep8. Samuel
On 2/19/19 8:28 AM, Samuel Colvin wrote:
Let's take a real life example from here
<https://github.com/samuelcolvin/pydantic/blob/master/pydantic/utils.py#L246>
If it were me, I'd probably write (or would have re-written when I added the type hints) that as follows: def resolve_annotations( *, raw_annotations: Dict[str, Type[Any]], module_name: Optional[str] ) -> Dict[str, Type[Any]]: which leaves the longest line at 46 characters, even shorter than your original 55. And if the type hints are long, then a similar approach can mitigate that: def resolve_annotations( *, raw_annotations: Dict[str, Type[Any]], module_name: Optional[str] ) -> Dict[str, Type[Any]]:
Nothing says that you have to write an entire function header on one line.
Nothing says that you have to write an entire function header on one line.
Of course. I just think that code with a 7 line function header is much harder to read and understand than code with a one line function header. For example: it's less likely that two chunks of code I'm looking at are still visible on the screen at the same time in the former case. I'm simply arguing that since python has changed, it might make sense to change this recomendation too. That what would have been on one line in 2000 should still be on one line in 2019, despite changes to the language. I'm going to leave this conversation now as it seem to be primarily opinion based and I generally find opinion based discussions almost as annoying as meta-conversations about how the list should be run. :-) Samuel
<https://github.com/samuelcolvin/pydantic/blob/master/pydantic/utils.py#L246> def resolve_annotations(raw_annotations: Dict[str, AnyType], module_name: Optional[str]) -> Dict[str, AnyType]: pass After using https://black.now.sh/ def resolve_annotations( raw_annotations: Dict[str, AnyType], module_name: Optional[str], ) -> Dict[str, AnyType]: pass -- Jonathan
I'm afraid I'm not sure of your point here. (By the way, that code is already <https://github.com/samuelcolvin/pydantic/blob/master/Makefile#L12> run through black, just with a line length limit of 120)
Previously, Samuel wrote that he would leave the conversation, because it was primarily opinion based, which he finds annoying. I then provided evidence (namely how black.py reformats a specific code example). Samuel then wrote:
I'm afraid I'm not sure of your point here.
I wasn't making a point. I was providing evidence. -- Jonathan
On Tue, Feb 19, 2019 at 05:29:33PM +0000, Jonathan Fine wrote:
Evidence of what? What was the point of this evidence? If it was to demonstrate that it is possible to reformat function parameter lists to split over multiple lines, we already knew that. If it was to demonstrate something else, I have no idea what. -- Steven
Steven D'Aprano wrote:
One idea arising from the evidence I provided was that like a word-processor, one could use black.py to 'line-wrap' the Python code to what is the current width of the editor window. Which may vary from person to person. (I did not say it at the time, because I did not have it at the time. And because others might have different useful ideas coming from the same piece of evidence.) See https://mail.python.org/pipermail/python-ideas/2019-February/055424.html -- Jonathan
Samuel Colvin wrote:
I just think that code with a 7 line function header is much harder to read and understand than code with a one line function header.
But to me, a one-line function header that contains 7 lines worth of charaacters is *less* readable than a 7-line header, as long as it's formatted intelligently. The readability problem here is not caused by insufficient width. It's caused by the need to stuff a bunch of annotations into the header. -- Greg
I would like to point out here that breaking up a line breaks grepping quite badly. I've had to write AST-based searches to find simple usages of arguments in the code base at work precisely because of code that is split on likes like this. (This tool is available here: https://github.com/boxed/parso_utils) I would vastly prefer a soft like break algorithm that formatted the code as per your examples and having the code on disk be single line no matter what. In proprietary projects where one can agree on the tools used for the code this can be quite doable, but I agree it's not great for open source projects. / Anders
On 19.02.2019 18:06, Anders Hovmöller wrote:
This should help: https://stackoverflow.com/questions/3717772/regex-grep-for-multi-line-search... but you can also use Python's re module with the re.DOTALL flag. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Experts (#1, Feb 19 2019)
::: We implement business ideas - efficiently in both time and costs ::: eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48 D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg Registered at Amtsgericht Duesseldorf: HRB 46611 http://www.egenix.com/company/contact/ http://www.malemburg.com/
Maybe you know some grep magic I don't? Is there a way to do multi line grep that knows that open paren means to ignore new lines until the matching close paren? I'd love to hear about it!
I probably don't know any more grep magic than you, I've just never had cause to grep for anything that long. I am a touch bemused that you do frequently have cause, but each to his own, I suppose.
Not often. Once. But then I really really needed it :) It was a case where we had an API change to a lib and many calls where long enough to be split on multiple lines AND the keyword argument we had to find was very generic AND it could exist in nested calls. Of course the last was really fine since we could ha e worked through the false positives manually. I also happen to have lots of experience with Parso so it was easy for me to write. Otherwise we would probably have a logged through the crappy way. It's pretty nice to have this is the tool belt though. / Anders
On 2/19/19 11:06 AM, Anders Hovmöller wrote:
At the risk of jumping in over my head with respect to the technical limitations of regular expressions, grep already can't deal with matching parenthesis. Consider: f(g(h(a=4), b=5), c=6) Can grep tell me that I'm passing c to f but not to g or h? Disclaimer: I don't write code like that. Most of the time.
Samuel Colvin wrote:
I would argue that it *is* more readable if it's not all on one line: def resolve_annotations(*, raw_annotations: Dict[str, Type[Any]], module_name: Optional[str]) -> Dict[str, Type[Any]]: Having thus improved its readability, an 80-char line limit is no longer a problem. -- Greg
[Samuel Colvin]
I don't see how anyone can say that would be more readable with a 80 character line limit.
For starters, type annotations don't add anything that good documentation would have required before. In most docstring style guides that I know of, the arguments list is supposed to be at least one line per argument, so really it should look like so: def resolve_annotations(raw_annotations, module_name): """ description of what the function does Arguments: raw_annotations (type annotation): description of raw_annotations module_name (type annotation): description of module name Returns (type annotation): description or return value """ Which can easily be replaced with: def resolve_annotations( raw_annotations: Dict[str, Type[Any]], module_name: Optional[str]) -> Dict[str, Type[Any]]: """ description of what the module does Arguments: raw_annotations: description of raw_annotations module_name: description of module name Returns: description or return value """ Often, I find, people make add a lot of redundant noise to names which is either clear from context like; math.log, not math.mathematical_log_function, or doesn't add anything like; user_data instead of user, or job_info instead of job, or raw_annotations instead of annotations. It's often just as good to write: def resolve(annotations: Dict[str, Type[Any]], module: Optional[str]) -> Dict[str, Type[Any]]: """...""" On Tue, Feb 19, 2019 at 8:30 AM Samuel Colvin <S@muelcolvin.com> wrote:
On Tue, Feb 19, 2019, 9:07 AM simon.bordeyne <simon.bordeyne@gmail.com wrote:
I find that 100 to 120 characters is ideal as far as line length goes.
I very much hope no one else where had to read it review your code. In my opinion, splitting lines is much worse in terms of cognitive burden
than just a longer line. On top of that, it's not uncommon to reach 6, even 7 indentation levels.
In 20+ years of programming in Python (writing some will known books about it too), I have never once indented a block 7 levels. Very, very rarely 6. If you do that, your code has serious problems beyond line length. As far as monitor size goes, I agree that on a laptop is not ideal for 100+
characters per line if you want two pieces of code side by side.
In a readable size and font, I get two vertical panes of 71 characters on my 15" Retina display. I can read a smaller font character by character, but not easily scan a line. Here I'm just taking about visual accuity, not the cognitive issue. My vision in particular remains 20/20 for near vision (but sadly decayed with age for distance). It used to be more like 20/15, but I never used lines longer than 80 characters in any programming language (yes, individual lines, but not as a rule). I did used to use a somewhat smaller font size though. I guarantee that your code quidditch would improve if you use both shorter lines and a larger font. The latter only affects your interaction with your screens, the former is essential to everyone who needs to look at your code. And, fyi, I work on a 23" monitor at home and on a 15.6" monitor on the go.
Every linter I know about is customizable this way.
On Tue, Feb 19, 2019 at 03:07:23PM +0100, simon.bordeyne wrote:
Clearly that is not "all" it takes, since that's only *five* indents, not 6 or 7: class X: def method(self): for a in seq: for b in other: if cond: print("five indents") [...]
Just in that example, which is a very common occurence, an doesn't warrant refactoring
Doesn't it? Maybe it does, maybe it doesn't. It depends on what's going on inside the method. Maybe it should be written as a function (avoiding one indent). Maybe the row and column processing should be factored out into seperate methods: class X: def method(self): self.process_rows(seq) def process_rows(self, rows): for a in items: self.process_columns(a, other) def process_columns(self, a, cols): for b in cols: if cond: print("four indents") When this is possible, it has other advantages than merely saving one indent: we can test and document the row and column processing seperately, and reduce coupling between the components. (I can understand the column processing without caring about the row processing, and visa versa.) This is what I meant when I said that sometimes, the discipline required to keep to 79 columns helps give you better code. I started off wanting only to save an indent, but I got better documentation, better tests, and less coupled code that is easier to maintain. Of course sometimes you get *worse* code by refactoring. In which case you shouldn't do it :-) -- Steven
[simon.bordeyne]
I find that 100 to 120 characters is ideal as far as line length goes.
Your finding goes against a long history of people attempting to present text in the most readable way possible. AFIK, the human fovea hasn't grown much larger in recent years. [simon.bordeyne]
On top of that, it's not uncommon to reach 6, even 7 indentation levels.
It should be pretty uncommon. You might want to re-think your coding style if you're regularly writing code that's so deeply indented. A good trick is to use helper functions: #instead of this if condition: ...code #do this if condition: handle_it() [simon.bordeyne]
You should check out the itertools library and possibly the toolz package. I find it's often pretty simple to collapse nested loops in python: for n, element in enumerate(chain(*array)): r, c = divmod(n, len(array[0])) # if you need the indexes if condition(element): do_something(element) # this follows the one-line one-thought rule over PEP8 On Tue, Feb 19, 2019 at 8:08 AM simon.bordeyne <simon.bordeyne@gmail.com> wrote:
On Thu, Feb 21, 2019 at 11:09 AM Abe Dillon <abedillon@gmail.com> wrote:
You can't see the entire line in focus simultaneously anyway, so the line length is about how far you can flit your eye left to right, not the actual fovea itself.
And this is always cited as the "obvious" solution. The trouble is, unless "handle_it" has a name that tells you EVERYTHING about what it does, you probably will end up having to go look at its definition - which means a lot more flicking around. The cost of a long line has to be balanced against the cost of *avoiding* having a long line. Splitting a line into consecutive lines has less cost than breaking it out into a function, *unless* the function truly has its own meaning. ChrisA
[Chris Angelico]
And this is always cited as the "obvious" solution.
Yes. I think simon even referred to this "obvious" solution in his post when he said, "...which is a very common ocurence, *and doesn't warrant refactoring*" So, my comment may have been unwarranted. [Chris Angelico]
I think you're over emphasizing "EVERYTHING" and "probably". If your de-bugging or refactoring, You typically have enough context to make an educated guess if you need to look deeper. The Wikipedia for the game Tic-Tac-Toe (AKA Nots and Crosses) describes a strategy <https://en.wikipedia.org/wiki/Tic-tac-toe#Strategy> play(board, my_mark): # Win moves = win(board, my_mark) if moves: return random.choice(moves) # Block moves = win(board, opposite(my_mark)) if moves: return random.choice(moves) # Fork moves = fork(board, my_mark) if moves: return random.choice(moves) # Block Fork moves = fork(board, opposite(my_mark)) if moves: return block_fork(moves, board, my_piece) # Center if board[1][1] is None: return (1, 1) # Corners moves = empty_corners(board) if moves: return random.choice(moves) # Sides moves = empty_sides(board) if moves: return random.choice(moves) # Failing test board = [['O' , None, None] ['X' , 'X' , None] [None, None, None]] mark = 'O' result = play(board, mark) expected = (1, 2) assert move == expected, f"Block! Expected: {expected}, Got: {result}" You don't need to know EVERYTHING about how block_fork works to debug that failure. You probably don't need to know EVERYTHING about how random.choice works either. You don't need to know about how most of the functions in the code work. The code is not blocking an opponent's win. The fault must be in "win" or "opposite". [Chris Angelico]
That's a good point. Pragmatism should always win the day, of course; and excessive functional decomposition can cause it's own readability issues. I only offer it as a strategy, not a flawless solution. Sometimes going beyond 80 columns is the most pragmatic choice, but such cases should be rare. On Wed, Feb 20, 2019 at 6:23 PM Chris Angelico <rosuav@gmail.com> wrote:
On Thu, Feb 21, 2019 at 12:26 PM Abe Dillon <abedillon@gmail.com> wrote:
Not about HOW it works. That's irrelevant. You DO need to know about what it does, which is what I said. In the case of random.choice, that's very clearly defined by its documentation: it chooses a random element from the thing you give it. If you don't know that, you have to look it up to determine whether that's the problem. ChrisA
[Chris Angelico]
Not about HOW it works. That's irrelevant. You DO need to know about what it does, which is what I said.
So it is. I'm sorry I misread your comment. [Chris Angelico]
that's the problem. I think you're missing the point. The name random.choice alone, doesn't fully describe its interface, yet the first time I came across it in code, I didn't feel the need to go look into documentation. I'm betting you could make a pretty good educated guess of the interface of all the functions in the code I wrote above. Humans aren't computers. We can and do deal with ambiguity all the time. We can usually make a pretty good guess whether we need to drill down into a function to find a bug even if we don't know EVERYTHING about what the function does. Sometimes that educated guess is wrong and we have to back up and look at things we initially thought were irrelevant, but we're not as brittle to ambiguity as you seem to think. On Wed, Feb 20, 2019 at 7:35 PM Chris Angelico <rosuav@gmail.com> wrote:
On 2/18/2019 11:37 PM, Simon wrote:
Strictly speaking, PEP8 applies only to CPython stdlib code. Please read the introduction. Adapt it as you will for your code.
The majority of core developers, to whom PEP 8 applies, seem to disagree.
Do you every print on paper? In tiny type? Or sideways? Anyway, 3 80-column windows side-by-side is really nice. For instance, shell, code file, test file. -- Terry Jan Reedy
On 19Feb2019 00:09, Terry Reedy <tjreedy@udel.edu> wrote:
I'm not a core developer and I also disagree.
I like 4 80 column windows. 2 for the editing and either 2 shells or a single wide shell. And 80 columns doesn't really influence my variable name sizes. The longer the line, the harder it is to apprehend. To my mind 80 columns is a nice upper limit: long enough for expressiveness, short enough to easily scan. Cheers, Cameron Simpson <cs@cskk.id.au>
Am 19.02.19 um 05:37 schrieb Simon:
If I read PEP8 correctly, the limit is effectively extended to 100 (well, 99) characters already: Some teams strongly prefer a longer line length. For code maintained exclusively or primarily by a team that can reach agreement on this issue, it is okay to increase the nominal line length from 80 to 100 characters (effectively increasing the maximum length to 99 characters), provided that comments and docstrings are still wrapped at 72 characters. https://www.python.org/dev/peps/pep-0008/ Mike
On Tue, Feb 19, 2019 at 05:37:29AM +0100, Simon wrote:
I know this is not precisely what you are arguing, but the thought of people arguing that the only problem with a 300-character Perl one-liner is that their monitor is too narrow to view it amuses me :-)
The width of source code on old green-screen 80 column terminals may be a factor, but it probably isn't the most important factor. You might consider that even when broadsheet newspapers have up to 23 inches in width, they still format their text in much narrower columns. The typical line of text in a paperback is 60-70 characters including spaces. We have many centuries of experience teaching us that 60-70 columns of text is typically as wide as people can comfortably read. I'm not an expert, but my understanding is that the limiting factor is not so much the cognitive burden of reading 100+ characters but the physical motion of the eyes tracking back and forth across the long lines. The wider the line, the greater the chances that the eye will run off one line into the one below it, and the more eye-strain. Source code isn't as dense as prose, and is more line-oriented than paragraph-oriented, so we can afford to exceed 70 columns occasionally, but not too often. If people are regularly exceeding 80 columns, I would consider it a code smell and inspect the code carefully for these problems: - indents may be too wide (8 spaces instead of 4?); - code may be too deeply nested (too many indents); - variable names may be excessively long; - possibly too many violations of the Law of Demeter: paperboy.take_fee(customer.trousers.right_pocket.get_wallet().remove(fee)) - or just generally, too much complexity per line.
Do we? That's a rather sweeping generalisation. It may be true in some cases, but in other cases, the discipline of keeping to the 79 column limit can result in better code. But don't go mad about it: Raymond Hettinger did a very good talk called "Beyond PEP 8" which (correctly in my opinion) argues against worrying about small violations of PEP 8, in favour of more substantial efforts to beautify your code. https://www.youtube.com/watch?v=wf-BqAjZb8M In my own code, I take the 79 column limit as more of a guideline than a law, if I have to go over by 2 or 3 characters, I just do it and don't worry unless it is a more substantial violation. All those "tricks" you mention are not necessarily bad things, they can often be justified. If you have a function or method with eight levels of indentation, you probably should reduce the amount of indentation by refactoring. If you have variables like number_of_pages_in_current_section you probably should consider a shorter name. Your IDE may make it easy to write such long names, but it doesn't make it easy to read them. -- Steven
I don't think you will find an agreement to raise the number of line length (we didn't even manage to find an agreement at my job with less than 10 people), so I would suggest every reader not interested in the disscussion to put it into the bin directly, as no decision will emerge from here. That beeing said, the probable best limit should be None, and let everyone's text editor line up the things the way people want to read them.
I understand that the writer wants to have shorter names, but why would I want more ambigious names as a reader ? How would you rename number_of_pages_in_current_section such that the reader is not left wondering what does this variable represents ? -- *Nicolas Rolin* | Data Scientist + 33 631992617 - nicolas.rolin@tiime.fr <prenom.nom@tiime.fr> *15 rue Auber, **75009 Paris* *www.tiime.fr <http://www.tiime.fr>*
My two cents, because this is a subject about which I have a strong opinion: - Yes, VT100s and other green screen terminals have long since been out of fashion, but there are still some people, including myself, who like their xterms and iTerms in the standard size (80x24). Also, we sometime need to browser code from a smartphone, in which case physical (not just virtual) screen size is really an issue. - Yes, for maximum code readability, it's better to optimise for ~70 no whitespace characters max, which is approximately 80 characters overall if you you put space properly around / after commas, plusses, equals, etc. - OTOH: there is now a wonderful tool called Black ( https://github.com/ambv/black ) which is so good at turning badly formatted code into readable code that I've stopped worrying about this kind of issues (even though, as stated initially, I have a strong attachment to it). Black's default is 88, not 80, which conflicts a bit with the two previous points, but Black is, IMHO, so good that I've stopped thinking about it (there is a way to override the default setting, which I should be using, but I don't). Cheers, S. -- Stefane Fermigier - http://fermigier.com/ - http://twitter.com/sfermigier - http://linkedin.com/in/sfermigier Founder & CEO, Abilian - Enterprise Social Software - http://www.abilian.com/ Chairman, Free&OSS Group @ Systematic Cluster - https://systematic-paris-region.org/fr/groupe-thematique-logiciel-libre/ Co-Chairman, National Council for Free & Open Source Software (CNLL) - http://cnll.fr/ Founder & Organiser, PyParis & PyData Paris - http://pyparis.org/ & http://pydata.fr/
On Tue, Feb 19, 2019 at 9:38 PM Nicolas Rolin <nicolas.rolin@tiime.fr> wrote:
I understand that the writer wants to have shorter names, but why would I want more ambigious names as a reader ? How would you rename number_of_pages_in_current_section such that the reader is not left wondering what does this variable represents ?
page_count will usually be unambiguous. You might need total_pages to mean "not the current section", thus leaving the shorter one available for the narrower use. Obviously questions like this can't be answered without context, but at an absolute minimum, "number_of" can almost *always* be omitted. ChrisA
On Wed, Feb 20, 2019 at 11:19 AM Steven D'Aprano <steve@pearwood.info> wrote:
Fair point. However, in any context where "pages" could be a list of pages, you are unlikely to need a separate "pagecount", as it's just the length of the list. Maybe it's the number of pages you're _going_ to need, or something. But it's nearly impossible to judge without context. Maybe "almost always" was too strong, but in real-world contexts, I don't often need to specify that something is the "number of" something. ChrisA
I wrote: <quote> <https://github.com/samuelcolvin/pydantic/blob/master/pydantic/utils.py#L246> def resolve_annotations(raw_annotations: Dict[str, AnyType], module_name: Optional[str]) -> Dict[str, AnyType]: pass After using https://black.now.sh/ def resolve_annotations( raw_annotations: Dict[str, AnyType], module_name: Optional[str], ) -> Dict[str, AnyType]: pass </endquote> Samuel Colvin then told us that his example was already formatted with black.py, using a long line length. Here's a suggestion, at least for people projects that use black.py (such as Samuel's). It is to use black.py with a line-length of say 80 characters for code that is saved in version control. And when editing code, use whatever line-length that happens to suit the tools you are using. Indeed, like a word-processor, one could use black.py to 'line-wrap' the Python code to what is the current width of the editor window. Indeed, this might be a useful feature in Jupyter - see https://github.com/drillan/jupyter-black. And I've created https://github.com/drillan/jupyter-black/issues/3 Perhaps set the black line length to the width of the text box -- Jonathan
On Thu, Feb 21, 2019 at 6:48 AM Jonathan Fine <jfine2358@gmail.com> wrote:
Of course, if you assume that everything in your code is perfect, then by all means, reformat it however you like. If you're 100% confident that nobody writes any buggy code, then the formatting doesn't matter, and you can display it in whichever way looks prettiest. But if you appreciate ways of discovering bugs more easily, preserve everything that represents the programmer's intention. ChrisA
Opinion first - I don't see a need to change PEP 8. I recommend 100 char width for Python, which is acceptable under PEP 8 anyway. I think the real limit should be around 70 characters per line, not including leading white-space, but I realize that's impractical. I work mostly at 100 character line width, and the question of line width came up for me recently. Otherwise, I follow PEP 8. I want to see where, and why I exceed 79 chars, so I dove into a decently sized module file of mine and tallied the results. This is what I found. 563 total lines 448 non-blank lines For the non-blank lines: 49.6 characters per line on average 36.7 non-leading-whitespace characters per line 13.1 leading spaces per line on average 15.5% of lines exceeded 79 chars. The 69 lines that exceeded 79 characters fell into the following categories, listed according to how annoying they would be to fix. 1 - with statements I have a with statement that contains two context managers "with open(blah) as b, open(foo) as f:". There isn't a really good way to wrap this without adding another with statement or a backslash. 3 - function calls Function calls, even with the arguments put one per line, often exceed 80 (and sometimes 100) character limit. The issue tends to be a combination of tabbing, kwarg names, and the context in which all of this is used. It's often unavoidable. variable = some_class.method(argument=value, argument2=value) 5 - Overly deep logic There were a couple of blocks of code that should have been pushed into separate methods/functions. I do occasionally run into issues where there simply isn't room (in 79 chars) for the logic required, and that logic can't reasonably be separated out. 8 - Format calls While I love the new format syntax, I almost always end up moving the format call to a new line with 4 spaces of extra indentation. These were instances of when I didn't. 21 - Comments There's plenty of space for readable comments in most cases. Under several nested scopes, however, the space gets pretty tight. Those extra 20 chars go a long way. 12 - Strings Like comments, having a few extra chars for strings (mostly exception messages in this case) goes a long way when even moderately nested. 2 - Chained conditionals if A and B and C Should have been: if (A and B and C): 16 - Doc strings These are easily fixable with no change in readability, and rarely have issues with padding. On Wed, Feb 20, 2019 at 12:57 PM Chris Angelico <rosuav@gmail.com> wrote:
-- Paul Ferrell pflarr@gmail.com
First of all, thank you so much for taking the time to do some actual analysis! I only have one thing to add: [Paul Ferrell]
This reminds me of a bit that shows up often in Kevlin Henney's talks <https://www.youtube.com/watch?v=B3b4tremI5o&t=7m45s>. A better way to list arguments is only one indentation level above the current: variable = some_class.method( argument=value, argument2=value) Trying to match the indentation of the opening line is less readable and less robust to refactoring: variable = some_class.method(argument=value, argument2=value) var = cls.method(argument=value, argument2=value) On Wed, Feb 20, 2019 at 4:52 PM Paul Ferrell <pflarr@gmail.com> wrote:
Most of this thread is all just so much opinion, so I have avoided chiming in -- but as for opinion: <histrionic> A better way to list arguments is only one indentation level above the
God no! I HATE that style -- for me, it makes it MUCH harder to read -- even more so if the variable names are a bit longer. But if you are going to do it, for the love of god, use more than four spaces! four spaces is one indentation, one indentation is how a code block is delineated in Python -- this is NOT a code block. It should not look like one. </histrionic> By the way, this is much worse for, say, function definitions: def a_function_with_lots_of_params( param1, param2, kwarg1=something, kwarg2=something_else): now_a_line_of_code = this_thing() How can anyone think that's more readable than (view with fixed-width font if this email doesn't already do that for you): def a_function_with_lots_of_params(param1, param2, kwarg1=something, kwarg2=something_else): now_a_line_of_code = this_thing() This puts the parameter definitions over on the right, after the function name, where they belong, and makes it very clear where the definition ends and the function code begins. But if you HAVE to put it off to the left for I don't know why, at least put some extra space in there: def a_function_with_lots_of_params( param1, param2, kwarg1=something, kwarg2=something_else): now_a_line_of_code = this_thing() The parameters are still in an odd place, but at least it's clear where the body of the function begins. If you need more convincing, consider functions with fewer params, and how they look compared to ones with many: def a_function_with_few_params(param1, param2): now_a_line_of_code = this_thing() then: def a_function_with_lots_of_params( param1, param2, kwarg1=something, kwarg2=something_else) now_a_line_of_code = this_thing() why am I looking in a different place for the parameters when there are more of them?? Trying to match the indentation of the opening line is less readable
variable = some_class.method(argument=value, argument2=value)
this is more readable to me :-)
and less robust to refactoring:
var = cls.method(argument=value, argument2=value)
well, that is an issue that I do face, but I blame it on my crappy tools :-) But YAPF does it the way I like :-) Except in the case of the "facebook" style -- yeach!) https://yapf.now.sh/ Facebook style: def a_function_with_lots_of_params( param1, param2, kwarg1=something, kwarg2=something_else ): now_a_line_of_code = this_thing() Anyway, PEP8 is officially for the standard library, but it HAS become a python-wide standard. As such, it simply needs to be flexible on some of these opinionated issues -- so both of the above styles are OK, as is adjusting your max line length up some. So at most, I'd say rewording this: """ Some teams strongly prefer a longer line length. For code maintained exclusively or primarily by a team that can reach agreement on this issue, it is okay to increase the nominal line length from 80 to 100 characters (effectively increasing the maximum length to 99 characters), provided that comments and docstrings are still wrapped at 72 characters. """ To be a bit less harsh would be a fine idea -- that is, change the clause: "For code maintained exclusively or primarily by a team that can reach agreement on this issue, it is okay ..." To maybe just "For code maintained by a team that can reach agreement on this issue, it is okay ..." Then we can all go back to bike-shedding something else. -CHB PS -- I personally use 95 char per line :-) -- Christopher Barker, PhD Python Language Consulting - Teaching - Scientific Software Development - Desktop GUI and Web Development - wxPython, numpy, scipy, Cython
[Christopher Barker]
Holly hell! I'm sorry I insulted your mother or whatever serious crime I committed. Yes, I agree that two levels of indentation is an improvement and is in-fact how I write function definitions. [Christopher Baker]
this is more readable to me :-)
I wish you would have watched the video I linked <https://www.youtube.com/watch?v=B3b4tremI5o&t=7m45s> so I wouldn't have to make all the same arguments, but in the context of code running off the edge of a window, having the argument list hidden out there with arbitrary indentation is definitely a readability issue. [Christopher Baker]
This puts the parameter definitions over on the right, after the function name, where they belong
According to whom? [Christopher Baker]
If you'd seen my other replies in this very thread, you'd see that's exactly the style I use. [Christopher Baker]
well, that is an issue that I do face, but I blame it on my crappy tools :-)
I consider it a good thing that your tools don't facilitate bad coding style ;) This is just more Stockholm syndrome. Nowhere else will you see people consider cramming valuable information off into the right margin with arbitrary indentation "good design". You won't see it in prose. You won't see it in mathematical notation. You won't see it anywhere else. On Wed, Feb 20, 2019 at 8:42 PM Christopher Barker <pythonchb@gmail.com> wrote:
On Wed, Feb 20, 2019 at 10:57 PM Abe Dillon <abedillon@gmail.com> wrote:
I wish you would have watched the video I linked <https://www.youtube.com/watch?v=B3b4tremI5o&t=7m45s>
that is an hour and 7 minute video! And I did watch some of it, and do agree with much of it. By the way, everyone should watch one of Jack Diederich's "naming things once videos as well: https://www.youtube.com/watch?v=hZ7hgYKKnF0
but in the context of code running off the edge of a window,
I never said anything about running off the edge of the window -- if you put all your parameters on their own line, and don't use insanely long names, that will not be an issue. Keeping it to 72 chars is virtually never a problem.
having the argument list hidden out there
nothing hidden about it --it's exactly where a single argument would be -- does anyone advocate putting a single parameter or argument on the next line? But my core point really was these are all matter of opiniion, and it's a godo thing that PEP 8 allows some variation.
According to me, of course. But it is wehre a single parameter would be, yes?
I've lost track of who advocates what style, but I was responding to someone that specifically advocated one level of indentation -- which is really the worst option. [Christopher Baker]
mostly they don't facilitate any of these styles in this context (I've been meaning to write a plugin for sublime that does, but haven't gotten around to it ). But the point is that handling indenting is really something the tools should do for you -- choosing a style for "ease of refactoring" should be pointless.
This is just more Stockholm syndrome.
honestly, I haven't chooses this style due to having been forced (or even encouraged) to use it -- I spend more time re-aligning code to make it the way I want it -- so no, I"ve come on this 'cuse it fits my brain better.
Nowhere else will you see people consider cramming valuable information off into the right margin with arbitrary indentation "good design".
It's not the margin, and it's not arbitrary.
You won't see it in prose. You won't see it in mathematical notation. You won't see it anywhere else.
Actually, I"ve seen in it math, where you have an "array" of equations, and
OK, then use two indentation levels for the parameter stack -- just don't use one -- that really is the worst option -- one indentation has real meaning in code. -CHB -- Christopher Barker, PhD Python Language Consulting - Teaching - Scientific Software Development - Desktop GUI and Web Development - wxPython, numpy, scipy, Cython
On 2019-02-20 18:41, Christopher Barker wrote:
I feel the complete opposite. "One indentation" is the only unit in multiples of which anything should ever be indented. Using arbitrary "indentation" to visually line things up is horrible. Everything gets indented by an integer number of indentation levels. It was mentioned earlier on this thread, but I think the real problem is editors. Specifically, people have become used to certain editor behaviors and conventions which are not actually that great, and as a result editors have not emphasized features which would be better. Even more specifically, people have not insisted that editors be designed to support a reader-oriented, rather than writer-oriented, approach to code display. In other words, visual details how the code is displayed should be up to person reading the code, not the person who wrote it. Instead, people have apparently for a long time insisted on the reverse, namely editors which format things as the code is written, by inserting actual characters in the file to make things like up visually. Characters shouldn't be in the file to make things like up visually; they should be there for their semantic importance. If that is done, then the editor can render those semantics in different ways according to the viewer's preference. The problem is that editors don't do this, because people have somehow gotten the idea that this would be a bad thing. So instead we have to argue over things like this, because whatever purely cosmetic choices one person makes in indenting his or her code become baked into the actual bytes of the file, and cannot be rendered differently later according to the preferences of a different viewer. I've rather forlornly given up on dealing with any of this. I use an editor that VISUALLY wraps long lines and maintains the indentation on the wrapped portion, without changing the bytes in the file. I make my lines as long as I want, inserting linebreaks only where they have a semantic reason to be (such as between multiple long conditions in an "if"). Everything is fine, until someone else looks at the code, and they have an editor that is only designed to display code that has the formatting baked into the whitespace. As a result, I consider this issue pretty much moot. There is no reason for the line length limit to be set to 100 or 120 or anything else. There are already too many problems with PEP 8 that stem from a desire to use whitespace for visual alignment rather than semantics (such as using spaces instead of tabs). So I just basically ignore PEP 8 and follow my own style, which happens to overlap in some respects with PEP 8 and diverge from it in others. -- Brendan Barnwell "Do not follow where the path may lead. Go, instead, where there is no path, and leave a trail." --author unknown
Brendan Barnwell wrote:
I don't think that taking an excessively long line of code and mechanically wrapping it to a narrower width makes in any easier to read. Like you say, readability relies on making intelligent decisions about where to break lines based on their semantics. So even if everyone is equipped with an auto-wrapping code editor, there is still going to be code that really needs at least N characters of width to display properly, and looks terrible when wrapped to anything less. Think about how annoying it is when an email message gets re-wrapped to a slightly narrower width than it was originally written with -- and apply that to code. -- Greg
Abe Dillon <abedillon@gmail.com> writes:
Yes, that's unfortunate, but I still prefer the latter, and usually I accept the hassle and realign the remaining lines. In hindsight, I wish someone with a powerful time machine could introduce the concept of "one-indent-level-and-half" for continuation lines: the statement that most annoys me is the "if" when the condition is very long, because my eyes suffer when I see the following: if condition1 and \ condition2 and \ condition3: do_something() or even if (condition1 and condition2 and condition3): do_something() at the point that I usually use a double paren just to have one single space of difference between the continued condition elements and the succeeding suite: if ((condition1 and condition2 and condition3)): do_something() ciao, lele. -- nickname: Lele Gaifax | Quando vivrò di quello che ho pensato ieri real: Emanuele Gaifas | comincerò ad aver paura di chi mi copia. lele@metapensiero.it | -- Fortunato Depero, 1929.
On Wed, Feb 20, 2019 at 11:51 PM Lele Gaifax <lele@metapensiero.it> wrote:
that most annoys me is the "if" when the condition is very long, because my eyes suffer when I see the following:
yup -- "if (" is four spaces -- exactly one indentation level -- that is really painful. I've got to figure out how to get flake8 to stop yelling at me for making that more readable :-) of difference between the continued condition elements and the succeeding
ouch! ehy not jsut do: if (condition1 and condition2 and condition3)): do_something() (or any number of other options) and teach your linter that that's OK (or ignore your linter) -CHB -- Christopher Barker, PhD Python Language Consulting - Teaching - Scientific Software Development - Desktop GUI and Web Development - wxPython, numpy, scipy, Cython
Christopher Barker <pythonchb@gmail.com> writes:
Because I would first need to teach Emacs the aforementioned "indent-and-half" for continuation lines :-) ciao, lele. -- nickname: Lele Gaifax | Quando vivrò di quello che ho pensato ieri real: Emanuele Gaifas | comincerò ad aver paura di chi mi copia. lele@metapensiero.it | -- Fortunato Depero, 1929.
On Thu, 21 Feb 2019 at 12:20, Paul Ferrell <pflarr@gmail.com> wrote:
My linter is fine with a double indent after an 'if (A and'. I thought it was in the standard.
If I used a linter, I'd expect it to be fine with whatever I told it to be fine with :-) It's a linter's job to flag up violations of the coding style *I* choose to follow, not to impose a coding style on me that I don't agree with. Paul
A general rule of thumb is, if Python feels inconvenient or awkward, you’re doing something wrong.
On Tue, Feb 19, 2019 at 11:38:04AM +0100, Nicolas Rolin wrote:
Excellent question! Note that I didn't say that long names are *necessarily* a problem, only that they could be. I would start by reading the code and asking two questions: 1. Does the name really need to specify that it is the number of pages in the *current* section? Unless you have multiple such variables: number_of_pages_in_current_section number_of_pages_in_previous_section number_of_pages_in_next_section the chances are very good that "in_current_section" is pointless information that the reader will infer from context: for section in sections: number_of_pages = len(section) 2. Do you really need such a verbose name spelled out in full? Instead of "number_of_pages", perhaps "num_pages" is enough. If it is obvious from context, perhaps even "num" or even "n" is enough. If you dislike such standard abbrevations, how about "pagecount"? Short names are not necessarily ambiguous, and long names are not necessarily clear: process(the_current_thing_we_are_processing_right_now) is no less ambiguous or any more clear than: process(thing) In a well-written function that isn't too long, we ought to be able to find the definition of any local variable no more than half a page away. Local variables are usually far more limited in their scope and lifetime and the need for them to be self-documenting is correspondingly reduced. Insisting that *every* name must be meaningful *in isolation* is an over-reaction to poor quality code. Typically we read code in context: we can see the rest of the function and the definition of the variable is only a handful of lines away. The interpreter doesn't care what you call your variables, names are purely comments for the reader. It isn't true that the more comments the better, and the same applies to naming: - Just as comments can lie, so can names. I expect we've all read code where the names are actively misleading: mylist = {key: value} - Comments shouldn't simply repeat the obvious meaning of the code: x += 1 # add 1 to x and neither should variable names. If meaning can be inferred from the obvious meaning of the code, the need to spell out the meaning in full is reduced. (See my example above of number_of_pages.) - When writing comments we should eschew sesquipedalian loquaciousness x += 1 # increment the value of the variable x by the successor integer to the additive identity of Z and we ought to do the same for variable names. -- Steven
On 2/18/19 8:37 PM, Simon wrote:
I'd like to propose an update to PEP8. Indeed, the 80 characters per line guideline is, I feel, outdated.
Hi, I don't agree it is outdated. As someone who has a second 4k monitor in portrait mode to minimize scrolling (recommended), the ~80 char line limit avoids the need for horizontal scrolling as well. This isn't your father's Oldsmobile, haha. When in landscape on the go I can have two windows open side by side, say an editor and documentation/mail at the same time, aka multitasking. Not as good as a second monitor, but better than nothing. Other folks have chimed in on how newspapers and magazines limit line length for readability purposes. I suppose if you code fullscreen (or near it) on a 16:9 monitor, longer lines might be desirable. Worked at a place where a co-worker frequently produced code with ~200 character lines despite calls to cease and desist. Looked over once, and sure enough a full+widescreen editor. Nostalgic for DOS, or focused like a laser? Not sure. The issue is unfortunately exacerbated by the monitor industry forcing us all to 16:9 aspect ratios, outside of the MacBook and tablets. That was a regression in my opinion. -Mike
On 2/21/19 10:53 AM, Paul Ferrell wrote:
I think the solution is for everyone to rotate their widescreen monitors 90° into a really tall portrait mode. :)
Yep, that's what I do, but would prefer a squarer monitor so I could get two windows side by side on that one also. My old 1600x1200 4:3 in portrait allowed that comfortably. 16:10 might. -Mike
Some feedback: I code on a 13.5 inch laptop. I split my screen between my browser on the left half and editor on the right half of the screen. The 80 character suggestion has been helpful to me in reading code. Otherwise I'd use up time with random horizontal scrolling. On Thu, Feb 21, 2019 at 4:11 PM Mike Miller <python-ideas@mgmiller.net> wrote:
On Feb 18, 2019, at 8:37 PM, Simon <simon.bordeyne@gmail.com> wrote:
I'd like to propose an update to PEP8. Indeed, the 80 characters per line guideline is, I feel, outdated.
I concur. We now put expressions in f-strings and have assignment expressions that easily spill over 80 characters if one uses all but the most compact variable names. Comprehensions tend to make expressions longer. Queries and filters in Pandas also easily spill over. The 80 character limit pre-dates these evolutions of the language. In particular, the case where I most want to let people run with long lines is in forming messages to be displayed to a user. Templates can get fat even if the displayed message is not long. The code is more readable if people don't mangle their templates with line wrapping. class Frabawidget: ... @wozzle.setter def (self, woozle): if not (self.min_woozle < woozle < self.max_woozle): raise ValueError(f"Expected woozle to be between {self.min_woozle} and {self.max_woozle}") self._wozzle = normalize(woozle) In doing code reviews, I see many fewer atrocities from long lines than I do from weird line-wraps and from variable names that have been over-shortened to make the line fit in 80 characters. To avoid these issues, my clients typically set their line limits at 90 or 100 (though I have one customer that keeps 80 characters but uses two-space indents, yuck). PEP 8 is mostly about readability. However, the line length limit often seems to cause less readable code. Raymond
On Thu, Feb 21, 2019 at 12:01 PM Raymond Hettinger < raymond.hettinger@gmail.com> wrote:
In particular, the case where I most want to let people run with long lines is in forming messages to be displayed to a user.
I agree here -- and if it's messages (also comments - a twenty char comment after a 70 char line should be fine!) then it's not part of the logic of the code -- so not as bd if there is some spill off the screen for those folks that do code on tablets ;-) Actually for me, the issue s comes up when I'm showing code on a projector -- I use a huge font so folks in the back can see)
That's 103 chars long -- and very readable. But, is this that much worse? class Frabawidget: ... @wozzle.setter def (self, woozle): if not (self.min_woozle < woozle < self.max_woozle): raise ValueError(f"Expected woozle to be between" "{self.min_woozle} and {self.max_woozle}") self._wozzle = normalize(woozle) (it IS harder to write, that's for sure) In doing code reviews, I see many fewer atrocities from long lines than I
and yet the above example was 103 ... you do need a limit somewhere. I actually would really like the "limit" to depend on what the line is -- that is, it's OK to go longer if it's essentially text -- message to the user, comment, etc., rather than part of the code logic. In fact, now that I write that, I think I actually DO do that -- and even add a # noqa sometimes so my linter will stop bugging me. A smart linter would be nice here. PEP 8 is mostly about readability. However, the line length limit often
seems to cause less readable code.
So what do you suggest? simply increase the recommended line length? Or would softening the language about extending it be enough? Maybe something along the lines of: A line length limit should be well defined for each project / organization -- 80 char per line is safest for all users, but anything up to 100 is appropriate if the team maintaining the code agrees. Raymond: As a core dev -- are suggesting extending the line limit for the standard library? To all the folks quoting theory: let's be honest. Yes, really long lines are harder to read, but the 80 char limit comes from old terminals, NOT any analysis that somehow that is optimum for readability. -CHB -- Christopher Barker, Ph.D. Oceanographer Emergency Response Division NOAA/NOS/OR&R (206) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317 main reception Chris.Barker@noaa.gov
On 2/21/19 7:06 PM, Chris Barker via Python-ideas wrote:
On Thu, Feb 21, 2019 at 12:01 PM Raymond Hettinger <raymond.hettinger@gmail.com> wrote:
That's 103 chars long -- and very readable. But, is this that much worse?
I remain against longer lines. I break 80 characters extremely rarely, if ever, and at times start breaking long lines before that. I find Chris's code more readable. I'm even more against for backwards incompatibility and hard-to-read exception messages. ;-) Chris's code doesn't quite match Raymond's; Chris lost a space between (ironically) "between" and "{self.min_woozle}." Dan
On Thu, Feb 21, 2019 at 05:06:51PM -0800, Chris Barker via Python-ideas wrote:
Chris, the convention to limit text to somewhere around 60-80 characters predates old terminals by *literally centuries*. I don't think it's *us* that needs to be told to "be honest". I don't know who first came up with this story that the 79 column limit is all about compatibility with old 80 char terminals, but it's just a story. (And did they ever stop to wonder why those old terminals standardized on 80 columns?) Compatibility with old terminals is "nice to have" if you ever need to ssh into a remote machine via an 80-column machine and edit code (and I know somebody who actually does that!), but that's not the reason why we should keep the 80 column limit as the default. (Many people have already spent a lot of words explaining some of the advantages of an 80 char limit, and I don't intend to go over them again. Go back and read the thread.) I've just grabbed a handful of books at random from my bookcase, and done a quick sample of number of chars per line: 42 letters plus whitespace = 52 characters 28 letters plus whitespace = 34 x 2 columns = 68 63 plus ws = 75 56 plus ws = 67 73 plus ws = 84 59 plus ws = 70 56 plus ws = 67 (another one!) I would be surprised if you found many books that reached 95-100 characters, and shocked if you found any at all that reached 120 characters. Based on this sample, I would say the typical line length for optimal reading of prose is about 60-70 chars. Call it 65. Add four leading idents of four spaces each, and our optimum is about 81 columns. The difference between that and PEP 8's 79 columns is not significant. (I for one would not fail your code in a review merely for reaching 81 or even 82 columns.) Now, it does have to be admitted that prose does not have the same characteristics as source code. Prose tends to have solid paragraphs of the same width, and we typically read large blocks of text in full. Whereas source code tends to have lots of short lines, and a few very long lines. We typically skim most of the text, then focus in tightly to study in detail a small section of the text at a time. And any limit we choose is going to be a compromise between the need to avoid giant one-liners and the nuisance value of splitting a conceptual line of code over multiple physical lines. Being a compromise, there will always be cases where it is sub-optimal. Nevertheless, we can say this about typical Python source code: 1. 79 characters is *very generous* for most lines of code; I did a quick sample of code and found an average of 51 columns including the leading indents. This is, of course, an imperfect and biased sample because long lines have been split to keep the 79 char limit, but even a brief glance at the std lib shows that most lines of code tend to fit within 50-60 characters. 2. When a single line goes beyond 80 columns, it often wants to go a long way beyond. Perl-ish one-liners are merely a extreme case of this. 3. Such long lines are often complex, which makes them hard to read and hard to debug. Opinion: we really shouldn't be encouraging people to write long complex lines of code. If a single line has more than a dozen method calls in it, it might be a tad too complex for one physical line regardless of how wide your monitor is :-) Splitting such complex expressions over multiple lines, or even multiple statements, can have advantages beyond merely keeping to the 79 column limit. It can often result in better code that is easier to understand, debug and maintain. 4. But one notable exception to this is the case where you have a long format string, often passed to "raise Exception", or print. They're rarely complicated or hard to read: at worst, substituting a few variables into a format string. These are often indented four or five levels deep, and they really are a pain-point. They're sometimes hard to split over multiple lines. And not only are they conceptually simple, but we rarely need to read them in detail. Its the surrounding code we need to read closely. (Raymond's post singles these kinds of lines out as especially problematic, and his observations agree with my experience.) Opinion: common sense should prevail here. If you have a line "raise ValueError(...)" which would reach 80 or even 90 characters, don't let PEP 8 alone tell you otherwise. It's just a rule, not a law of physics. We have rules so that you *think before you break them*. But if you have a more substantial code that exceeds 80 columns, that's a code smell and you ought to think long and hard before breaking it. Proposal: - keep PEP 8's current recommendation; - but remind people that the rule can be relaxed for lines that are conceptually simple, such as the "raise Exception(...)" pattern; - and also remind people that long *complex* lines are an anti-pattern. Such complex lines can be improved by splitting them over multiple lines, and should be. I know we try to think in hard limits. "If 79 is too short, then 90 or 100 or 150 or ..." I'm making a plea for the opposite: if you intend to break 80 columns, consider the line itself before breaking it. Don't just increase the limit. That effectively says "any amount of complexity is OK in a single line, so long as it remains below X columns". I'd rather people look at the line and decide "this is too complex, split it" or "it's just a format string (or whatever), let it be". -- Steven
Chris, the convention to limit text to somewhere around 60-80 characters predates old terminals by *literally centuries*.
Not for code, it doesn’t— and centuries ago, there were other technical issues on play for papermaking, hand writing, and typesetting.
(And did they ever stop to wonder why those old terminals
standardized on 80 columns?)
CRTs were small and low resolution? A 200 char line would have been very expensive back in the day, and I’m pretty sure the old tractor feed paper terminal I first learned to code on was a lot more than 80 char wide. But now that you mention it, I suspect the 80 char punch cards had an influence. How many of us still type on QWERTY keyboards? Even on a phone, like I am now. The point is that we conform to s lot of conventions without re-adding whether the original reasons for those conventions apply. And no one on this thread has cited a study about optimum line length for readability of code. I have no idea if that’s ever been done — but that is the question at hand. “Typesetters hundreds of years ago used less than 80 chars per line, so that’s what we should do for Python code now” is a pretty weak argument.
Go back and read the thread.
I have read the thread. And Raymond made a pretty good argument for why, in some cases, a shorter line limit is a problem— and I have had much the same experience. and the nuisance value of splitting a conceptual
line of code over multiple physical lines.
I think one key question is whether it’s a nuisance, or actually makes some code harder to read.
1. 79 characters is *very generous* for most lines of code;
I’ve found a common exception for this is string literals and trailing comments. And I often prefer 80+ char trailing comments to an extra comment line. 2. When a single line goes beyond 80 columns, it often wants to go a
long way beyond.
Often True, but I’ve found setting my linter to 95 char makes a big difference in my code
Opinion: we really shouldn't be encouraging people to write long complex lines of code.
Agreed — but as you point out, those are often MUCH longer, so pushing the line limit to < 100 chars doesn’t really change that. 4. But one notable exception to this is the case where you have a long
format string, often passed to "raise Exception",
...
These are often indented four or five levels deep, and they really are a pain-point.
Oh yeah, that was Raymond’s point, and I concurred and emphasized it.
Yup - the trick here is that it’s hard to define clearly in a style guide, and even harder in a linter. One issue with all this is that there’s been a move toward automated enforcement (or checking) of style. Which I think is an overall good thing, but then it’s hard to allow judgement as well. But if you have a more substantial code that exceeds 80 columns, that's
a code smell and you ought to think long and hard before breaking it.
My reading of your points above is that the really smelly code is well over 80 chars, so having a slightly larger limit would work fine as well. Proposal:
- keep PEP 8's current recommendation;
As long as that includes the “ you can raise it to up to 100 char, sure :-)
- but remind people that the rule can be relaxed for lines that are conceptually simple, such as the "raise Exception(...)" pattern;
It would be nice, if possible, to clearly define this relaxation. - and also remind people that long *complex* lines are an anti-pattern.
Such complex lines can be improved by splitting them over multiple lines, and should be.
Not sure that’s needed, but why not?
Agreed — you can have too much complexity in 80 char. Which is why I think the 80 char limit is about what fits on a screen, not complexity. -CHB -- Christopher Barker, PhD Python Language Consulting - Teaching - Scientific Software Development - Desktop GUI and Web Development - wxPython, numpy, scipy, Cython
Christopher Barker wrote:
(And did they ever stop to wonder why those old terminals standardized on 80 columns?)
Probably because IBM decided on 80 columns for their punched cards. And that probably didn't have anything to do with a readable width for text. Nobody used computers for word processing back then. In fact punched cards predate computers altogether, originally being developed for electromechanical accounting and record keeping machines.
Line printers were traditionally 120 chars wide, but again that had nothing to do with text. It was so that accountants could print reports with a ridiculously large number of columns of figures.
How many of us still type on QWERTY keyboards? Even on a phone, like I am now.
Once you're used to qwerty, anything else is a nuisance, even if you're not touch typing on it. A place I park at recently installed machines you enter your car's license number into. The keyboard has the letters in alphabetical order, presumably because someone thought it would be "easier". But nowadays I suspect it just makes it harder for most people!
“Typesetters hundreds of years ago used less than 80 chars per line, so that’s what we should do for Python code now” is a pretty weak argument.
But that's not the entire argument -- the point it is that typesetters had the goal of making lines of text readable, which is similar (if not quite the same) as the goal of making lines of program code readable. It's a lot closer than, for example, the goal of fitting in an accountant's spreadsheet.
Agreed — you can have too much complexity in 80 char. Which is why I think the 80 char limit is about what fits on a screen, not complexity.
I would say it the other way around. Once you've reduced the complexity of a line to something a human can handle, *most* of the time 80 chars is enough. There will be exceptions, but as long as the exceptions are rare, making your editing window any wider will mostly just waste screen space. -- Greg
On Fri, Feb 22, 2019 at 5:10 PM Greg Ewing <greg.ewing@canterbury.ac.nz> wrote:
+1 It has been known for a very long time. These are *old *books that talk about *refactoring* (the word wasn't used then) of complex code (assigning subexpressions to variables, or extracting code into functions, reverting conditionals, etc.), not for line length, but for understandability, yet resulting nevertheless in much shorter lines: - Software Tools (also Software Tools in Pascal), Kernighan and Plauger, 1976 https://smile.amazon.com/Software-Tools-Brian-W-Kernighan/dp/020103669X - Code Complete (also the second edition), Steve Mc Connell, 1993, https://smile.amazon.com/Software-Tools-Brian-W-Kernighan/dp/020103669X I do make an exception in that after taking 8 spaces of indentation to write the implementation of a method in Python, the sweet spot is more around 100 chars. -- Juancarlo *Añez*
Hi, Le 22/02/2019 à 22:10, Greg Ewing a écrit :
I totally agree with Greg Ewing on that point. The only time when line length is a hinder by itself to me is when I can't split the windows side by side and fit both the lines of the code and it's unit-tests. And this case never happen alone as the "I can't describe easily what this line of code does" is a way bigger problem than the line length. Alexandre Dubois --- L'absence de virus dans ce courrier électronique a été vérifiée par le logiciel antivirus Avast. https://www.avast.com/antivirus
Textile looms, actually. Neither here nor there about the length of lines in PEP8 but an interesting factoid none the less. IBM (and possibly others) took punch cards from looms. On the subject of the 79 character line limit, its come up a lot in the past. * PEP-8 is the guidelines for the standard library that python-dev doesn't even strictly enforce. While it makes a decent starting point for your own project guidelines, change anything you want. * 79 characters is a reasonable ball-park figure for how long a line should be for most people * Going much above 79 characters is an indication of code smell * No matter what number you come up with, someone is going to be upset. There is no way to win in changing the guideline. PEP-8 is not a universal truth, or even a standard, we really shouldn't be treating it like it is.
Alex Walters writes:
There is no way to win in changing the guideline.
IMO this is true, despite the comment below:
PEP-8 is not a universal truth, or even a standard, we really shouldn't be treating it like it is.
Unfortunately, it's not us (at least, I don't think it is), and it's not our choice. Despite repeated warnings on the lists and even in the PEP that this is specific to the Python standard library, there are a lot of projects that choose to use the pep8 and flake8 utilities to more or less enforce PEP 8 as a standard. I believe the OP was in that situation, and it usually comes up when we have these discussions. They want us to take leadership in enforcing their standard on the rest of the world. But I don't see what's in it for us, given how divided we are on the issue. -- Associate Professor Division of Policy and Planning Science http://turnbull.sk.tsukuba.ac.jp/ Faculty of Systems and Information Email: turnbull@sk.tsukuba.ac.jp University of Tsukuba Tel: 029-853-5175 Tennodai 1-1-1, Tsukuba 305-8573 JAPAN
On Feb 22, 2019, at 1:10 PM, Greg Ewing <greg.ewing@canterbury.ac.nz> wrote:
The issue with reference to typesetter rules is that they were targeted at blocks of prose rather than heavily nested hanging indents with non-trivial string literals or a dotted attribute notation. Typesetters were also dealing with fixed page widths and need to leave gutter space for binding. The "rules" aren't comparable at all.
That would make sense if we started at column 0; however, if you have your prefix your thoughts with something like ''' class TestRemote(unittest.TestCase): def test_heartbeat(self): ... self.assertIsInstance(... ''' then the meant of the part "a human can handle" starts at column 30. Then if you need good variable names and/or have to module.function prefixes, there is sometimes little to left to work with. Raymond
As a human, and one who reads and writes code even, I know that MY ability to understands the meaning of a line of code starts to plummet when it reaches about 65-70 characters in length. Yes, of course there are some "it depends" caveats that make some lines easier and some harder. But an 80 characters "limit" is an excellent rule of thumb, as long as most coders usually "err" on the short side. My brain is a lot like those of people whom typesetters have typeset for for hundred of years, and whom scribes have written for for thousands. It's easy to be sophistical and discover that code is so very much different that roles of intelligibility don't apply. It's not though, and they do still. Or maybe everyone else in the thread is simply smarter and better able to handle complexity than I am. More power to you, but that definitely doesn't feel like "computer programming for everyone." If you want to write 100 or 120 characters lines, Python won't complain, but you've walled off your code from me as a potential reader of it. On Mon, Feb 25, 2019, 12:25 AM Raymond Hettinger < raymond.hettinger@gmail.com> wrote:
On 2/21/19 10:33 PM, Steven D'Aprano wrote:
(And did they ever stop to wonder why those old terminals standardized on 80 columns?)
Punch cards? https://softwareengineering.stackexchange.com/questions/148677 There's an ensuing discussion regarding the history of the size/shape of the punch card, too. Dan
Raymond Hettinger posted a helpful example to this list. Here, I run his example, and a variant, through https://black.now.sh Raymond class Frabawidget: @wozzle.setter def wibble(self, woozle): if not (self.min_woozle < woozle < self.max_woozle): raise ValueError(f"Expected woozle to be between {self.min_woozle} and {self.max_woozle}") self._wozzle = normalize(woozle) black.py class Frabawidget: @wozzle.setter def wibble(self, woozle): if not (self.min_woozle < woozle < self.max_woozle): raise ValueError( f"Expected woozle to be between {self.min_woozle} and {self.max_woozle}" ) self._wozzle = normalize(woozle) Raymond variant class Frabawidget: @wozzle.setter def wibble(self, woozle): if not (self.min_woozle < woozle < self.max_woozle < self.super_max_value) and do_this_or_that_(): raise ValueError(f"Expected woozle to be between {self.min_woozle} and {self.max_woozle}") self._wozzle = normalize(woozle) black.py class Frabawidget: @wozzle.setter def wibble(self, woozle): if ( not ( self.min_woozle < woozle < self.max_woozle < self.super_max_value ) and do_this_or_that_() ): raise ValueError( f"Expected woozle to be between {self.min_woozle} and {self.max_woozle}" ) self._wozzle = normalize(woozle) (By the way, I had to add the 'wibble' to the code above, to avoid a syntax error.) -- Jonathan
Yes, it's worse. You introduced twos bugs. First the space between the two fragments was lost. Second the f on the second f-string was dropped. I see these kinds of line-wrapping errors frequently. The bugs are CAUSED by the line length rule. Also, in the case of multi-line templates, there is no way to wrap them without getting very far from WYSIWYG: def run_diagnostics(location, system, test_engineer): ... if (failures): print(dedent(f'''\ There were {num_failures) anomalies detected in the {location} {system} at {event_time ::%I:%M:%S}}. These anomalies were classified as {level}. Further action is {'' if escalate else 'not'} recommended. ''') else: print(dedent(f'''\ A total of {num_test_cases} diagnostics were run in the {location} {system} as of {event_time::%I:%M:%S}}. No anomalies were detected and further action is not required. Test signed by {test_engineer.title()}. ... Raymond
On Thu, 21 Feb 2019 11:59:56 -0800 Raymond Hettinger <raymond.hettinger@gmail.com> wrote:
PEP 8 is mostly about readability. However, the line length limit often seems to cause less readable code.
There are well-known typography rules around line length and readability, both on screen and in print. See e.g.: https://baymard.com/blog/line-length-readability It's not straight-forward how to apply these for code, because it is typically indented, with varying levels of indentation (should the indentation count towards character line length when making up a rule of thumb for readability?). However, there is a commonly held idea - with centuries of experience backing it - that overly long lines makes text or code less readable (look at your typical newspaper or magazine: it splits pages of text into a number of columns so as to limit line width). And "overly long" starts rather early, around 50-80 characters for non-indented text according to most typographers. For code, a 80 character limit is common, as are other limits such as 90 and 100. In any case, each project can customize their pep8 / flake8 settings easily. PEP 8 doesn't aim to be an inflexible standard (we don't even apply it mechanically in the stdlib). Regards Antoine.
saw that today 80 Characters per Line Is a Standard Worth Sticking to Even Today https://dev.to/nickjj/80-characters-per-line-is-a-standard-worth-sticking-to... Abdur-Rahmaan Janhangeer http://www.pythonmembers.club | https://github.com/Abdur-rahmaanJ Mauritius On Tue, 19 Feb 2019, 08:38 Simon, <simon.bordeyne@gmail.com> wrote:
Same arguments made in this thread. I noticed that most of the comments were from folks disagreeing:-) Anyway, the only point to have UNH this discussion on this list is to suggest changes to PEP8. And clearly there is no consensus to increase the line length in the Style guide. So I would like to propose the softening of the language a bit as I proposed earlier in this thread, and other than that call it done. Here’s what I wrote: We could reword: """ Some teams strongly prefer a longer line length. For code maintained exclusively or primarily by a team that can reach agreement on this issue, it is okay to increase the nominal line length from 80 to 100 characters (effectively increasing the maximum length to 99 characters), provided that comments and docstrings are still wrapped at 72 characters. """ To be a bit less harsh -- that is, change the clause: "For code maintained exclusively or primarily by a team that can reach agreement on this issue, it is okay ..." To maybe just "For code maintained by a team that can reach agreement on this issue, it is okay ..." -CHB -- Christopher Barker, PhD Python Language Consulting - Teaching - Scientific Software Development - Desktop GUI and Web Development - wxPython, numpy, scipy, Cython
i thought it interesting as it presented a non py's view of things (web dev) for the 80 chars length. Abdur-Rahmaan Janhangeer http://www.pythonmembers.club | https://github.com/Abdur-rahmaanJ Mauritius
On 26/02/2019 02:01, Christopher Barker wrote:
I would prefer not. The wording as given emphasizes that the team isn't expecting outsiders to work on their code. I think that's quite important, especially when you consider that PEP8 only really has force for the standard library. -- Rhodri James *-* Kynesim Ltd
On Wed, Feb 27, 2019 at 5:53 AM Rhodri James <rhodri@kynesim.co.uk> wrote:
Huh? in the case of the stdlib, the "team" is the python core devs -- they could decide to increase the line length if they want (though I imagine if they did, they's probably change the PEP :- ) Anyway, not a biggie -- just might get folks to chill out a bit and stop pushing to change the PEP ... -CHB -- Christopher Barker, Ph.D. Oceanographer Emergency Response Division NOAA/NOS/OR&R (206) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317 main reception Chris.Barker@noaa.gov
You either have much better eyes to read tiny fonts than I do, or maybe a much larger monitor (it's hard for me to fit a 30"" monitor in my laptop bag). But that's not even the real issue. If the characters were in giant letters on billboards, I still would never want more than 80 of them on a line (well, rarely, I violate PEP 8 sometimes). Centuries if not millennia of experience with writing show that cognitive burden goes up exponentially, not linearly, as lines get to be more than about 60 characters. This is why it's not just code on screen. Magazines, books, wall signs, billboards, and every other written form, insists on similar limits on line length. In printed matter this often means using multiple columns to avoid overly long lines. The issue isn't resolution or size, it's that the human brain simply doesn't process long lines of text will. On Mon, Feb 18, 2019, 11:38 PM Simon <simon.bordeyne@gmail.com wrote:
If that is the issue then we should be talking about non-space characters, not a 68 column limit right? No way does 40 spaces due to indent count towards the cognitive burden :) Also, if the cognitive burden is the issue then we should talk about short forms for keyword arguments again. The way the 68 column limit works in practice is that people avoid keyword arguments because of line length, plus the issues already mentioned. / Anders
From: Python-ideas <python-ideas-bounces+gadgetsteve=live.co.uk@python.org> On Behalf Of Anders Hovmöller Sent: 19 February 2019 06:11 To: David Mertz <mertz@gnosis.cx> Cc: Simon <simon.bordeyne@gmail.com>; python-ideas <python-ideas@python.org> Subject: Re: [Python-ideas] PEP 8 update on line length
If that is the issue then we should be talking about non-space characters, not a 68 column limit right? No way does 40 spaces due to indent count towards the cognitive burden :) Also, if the cognitive burden is the issue then we should talk about short forms for keyword arguments again. The way the 68 column limit works in practice is that people avoid keyword arguments because of line length, plus the issues already mentioned. / Anders [Steve Barnes] If you are getting to 40 spaces of indent, (for _most_ people that is 10 scope changes, e.g. fn then 9 levels of if), then you are already facing a major cognitive burden and should probably be refactoring.
60, or 68, or 80 characters, is not per se a cognitive limit. Yes, sure whitespace counts much less towards that burden than do regular characters. And to a significant degrees, punctuation vs. letters vs. numbers matter. And sure familiar words such as keywords scan a bit easier than unfamiliar names of variables. And so on. But 80 characters in general is already too wide most of the time. 65 is a better goal as a rule of thumb, with 80 already being for exceptionally long lines. Python keywords are already short, there's not much improvement to be had there. Saving two characters for acryptic WHL isn't better than the word 'while', for example. Pretty much the only time my code how's more than 80 characters is when it includes string literally that occupy a large chunk of the width. But if that 50 character string is the last argument of a function call, the reader can mostly stop scanning at it's beginning, so it's not terrible. When I have many keyword arguments, I break them into multiple physical lines using parents too continue the logical line. Or if I have complex compound conditions, I give the subclauses short but descriptive names before the if/elif. On Tue, Feb 19, 2019, 1:11 AM Anders Hovmöller <boxed@killingar.net wrote:
I find that 100 to 120 characters is ideal as far as line length goes. In my opinion, splitting lines is much worse in terms of cognitive burden than just a longer line. On top of that, it's not uncommon to reach 6, even 7 indentation levels. All it takes is a loop in a loop (looping through an array for instance), a condition and all of that inside a class' method. Just in that example, which is a very common occurence, an doesn't warrant refactoring, there is 5 indentation level, eg a quarter of the recommended line length. Defining decorators also goes up there in terms of number of indents by the way. As far as monitor size goes, I agree that on a laptop is not ideal for 100+ characters per line if you want two pieces of code side by side. And, fyi, I work on a 23" monitor at home and on a 15.6" monitor on the go. Both are perfectly fine with 100 characters a line. A good middle ground would be to enforce customization of that rule in the most used python linters. A simple setting to set the number of characters before a linting warning occurs would be acceptable. Envoyé depuis mon smartphone Samsung Galaxy. -------- Message d'origine --------De : David Mertz <mertz@gnosis.cx> Date : 19/02/2019 07:28 (GMT+01:00) À : Anders Hovmöller <boxed@killingar.net> Cc : Simon <simon.bordeyne@gmail.com>, python-ideas <python-ideas@python.org> Objet : Re: [Python-ideas] PEP 8 update on line length 60, or 68, or 80 characters, is not per se a cognitive limit. Yes, sure whitespace counts much less towards that burden than do regular characters. And to a significant degrees, punctuation vs. letters vs. numbers matter. And sure familiar words such as keywords scan a bit easier than unfamiliar names of variables. And so on.But 80 characters in general is already too wide most of the time. 65 is a better goal as a rule of thumb, with 80 already being for exceptionally long lines. Python keywords are already short, there's not much improvement to be had there. Saving two characters for acryptic WHL isn't better than the word 'while', for example.Pretty much the only time my code how's more than 80 characters is when it includes string literally that occupy a large chunk of the width. But if that 50 character string is the last argument of a function call, the reader can mostly stop scanning at it's beginning, so it's not terrible. When I have many keyword arguments, I break them into multiple physical lines using parents too continue the logical line. Or if I have complex compound conditions, I give the subclauses short but descriptive names before the if/elif.On Tue, Feb 19, 2019, 1:11 AM Anders Hovmöller <boxed@killingar.net wrote:
If that is the issue then we should be talking about non-space characters, not a 68 column limit right? No way does 40 spaces due to indent count towards the cognitive burden :) Also, if the cognitive burden is the issue then we should talk about short forms for keyword arguments again. The way the 68 column limit works in practice is that people avoid keyword arguments because of line length, plus the issues already mentioned. / Anders
On Tue, 19 Feb 2019 at 14:08, simon.bordeyne <simon.bordeyne@gmail.com> wrote:
A good middle ground would be to enforce customization of that rule in the most used python linters. A simple setting to set the number of characters before a linting warning occurs would be acceptable.
Any linter or project that treats PEP 8 as mandatory has *already* failed, as PEP 8 itself states that the rules can be broken as needed. Of course individual projects are entirely allowed to impose whatever draconian and inflexible rules they choose on source code formatting, but please don't pretend that PEP 8 made you do it ;-) Paul
I too would argue that it's time to reconsider line length limits. But the reason is not monitor changes, or any particularly strong personal opinion, but changes to python: Let's take a real life example from here <https://github.com/samuelcolvin/pydantic/blob/master/pydantic/utils.py#L246> (changed very slightly for this example), in tranitional python the signature might be: def resolve_annotations(raw_annotations, module_name): 55 characters, all fine. Now let's look at that same function in modern python with type hints: def resolve_annotations(*, raw_annotations: Dict[str, Type[Any]], module_name: Optional[str]) -> Dict[str, Type[Any]]: 119 characters! No daft 5-word variable names, just a clean (if strict) function definition. I don't see how anyone can say that would be more readable with a 80 character line limit. And that's not even an extreme case, we don't have lots of "Optional[..]" or "Tuple[ThingA, ThingB, ThingC]". Type hints (for good or bad depending on your view point) have made python code more verbose, that's just a fact. Code that used to fit on one line with 80char limit now require 120 (or more), therefore in my opinion the recommendation should change to keep up with changes in python. My preference is 120 characters (that's also the default in pycharm I believe). It works well on a desktop monitor, leaving room for a file browser and part of another window, it's also fine on a 13" laptop screen. Then again, every IDE and linter I've used (even black) allows the line length to be varried, so this is only really a problem in the standard library and libraries which adhere closely to pep8. Samuel
On 2/19/19 8:28 AM, Samuel Colvin wrote:
Let's take a real life example from here
<https://github.com/samuelcolvin/pydantic/blob/master/pydantic/utils.py#L246>
If it were me, I'd probably write (or would have re-written when I added the type hints) that as follows: def resolve_annotations( *, raw_annotations: Dict[str, Type[Any]], module_name: Optional[str] ) -> Dict[str, Type[Any]]: which leaves the longest line at 46 characters, even shorter than your original 55. And if the type hints are long, then a similar approach can mitigate that: def resolve_annotations( *, raw_annotations: Dict[str, Type[Any]], module_name: Optional[str] ) -> Dict[str, Type[Any]]:
Nothing says that you have to write an entire function header on one line.
Nothing says that you have to write an entire function header on one line.
Of course. I just think that code with a 7 line function header is much harder to read and understand than code with a one line function header. For example: it's less likely that two chunks of code I'm looking at are still visible on the screen at the same time in the former case. I'm simply arguing that since python has changed, it might make sense to change this recomendation too. That what would have been on one line in 2000 should still be on one line in 2019, despite changes to the language. I'm going to leave this conversation now as it seem to be primarily opinion based and I generally find opinion based discussions almost as annoying as meta-conversations about how the list should be run. :-) Samuel
<https://github.com/samuelcolvin/pydantic/blob/master/pydantic/utils.py#L246> def resolve_annotations(raw_annotations: Dict[str, AnyType], module_name: Optional[str]) -> Dict[str, AnyType]: pass After using https://black.now.sh/ def resolve_annotations( raw_annotations: Dict[str, AnyType], module_name: Optional[str], ) -> Dict[str, AnyType]: pass -- Jonathan
I'm afraid I'm not sure of your point here. (By the way, that code is already <https://github.com/samuelcolvin/pydantic/blob/master/Makefile#L12> run through black, just with a line length limit of 120)
Previously, Samuel wrote that he would leave the conversation, because it was primarily opinion based, which he finds annoying. I then provided evidence (namely how black.py reformats a specific code example). Samuel then wrote:
I'm afraid I'm not sure of your point here.
I wasn't making a point. I was providing evidence. -- Jonathan
On Tue, Feb 19, 2019 at 05:29:33PM +0000, Jonathan Fine wrote:
Evidence of what? What was the point of this evidence? If it was to demonstrate that it is possible to reformat function parameter lists to split over multiple lines, we already knew that. If it was to demonstrate something else, I have no idea what. -- Steven
Steven D'Aprano wrote:
One idea arising from the evidence I provided was that like a word-processor, one could use black.py to 'line-wrap' the Python code to what is the current width of the editor window. Which may vary from person to person. (I did not say it at the time, because I did not have it at the time. And because others might have different useful ideas coming from the same piece of evidence.) See https://mail.python.org/pipermail/python-ideas/2019-February/055424.html -- Jonathan
Samuel Colvin wrote:
I just think that code with a 7 line function header is much harder to read and understand than code with a one line function header.
But to me, a one-line function header that contains 7 lines worth of charaacters is *less* readable than a 7-line header, as long as it's formatted intelligently. The readability problem here is not caused by insufficient width. It's caused by the need to stuff a bunch of annotations into the header. -- Greg
I would like to point out here that breaking up a line breaks grepping quite badly. I've had to write AST-based searches to find simple usages of arguments in the code base at work precisely because of code that is split on likes like this. (This tool is available here: https://github.com/boxed/parso_utils) I would vastly prefer a soft like break algorithm that formatted the code as per your examples and having the code on disk be single line no matter what. In proprietary projects where one can agree on the tools used for the code this can be quite doable, but I agree it's not great for open source projects. / Anders
On 19.02.2019 18:06, Anders Hovmöller wrote:
This should help: https://stackoverflow.com/questions/3717772/regex-grep-for-multi-line-search... but you can also use Python's re module with the re.DOTALL flag. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Experts (#1, Feb 19 2019)
::: We implement business ideas - efficiently in both time and costs ::: eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48 D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg Registered at Amtsgericht Duesseldorf: HRB 46611 http://www.egenix.com/company/contact/ http://www.malemburg.com/
Maybe you know some grep magic I don't? Is there a way to do multi line grep that knows that open paren means to ignore new lines until the matching close paren? I'd love to hear about it!
I probably don't know any more grep magic than you, I've just never had cause to grep for anything that long. I am a touch bemused that you do frequently have cause, but each to his own, I suppose.
Not often. Once. But then I really really needed it :) It was a case where we had an API change to a lib and many calls where long enough to be split on multiple lines AND the keyword argument we had to find was very generic AND it could exist in nested calls. Of course the last was really fine since we could ha e worked through the false positives manually. I also happen to have lots of experience with Parso so it was easy for me to write. Otherwise we would probably have a logged through the crappy way. It's pretty nice to have this is the tool belt though. / Anders
On 2/19/19 11:06 AM, Anders Hovmöller wrote:
At the risk of jumping in over my head with respect to the technical limitations of regular expressions, grep already can't deal with matching parenthesis. Consider: f(g(h(a=4), b=5), c=6) Can grep tell me that I'm passing c to f but not to g or h? Disclaimer: I don't write code like that. Most of the time.
Samuel Colvin wrote:
I would argue that it *is* more readable if it's not all on one line: def resolve_annotations(*, raw_annotations: Dict[str, Type[Any]], module_name: Optional[str]) -> Dict[str, Type[Any]]: Having thus improved its readability, an 80-char line limit is no longer a problem. -- Greg
[Samuel Colvin]
I don't see how anyone can say that would be more readable with a 80 character line limit.
For starters, type annotations don't add anything that good documentation would have required before. In most docstring style guides that I know of, the arguments list is supposed to be at least one line per argument, so really it should look like so: def resolve_annotations(raw_annotations, module_name): """ description of what the function does Arguments: raw_annotations (type annotation): description of raw_annotations module_name (type annotation): description of module name Returns (type annotation): description or return value """ Which can easily be replaced with: def resolve_annotations( raw_annotations: Dict[str, Type[Any]], module_name: Optional[str]) -> Dict[str, Type[Any]]: """ description of what the module does Arguments: raw_annotations: description of raw_annotations module_name: description of module name Returns: description or return value """ Often, I find, people make add a lot of redundant noise to names which is either clear from context like; math.log, not math.mathematical_log_function, or doesn't add anything like; user_data instead of user, or job_info instead of job, or raw_annotations instead of annotations. It's often just as good to write: def resolve(annotations: Dict[str, Type[Any]], module: Optional[str]) -> Dict[str, Type[Any]]: """...""" On Tue, Feb 19, 2019 at 8:30 AM Samuel Colvin <S@muelcolvin.com> wrote:
On Tue, Feb 19, 2019, 9:07 AM simon.bordeyne <simon.bordeyne@gmail.com wrote:
I find that 100 to 120 characters is ideal as far as line length goes.
I very much hope no one else where had to read it review your code. In my opinion, splitting lines is much worse in terms of cognitive burden
than just a longer line. On top of that, it's not uncommon to reach 6, even 7 indentation levels.
In 20+ years of programming in Python (writing some will known books about it too), I have never once indented a block 7 levels. Very, very rarely 6. If you do that, your code has serious problems beyond line length. As far as monitor size goes, I agree that on a laptop is not ideal for 100+
characters per line if you want two pieces of code side by side.
In a readable size and font, I get two vertical panes of 71 characters on my 15" Retina display. I can read a smaller font character by character, but not easily scan a line. Here I'm just taking about visual accuity, not the cognitive issue. My vision in particular remains 20/20 for near vision (but sadly decayed with age for distance). It used to be more like 20/15, but I never used lines longer than 80 characters in any programming language (yes, individual lines, but not as a rule). I did used to use a somewhat smaller font size though. I guarantee that your code quidditch would improve if you use both shorter lines and a larger font. The latter only affects your interaction with your screens, the former is essential to everyone who needs to look at your code. And, fyi, I work on a 23" monitor at home and on a 15.6" monitor on the go.
Every linter I know about is customizable this way.
On Tue, Feb 19, 2019 at 03:07:23PM +0100, simon.bordeyne wrote:
Clearly that is not "all" it takes, since that's only *five* indents, not 6 or 7: class X: def method(self): for a in seq: for b in other: if cond: print("five indents") [...]
Just in that example, which is a very common occurence, an doesn't warrant refactoring
Doesn't it? Maybe it does, maybe it doesn't. It depends on what's going on inside the method. Maybe it should be written as a function (avoiding one indent). Maybe the row and column processing should be factored out into seperate methods: class X: def method(self): self.process_rows(seq) def process_rows(self, rows): for a in items: self.process_columns(a, other) def process_columns(self, a, cols): for b in cols: if cond: print("four indents") When this is possible, it has other advantages than merely saving one indent: we can test and document the row and column processing seperately, and reduce coupling between the components. (I can understand the column processing without caring about the row processing, and visa versa.) This is what I meant when I said that sometimes, the discipline required to keep to 79 columns helps give you better code. I started off wanting only to save an indent, but I got better documentation, better tests, and less coupled code that is easier to maintain. Of course sometimes you get *worse* code by refactoring. In which case you shouldn't do it :-) -- Steven
[simon.bordeyne]
I find that 100 to 120 characters is ideal as far as line length goes.
Your finding goes against a long history of people attempting to present text in the most readable way possible. AFIK, the human fovea hasn't grown much larger in recent years. [simon.bordeyne]
On top of that, it's not uncommon to reach 6, even 7 indentation levels.
It should be pretty uncommon. You might want to re-think your coding style if you're regularly writing code that's so deeply indented. A good trick is to use helper functions: #instead of this if condition: ...code #do this if condition: handle_it() [simon.bordeyne]
You should check out the itertools library and possibly the toolz package. I find it's often pretty simple to collapse nested loops in python: for n, element in enumerate(chain(*array)): r, c = divmod(n, len(array[0])) # if you need the indexes if condition(element): do_something(element) # this follows the one-line one-thought rule over PEP8 On Tue, Feb 19, 2019 at 8:08 AM simon.bordeyne <simon.bordeyne@gmail.com> wrote:
On Thu, Feb 21, 2019 at 11:09 AM Abe Dillon <abedillon@gmail.com> wrote:
You can't see the entire line in focus simultaneously anyway, so the line length is about how far you can flit your eye left to right, not the actual fovea itself.
And this is always cited as the "obvious" solution. The trouble is, unless "handle_it" has a name that tells you EVERYTHING about what it does, you probably will end up having to go look at its definition - which means a lot more flicking around. The cost of a long line has to be balanced against the cost of *avoiding* having a long line. Splitting a line into consecutive lines has less cost than breaking it out into a function, *unless* the function truly has its own meaning. ChrisA
[Chris Angelico]
And this is always cited as the "obvious" solution.
Yes. I think simon even referred to this "obvious" solution in his post when he said, "...which is a very common ocurence, *and doesn't warrant refactoring*" So, my comment may have been unwarranted. [Chris Angelico]
I think you're over emphasizing "EVERYTHING" and "probably". If your de-bugging or refactoring, You typically have enough context to make an educated guess if you need to look deeper. The Wikipedia for the game Tic-Tac-Toe (AKA Nots and Crosses) describes a strategy <https://en.wikipedia.org/wiki/Tic-tac-toe#Strategy> play(board, my_mark): # Win moves = win(board, my_mark) if moves: return random.choice(moves) # Block moves = win(board, opposite(my_mark)) if moves: return random.choice(moves) # Fork moves = fork(board, my_mark) if moves: return random.choice(moves) # Block Fork moves = fork(board, opposite(my_mark)) if moves: return block_fork(moves, board, my_piece) # Center if board[1][1] is None: return (1, 1) # Corners moves = empty_corners(board) if moves: return random.choice(moves) # Sides moves = empty_sides(board) if moves: return random.choice(moves) # Failing test board = [['O' , None, None] ['X' , 'X' , None] [None, None, None]] mark = 'O' result = play(board, mark) expected = (1, 2) assert move == expected, f"Block! Expected: {expected}, Got: {result}" You don't need to know EVERYTHING about how block_fork works to debug that failure. You probably don't need to know EVERYTHING about how random.choice works either. You don't need to know about how most of the functions in the code work. The code is not blocking an opponent's win. The fault must be in "win" or "opposite". [Chris Angelico]
That's a good point. Pragmatism should always win the day, of course; and excessive functional decomposition can cause it's own readability issues. I only offer it as a strategy, not a flawless solution. Sometimes going beyond 80 columns is the most pragmatic choice, but such cases should be rare. On Wed, Feb 20, 2019 at 6:23 PM Chris Angelico <rosuav@gmail.com> wrote:
On Thu, Feb 21, 2019 at 12:26 PM Abe Dillon <abedillon@gmail.com> wrote:
Not about HOW it works. That's irrelevant. You DO need to know about what it does, which is what I said. In the case of random.choice, that's very clearly defined by its documentation: it chooses a random element from the thing you give it. If you don't know that, you have to look it up to determine whether that's the problem. ChrisA
[Chris Angelico]
Not about HOW it works. That's irrelevant. You DO need to know about what it does, which is what I said.
So it is. I'm sorry I misread your comment. [Chris Angelico]
that's the problem. I think you're missing the point. The name random.choice alone, doesn't fully describe its interface, yet the first time I came across it in code, I didn't feel the need to go look into documentation. I'm betting you could make a pretty good educated guess of the interface of all the functions in the code I wrote above. Humans aren't computers. We can and do deal with ambiguity all the time. We can usually make a pretty good guess whether we need to drill down into a function to find a bug even if we don't know EVERYTHING about what the function does. Sometimes that educated guess is wrong and we have to back up and look at things we initially thought were irrelevant, but we're not as brittle to ambiguity as you seem to think. On Wed, Feb 20, 2019 at 7:35 PM Chris Angelico <rosuav@gmail.com> wrote:
On 2/18/2019 11:37 PM, Simon wrote:
Strictly speaking, PEP8 applies only to CPython stdlib code. Please read the introduction. Adapt it as you will for your code.
The majority of core developers, to whom PEP 8 applies, seem to disagree.
Do you every print on paper? In tiny type? Or sideways? Anyway, 3 80-column windows side-by-side is really nice. For instance, shell, code file, test file. -- Terry Jan Reedy
On 19Feb2019 00:09, Terry Reedy <tjreedy@udel.edu> wrote:
I'm not a core developer and I also disagree.
I like 4 80 column windows. 2 for the editing and either 2 shells or a single wide shell. And 80 columns doesn't really influence my variable name sizes. The longer the line, the harder it is to apprehend. To my mind 80 columns is a nice upper limit: long enough for expressiveness, short enough to easily scan. Cheers, Cameron Simpson <cs@cskk.id.au>
Am 19.02.19 um 05:37 schrieb Simon:
If I read PEP8 correctly, the limit is effectively extended to 100 (well, 99) characters already: Some teams strongly prefer a longer line length. For code maintained exclusively or primarily by a team that can reach agreement on this issue, it is okay to increase the nominal line length from 80 to 100 characters (effectively increasing the maximum length to 99 characters), provided that comments and docstrings are still wrapped at 72 characters. https://www.python.org/dev/peps/pep-0008/ Mike
On Tue, Feb 19, 2019 at 05:37:29AM +0100, Simon wrote:
I know this is not precisely what you are arguing, but the thought of people arguing that the only problem with a 300-character Perl one-liner is that their monitor is too narrow to view it amuses me :-)
The width of source code on old green-screen 80 column terminals may be a factor, but it probably isn't the most important factor. You might consider that even when broadsheet newspapers have up to 23 inches in width, they still format their text in much narrower columns. The typical line of text in a paperback is 60-70 characters including spaces. We have many centuries of experience teaching us that 60-70 columns of text is typically as wide as people can comfortably read. I'm not an expert, but my understanding is that the limiting factor is not so much the cognitive burden of reading 100+ characters but the physical motion of the eyes tracking back and forth across the long lines. The wider the line, the greater the chances that the eye will run off one line into the one below it, and the more eye-strain. Source code isn't as dense as prose, and is more line-oriented than paragraph-oriented, so we can afford to exceed 70 columns occasionally, but not too often. If people are regularly exceeding 80 columns, I would consider it a code smell and inspect the code carefully for these problems: - indents may be too wide (8 spaces instead of 4?); - code may be too deeply nested (too many indents); - variable names may be excessively long; - possibly too many violations of the Law of Demeter: paperboy.take_fee(customer.trousers.right_pocket.get_wallet().remove(fee)) - or just generally, too much complexity per line.
Do we? That's a rather sweeping generalisation. It may be true in some cases, but in other cases, the discipline of keeping to the 79 column limit can result in better code. But don't go mad about it: Raymond Hettinger did a very good talk called "Beyond PEP 8" which (correctly in my opinion) argues against worrying about small violations of PEP 8, in favour of more substantial efforts to beautify your code. https://www.youtube.com/watch?v=wf-BqAjZb8M In my own code, I take the 79 column limit as more of a guideline than a law, if I have to go over by 2 or 3 characters, I just do it and don't worry unless it is a more substantial violation. All those "tricks" you mention are not necessarily bad things, they can often be justified. If you have a function or method with eight levels of indentation, you probably should reduce the amount of indentation by refactoring. If you have variables like number_of_pages_in_current_section you probably should consider a shorter name. Your IDE may make it easy to write such long names, but it doesn't make it easy to read them. -- Steven
I don't think you will find an agreement to raise the number of line length (we didn't even manage to find an agreement at my job with less than 10 people), so I would suggest every reader not interested in the disscussion to put it into the bin directly, as no decision will emerge from here. That beeing said, the probable best limit should be None, and let everyone's text editor line up the things the way people want to read them.
I understand that the writer wants to have shorter names, but why would I want more ambigious names as a reader ? How would you rename number_of_pages_in_current_section such that the reader is not left wondering what does this variable represents ? -- *Nicolas Rolin* | Data Scientist + 33 631992617 - nicolas.rolin@tiime.fr <prenom.nom@tiime.fr> *15 rue Auber, **75009 Paris* *www.tiime.fr <http://www.tiime.fr>*
My two cents, because this is a subject about which I have a strong opinion: - Yes, VT100s and other green screen terminals have long since been out of fashion, but there are still some people, including myself, who like their xterms and iTerms in the standard size (80x24). Also, we sometime need to browser code from a smartphone, in which case physical (not just virtual) screen size is really an issue. - Yes, for maximum code readability, it's better to optimise for ~70 no whitespace characters max, which is approximately 80 characters overall if you you put space properly around / after commas, plusses, equals, etc. - OTOH: there is now a wonderful tool called Black ( https://github.com/ambv/black ) which is so good at turning badly formatted code into readable code that I've stopped worrying about this kind of issues (even though, as stated initially, I have a strong attachment to it). Black's default is 88, not 80, which conflicts a bit with the two previous points, but Black is, IMHO, so good that I've stopped thinking about it (there is a way to override the default setting, which I should be using, but I don't). Cheers, S. -- Stefane Fermigier - http://fermigier.com/ - http://twitter.com/sfermigier - http://linkedin.com/in/sfermigier Founder & CEO, Abilian - Enterprise Social Software - http://www.abilian.com/ Chairman, Free&OSS Group @ Systematic Cluster - https://systematic-paris-region.org/fr/groupe-thematique-logiciel-libre/ Co-Chairman, National Council for Free & Open Source Software (CNLL) - http://cnll.fr/ Founder & Organiser, PyParis & PyData Paris - http://pyparis.org/ & http://pydata.fr/
On Tue, Feb 19, 2019 at 9:38 PM Nicolas Rolin <nicolas.rolin@tiime.fr> wrote:
I understand that the writer wants to have shorter names, but why would I want more ambigious names as a reader ? How would you rename number_of_pages_in_current_section such that the reader is not left wondering what does this variable represents ?
page_count will usually be unambiguous. You might need total_pages to mean "not the current section", thus leaving the shorter one available for the narrower use. Obviously questions like this can't be answered without context, but at an absolute minimum, "number_of" can almost *always* be omitted. ChrisA
On Wed, Feb 20, 2019 at 11:19 AM Steven D'Aprano <steve@pearwood.info> wrote:
Fair point. However, in any context where "pages" could be a list of pages, you are unlikely to need a separate "pagecount", as it's just the length of the list. Maybe it's the number of pages you're _going_ to need, or something. But it's nearly impossible to judge without context. Maybe "almost always" was too strong, but in real-world contexts, I don't often need to specify that something is the "number of" something. ChrisA
I wrote: <quote> <https://github.com/samuelcolvin/pydantic/blob/master/pydantic/utils.py#L246> def resolve_annotations(raw_annotations: Dict[str, AnyType], module_name: Optional[str]) -> Dict[str, AnyType]: pass After using https://black.now.sh/ def resolve_annotations( raw_annotations: Dict[str, AnyType], module_name: Optional[str], ) -> Dict[str, AnyType]: pass </endquote> Samuel Colvin then told us that his example was already formatted with black.py, using a long line length. Here's a suggestion, at least for people projects that use black.py (such as Samuel's). It is to use black.py with a line-length of say 80 characters for code that is saved in version control. And when editing code, use whatever line-length that happens to suit the tools you are using. Indeed, like a word-processor, one could use black.py to 'line-wrap' the Python code to what is the current width of the editor window. Indeed, this might be a useful feature in Jupyter - see https://github.com/drillan/jupyter-black. And I've created https://github.com/drillan/jupyter-black/issues/3 Perhaps set the black line length to the width of the text box -- Jonathan
On Thu, Feb 21, 2019 at 6:48 AM Jonathan Fine <jfine2358@gmail.com> wrote:
Of course, if you assume that everything in your code is perfect, then by all means, reformat it however you like. If you're 100% confident that nobody writes any buggy code, then the formatting doesn't matter, and you can display it in whichever way looks prettiest. But if you appreciate ways of discovering bugs more easily, preserve everything that represents the programmer's intention. ChrisA
Opinion first - I don't see a need to change PEP 8. I recommend 100 char width for Python, which is acceptable under PEP 8 anyway. I think the real limit should be around 70 characters per line, not including leading white-space, but I realize that's impractical. I work mostly at 100 character line width, and the question of line width came up for me recently. Otherwise, I follow PEP 8. I want to see where, and why I exceed 79 chars, so I dove into a decently sized module file of mine and tallied the results. This is what I found. 563 total lines 448 non-blank lines For the non-blank lines: 49.6 characters per line on average 36.7 non-leading-whitespace characters per line 13.1 leading spaces per line on average 15.5% of lines exceeded 79 chars. The 69 lines that exceeded 79 characters fell into the following categories, listed according to how annoying they would be to fix. 1 - with statements I have a with statement that contains two context managers "with open(blah) as b, open(foo) as f:". There isn't a really good way to wrap this without adding another with statement or a backslash. 3 - function calls Function calls, even with the arguments put one per line, often exceed 80 (and sometimes 100) character limit. The issue tends to be a combination of tabbing, kwarg names, and the context in which all of this is used. It's often unavoidable. variable = some_class.method(argument=value, argument2=value) 5 - Overly deep logic There were a couple of blocks of code that should have been pushed into separate methods/functions. I do occasionally run into issues where there simply isn't room (in 79 chars) for the logic required, and that logic can't reasonably be separated out. 8 - Format calls While I love the new format syntax, I almost always end up moving the format call to a new line with 4 spaces of extra indentation. These were instances of when I didn't. 21 - Comments There's plenty of space for readable comments in most cases. Under several nested scopes, however, the space gets pretty tight. Those extra 20 chars go a long way. 12 - Strings Like comments, having a few extra chars for strings (mostly exception messages in this case) goes a long way when even moderately nested. 2 - Chained conditionals if A and B and C Should have been: if (A and B and C): 16 - Doc strings These are easily fixable with no change in readability, and rarely have issues with padding. On Wed, Feb 20, 2019 at 12:57 PM Chris Angelico <rosuav@gmail.com> wrote:
-- Paul Ferrell pflarr@gmail.com
First of all, thank you so much for taking the time to do some actual analysis! I only have one thing to add: [Paul Ferrell]
This reminds me of a bit that shows up often in Kevlin Henney's talks <https://www.youtube.com/watch?v=B3b4tremI5o&t=7m45s>. A better way to list arguments is only one indentation level above the current: variable = some_class.method( argument=value, argument2=value) Trying to match the indentation of the opening line is less readable and less robust to refactoring: variable = some_class.method(argument=value, argument2=value) var = cls.method(argument=value, argument2=value) On Wed, Feb 20, 2019 at 4:52 PM Paul Ferrell <pflarr@gmail.com> wrote:
Most of this thread is all just so much opinion, so I have avoided chiming in -- but as for opinion: <histrionic> A better way to list arguments is only one indentation level above the
God no! I HATE that style -- for me, it makes it MUCH harder to read -- even more so if the variable names are a bit longer. But if you are going to do it, for the love of god, use more than four spaces! four spaces is one indentation, one indentation is how a code block is delineated in Python -- this is NOT a code block. It should not look like one. </histrionic> By the way, this is much worse for, say, function definitions: def a_function_with_lots_of_params( param1, param2, kwarg1=something, kwarg2=something_else): now_a_line_of_code = this_thing() How can anyone think that's more readable than (view with fixed-width font if this email doesn't already do that for you): def a_function_with_lots_of_params(param1, param2, kwarg1=something, kwarg2=something_else): now_a_line_of_code = this_thing() This puts the parameter definitions over on the right, after the function name, where they belong, and makes it very clear where the definition ends and the function code begins. But if you HAVE to put it off to the left for I don't know why, at least put some extra space in there: def a_function_with_lots_of_params( param1, param2, kwarg1=something, kwarg2=something_else): now_a_line_of_code = this_thing() The parameters are still in an odd place, but at least it's clear where the body of the function begins. If you need more convincing, consider functions with fewer params, and how they look compared to ones with many: def a_function_with_few_params(param1, param2): now_a_line_of_code = this_thing() then: def a_function_with_lots_of_params( param1, param2, kwarg1=something, kwarg2=something_else) now_a_line_of_code = this_thing() why am I looking in a different place for the parameters when there are more of them?? Trying to match the indentation of the opening line is less readable
variable = some_class.method(argument=value, argument2=value)
this is more readable to me :-)
and less robust to refactoring:
var = cls.method(argument=value, argument2=value)
well, that is an issue that I do face, but I blame it on my crappy tools :-) But YAPF does it the way I like :-) Except in the case of the "facebook" style -- yeach!) https://yapf.now.sh/ Facebook style: def a_function_with_lots_of_params( param1, param2, kwarg1=something, kwarg2=something_else ): now_a_line_of_code = this_thing() Anyway, PEP8 is officially for the standard library, but it HAS become a python-wide standard. As such, it simply needs to be flexible on some of these opinionated issues -- so both of the above styles are OK, as is adjusting your max line length up some. So at most, I'd say rewording this: """ Some teams strongly prefer a longer line length. For code maintained exclusively or primarily by a team that can reach agreement on this issue, it is okay to increase the nominal line length from 80 to 100 characters (effectively increasing the maximum length to 99 characters), provided that comments and docstrings are still wrapped at 72 characters. """ To be a bit less harsh would be a fine idea -- that is, change the clause: "For code maintained exclusively or primarily by a team that can reach agreement on this issue, it is okay ..." To maybe just "For code maintained by a team that can reach agreement on this issue, it is okay ..." Then we can all go back to bike-shedding something else. -CHB PS -- I personally use 95 char per line :-) -- Christopher Barker, PhD Python Language Consulting - Teaching - Scientific Software Development - Desktop GUI and Web Development - wxPython, numpy, scipy, Cython
[Christopher Barker]
Holly hell! I'm sorry I insulted your mother or whatever serious crime I committed. Yes, I agree that two levels of indentation is an improvement and is in-fact how I write function definitions. [Christopher Baker]
this is more readable to me :-)
I wish you would have watched the video I linked <https://www.youtube.com/watch?v=B3b4tremI5o&t=7m45s> so I wouldn't have to make all the same arguments, but in the context of code running off the edge of a window, having the argument list hidden out there with arbitrary indentation is definitely a readability issue. [Christopher Baker]
This puts the parameter definitions over on the right, after the function name, where they belong
According to whom? [Christopher Baker]
If you'd seen my other replies in this very thread, you'd see that's exactly the style I use. [Christopher Baker]
well, that is an issue that I do face, but I blame it on my crappy tools :-)
I consider it a good thing that your tools don't facilitate bad coding style ;) This is just more Stockholm syndrome. Nowhere else will you see people consider cramming valuable information off into the right margin with arbitrary indentation "good design". You won't see it in prose. You won't see it in mathematical notation. You won't see it anywhere else. On Wed, Feb 20, 2019 at 8:42 PM Christopher Barker <pythonchb@gmail.com> wrote:
On Wed, Feb 20, 2019 at 10:57 PM Abe Dillon <abedillon@gmail.com> wrote:
I wish you would have watched the video I linked <https://www.youtube.com/watch?v=B3b4tremI5o&t=7m45s>
that is an hour and 7 minute video! And I did watch some of it, and do agree with much of it. By the way, everyone should watch one of Jack Diederich's "naming things once videos as well: https://www.youtube.com/watch?v=hZ7hgYKKnF0
but in the context of code running off the edge of a window,
I never said anything about running off the edge of the window -- if you put all your parameters on their own line, and don't use insanely long names, that will not be an issue. Keeping it to 72 chars is virtually never a problem.
having the argument list hidden out there
nothing hidden about it --it's exactly where a single argument would be -- does anyone advocate putting a single parameter or argument on the next line? But my core point really was these are all matter of opiniion, and it's a godo thing that PEP 8 allows some variation.
According to me, of course. But it is wehre a single parameter would be, yes?
I've lost track of who advocates what style, but I was responding to someone that specifically advocated one level of indentation -- which is really the worst option. [Christopher Baker]
mostly they don't facilitate any of these styles in this context (I've been meaning to write a plugin for sublime that does, but haven't gotten around to it ). But the point is that handling indenting is really something the tools should do for you -- choosing a style for "ease of refactoring" should be pointless.
This is just more Stockholm syndrome.
honestly, I haven't chooses this style due to having been forced (or even encouraged) to use it -- I spend more time re-aligning code to make it the way I want it -- so no, I"ve come on this 'cuse it fits my brain better.
Nowhere else will you see people consider cramming valuable information off into the right margin with arbitrary indentation "good design".
It's not the margin, and it's not arbitrary.
You won't see it in prose. You won't see it in mathematical notation. You won't see it anywhere else.
Actually, I"ve seen in it math, where you have an "array" of equations, and
OK, then use two indentation levels for the parameter stack -- just don't use one -- that really is the worst option -- one indentation has real meaning in code. -CHB -- Christopher Barker, PhD Python Language Consulting - Teaching - Scientific Software Development - Desktop GUI and Web Development - wxPython, numpy, scipy, Cython
On 2019-02-20 18:41, Christopher Barker wrote:
I feel the complete opposite. "One indentation" is the only unit in multiples of which anything should ever be indented. Using arbitrary "indentation" to visually line things up is horrible. Everything gets indented by an integer number of indentation levels. It was mentioned earlier on this thread, but I think the real problem is editors. Specifically, people have become used to certain editor behaviors and conventions which are not actually that great, and as a result editors have not emphasized features which would be better. Even more specifically, people have not insisted that editors be designed to support a reader-oriented, rather than writer-oriented, approach to code display. In other words, visual details how the code is displayed should be up to person reading the code, not the person who wrote it. Instead, people have apparently for a long time insisted on the reverse, namely editors which format things as the code is written, by inserting actual characters in the file to make things like up visually. Characters shouldn't be in the file to make things like up visually; they should be there for their semantic importance. If that is done, then the editor can render those semantics in different ways according to the viewer's preference. The problem is that editors don't do this, because people have somehow gotten the idea that this would be a bad thing. So instead we have to argue over things like this, because whatever purely cosmetic choices one person makes in indenting his or her code become baked into the actual bytes of the file, and cannot be rendered differently later according to the preferences of a different viewer. I've rather forlornly given up on dealing with any of this. I use an editor that VISUALLY wraps long lines and maintains the indentation on the wrapped portion, without changing the bytes in the file. I make my lines as long as I want, inserting linebreaks only where they have a semantic reason to be (such as between multiple long conditions in an "if"). Everything is fine, until someone else looks at the code, and they have an editor that is only designed to display code that has the formatting baked into the whitespace. As a result, I consider this issue pretty much moot. There is no reason for the line length limit to be set to 100 or 120 or anything else. There are already too many problems with PEP 8 that stem from a desire to use whitespace for visual alignment rather than semantics (such as using spaces instead of tabs). So I just basically ignore PEP 8 and follow my own style, which happens to overlap in some respects with PEP 8 and diverge from it in others. -- Brendan Barnwell "Do not follow where the path may lead. Go, instead, where there is no path, and leave a trail." --author unknown
Brendan Barnwell wrote:
I don't think that taking an excessively long line of code and mechanically wrapping it to a narrower width makes in any easier to read. Like you say, readability relies on making intelligent decisions about where to break lines based on their semantics. So even if everyone is equipped with an auto-wrapping code editor, there is still going to be code that really needs at least N characters of width to display properly, and looks terrible when wrapped to anything less. Think about how annoying it is when an email message gets re-wrapped to a slightly narrower width than it was originally written with -- and apply that to code. -- Greg
Abe Dillon <abedillon@gmail.com> writes:
Yes, that's unfortunate, but I still prefer the latter, and usually I accept the hassle and realign the remaining lines. In hindsight, I wish someone with a powerful time machine could introduce the concept of "one-indent-level-and-half" for continuation lines: the statement that most annoys me is the "if" when the condition is very long, because my eyes suffer when I see the following: if condition1 and \ condition2 and \ condition3: do_something() or even if (condition1 and condition2 and condition3): do_something() at the point that I usually use a double paren just to have one single space of difference between the continued condition elements and the succeeding suite: if ((condition1 and condition2 and condition3)): do_something() ciao, lele. -- nickname: Lele Gaifax | Quando vivrò di quello che ho pensato ieri real: Emanuele Gaifas | comincerò ad aver paura di chi mi copia. lele@metapensiero.it | -- Fortunato Depero, 1929.
On Wed, Feb 20, 2019 at 11:51 PM Lele Gaifax <lele@metapensiero.it> wrote:
that most annoys me is the "if" when the condition is very long, because my eyes suffer when I see the following:
yup -- "if (" is four spaces -- exactly one indentation level -- that is really painful. I've got to figure out how to get flake8 to stop yelling at me for making that more readable :-) of difference between the continued condition elements and the succeeding
ouch! ehy not jsut do: if (condition1 and condition2 and condition3)): do_something() (or any number of other options) and teach your linter that that's OK (or ignore your linter) -CHB -- Christopher Barker, PhD Python Language Consulting - Teaching - Scientific Software Development - Desktop GUI and Web Development - wxPython, numpy, scipy, Cython
Christopher Barker <pythonchb@gmail.com> writes:
Because I would first need to teach Emacs the aforementioned "indent-and-half" for continuation lines :-) ciao, lele. -- nickname: Lele Gaifax | Quando vivrò di quello che ho pensato ieri real: Emanuele Gaifas | comincerò ad aver paura di chi mi copia. lele@metapensiero.it | -- Fortunato Depero, 1929.
On Thu, 21 Feb 2019 at 12:20, Paul Ferrell <pflarr@gmail.com> wrote:
My linter is fine with a double indent after an 'if (A and'. I thought it was in the standard.
If I used a linter, I'd expect it to be fine with whatever I told it to be fine with :-) It's a linter's job to flag up violations of the coding style *I* choose to follow, not to impose a coding style on me that I don't agree with. Paul
A general rule of thumb is, if Python feels inconvenient or awkward, you’re doing something wrong.
On Tue, Feb 19, 2019 at 11:38:04AM +0100, Nicolas Rolin wrote:
Excellent question! Note that I didn't say that long names are *necessarily* a problem, only that they could be. I would start by reading the code and asking two questions: 1. Does the name really need to specify that it is the number of pages in the *current* section? Unless you have multiple such variables: number_of_pages_in_current_section number_of_pages_in_previous_section number_of_pages_in_next_section the chances are very good that "in_current_section" is pointless information that the reader will infer from context: for section in sections: number_of_pages = len(section) 2. Do you really need such a verbose name spelled out in full? Instead of "number_of_pages", perhaps "num_pages" is enough. If it is obvious from context, perhaps even "num" or even "n" is enough. If you dislike such standard abbrevations, how about "pagecount"? Short names are not necessarily ambiguous, and long names are not necessarily clear: process(the_current_thing_we_are_processing_right_now) is no less ambiguous or any more clear than: process(thing) In a well-written function that isn't too long, we ought to be able to find the definition of any local variable no more than half a page away. Local variables are usually far more limited in their scope and lifetime and the need for them to be self-documenting is correspondingly reduced. Insisting that *every* name must be meaningful *in isolation* is an over-reaction to poor quality code. Typically we read code in context: we can see the rest of the function and the definition of the variable is only a handful of lines away. The interpreter doesn't care what you call your variables, names are purely comments for the reader. It isn't true that the more comments the better, and the same applies to naming: - Just as comments can lie, so can names. I expect we've all read code where the names are actively misleading: mylist = {key: value} - Comments shouldn't simply repeat the obvious meaning of the code: x += 1 # add 1 to x and neither should variable names. If meaning can be inferred from the obvious meaning of the code, the need to spell out the meaning in full is reduced. (See my example above of number_of_pages.) - When writing comments we should eschew sesquipedalian loquaciousness x += 1 # increment the value of the variable x by the successor integer to the additive identity of Z and we ought to do the same for variable names. -- Steven
On 2/18/19 8:37 PM, Simon wrote:
I'd like to propose an update to PEP8. Indeed, the 80 characters per line guideline is, I feel, outdated.
Hi, I don't agree it is outdated. As someone who has a second 4k monitor in portrait mode to minimize scrolling (recommended), the ~80 char line limit avoids the need for horizontal scrolling as well. This isn't your father's Oldsmobile, haha. When in landscape on the go I can have two windows open side by side, say an editor and documentation/mail at the same time, aka multitasking. Not as good as a second monitor, but better than nothing. Other folks have chimed in on how newspapers and magazines limit line length for readability purposes. I suppose if you code fullscreen (or near it) on a 16:9 monitor, longer lines might be desirable. Worked at a place where a co-worker frequently produced code with ~200 character lines despite calls to cease and desist. Looked over once, and sure enough a full+widescreen editor. Nostalgic for DOS, or focused like a laser? Not sure. The issue is unfortunately exacerbated by the monitor industry forcing us all to 16:9 aspect ratios, outside of the MacBook and tablets. That was a regression in my opinion. -Mike
On 2/21/19 10:53 AM, Paul Ferrell wrote:
I think the solution is for everyone to rotate their widescreen monitors 90° into a really tall portrait mode. :)
Yep, that's what I do, but would prefer a squarer monitor so I could get two windows side by side on that one also. My old 1600x1200 4:3 in portrait allowed that comfortably. 16:10 might. -Mike
Some feedback: I code on a 13.5 inch laptop. I split my screen between my browser on the left half and editor on the right half of the screen. The 80 character suggestion has been helpful to me in reading code. Otherwise I'd use up time with random horizontal scrolling. On Thu, Feb 21, 2019 at 4:11 PM Mike Miller <python-ideas@mgmiller.net> wrote:
On Feb 18, 2019, at 8:37 PM, Simon <simon.bordeyne@gmail.com> wrote:
I'd like to propose an update to PEP8. Indeed, the 80 characters per line guideline is, I feel, outdated.
I concur. We now put expressions in f-strings and have assignment expressions that easily spill over 80 characters if one uses all but the most compact variable names. Comprehensions tend to make expressions longer. Queries and filters in Pandas also easily spill over. The 80 character limit pre-dates these evolutions of the language. In particular, the case where I most want to let people run with long lines is in forming messages to be displayed to a user. Templates can get fat even if the displayed message is not long. The code is more readable if people don't mangle their templates with line wrapping. class Frabawidget: ... @wozzle.setter def (self, woozle): if not (self.min_woozle < woozle < self.max_woozle): raise ValueError(f"Expected woozle to be between {self.min_woozle} and {self.max_woozle}") self._wozzle = normalize(woozle) In doing code reviews, I see many fewer atrocities from long lines than I do from weird line-wraps and from variable names that have been over-shortened to make the line fit in 80 characters. To avoid these issues, my clients typically set their line limits at 90 or 100 (though I have one customer that keeps 80 characters but uses two-space indents, yuck). PEP 8 is mostly about readability. However, the line length limit often seems to cause less readable code. Raymond
On Thu, Feb 21, 2019 at 12:01 PM Raymond Hettinger < raymond.hettinger@gmail.com> wrote:
In particular, the case where I most want to let people run with long lines is in forming messages to be displayed to a user.
I agree here -- and if it's messages (also comments - a twenty char comment after a 70 char line should be fine!) then it's not part of the logic of the code -- so not as bd if there is some spill off the screen for those folks that do code on tablets ;-) Actually for me, the issue s comes up when I'm showing code on a projector -- I use a huge font so folks in the back can see)
That's 103 chars long -- and very readable. But, is this that much worse? class Frabawidget: ... @wozzle.setter def (self, woozle): if not (self.min_woozle < woozle < self.max_woozle): raise ValueError(f"Expected woozle to be between" "{self.min_woozle} and {self.max_woozle}") self._wozzle = normalize(woozle) (it IS harder to write, that's for sure) In doing code reviews, I see many fewer atrocities from long lines than I
and yet the above example was 103 ... you do need a limit somewhere. I actually would really like the "limit" to depend on what the line is -- that is, it's OK to go longer if it's essentially text -- message to the user, comment, etc., rather than part of the code logic. In fact, now that I write that, I think I actually DO do that -- and even add a # noqa sometimes so my linter will stop bugging me. A smart linter would be nice here. PEP 8 is mostly about readability. However, the line length limit often
seems to cause less readable code.
So what do you suggest? simply increase the recommended line length? Or would softening the language about extending it be enough? Maybe something along the lines of: A line length limit should be well defined for each project / organization -- 80 char per line is safest for all users, but anything up to 100 is appropriate if the team maintaining the code agrees. Raymond: As a core dev -- are suggesting extending the line limit for the standard library? To all the folks quoting theory: let's be honest. Yes, really long lines are harder to read, but the 80 char limit comes from old terminals, NOT any analysis that somehow that is optimum for readability. -CHB -- Christopher Barker, Ph.D. Oceanographer Emergency Response Division NOAA/NOS/OR&R (206) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317 main reception Chris.Barker@noaa.gov
On 2/21/19 7:06 PM, Chris Barker via Python-ideas wrote:
On Thu, Feb 21, 2019 at 12:01 PM Raymond Hettinger <raymond.hettinger@gmail.com> wrote:
That's 103 chars long -- and very readable. But, is this that much worse?
I remain against longer lines. I break 80 characters extremely rarely, if ever, and at times start breaking long lines before that. I find Chris's code more readable. I'm even more against for backwards incompatibility and hard-to-read exception messages. ;-) Chris's code doesn't quite match Raymond's; Chris lost a space between (ironically) "between" and "{self.min_woozle}." Dan
On Thu, Feb 21, 2019 at 05:06:51PM -0800, Chris Barker via Python-ideas wrote:
Chris, the convention to limit text to somewhere around 60-80 characters predates old terminals by *literally centuries*. I don't think it's *us* that needs to be told to "be honest". I don't know who first came up with this story that the 79 column limit is all about compatibility with old 80 char terminals, but it's just a story. (And did they ever stop to wonder why those old terminals standardized on 80 columns?) Compatibility with old terminals is "nice to have" if you ever need to ssh into a remote machine via an 80-column machine and edit code (and I know somebody who actually does that!), but that's not the reason why we should keep the 80 column limit as the default. (Many people have already spent a lot of words explaining some of the advantages of an 80 char limit, and I don't intend to go over them again. Go back and read the thread.) I've just grabbed a handful of books at random from my bookcase, and done a quick sample of number of chars per line: 42 letters plus whitespace = 52 characters 28 letters plus whitespace = 34 x 2 columns = 68 63 plus ws = 75 56 plus ws = 67 73 plus ws = 84 59 plus ws = 70 56 plus ws = 67 (another one!) I would be surprised if you found many books that reached 95-100 characters, and shocked if you found any at all that reached 120 characters. Based on this sample, I would say the typical line length for optimal reading of prose is about 60-70 chars. Call it 65. Add four leading idents of four spaces each, and our optimum is about 81 columns. The difference between that and PEP 8's 79 columns is not significant. (I for one would not fail your code in a review merely for reaching 81 or even 82 columns.) Now, it does have to be admitted that prose does not have the same characteristics as source code. Prose tends to have solid paragraphs of the same width, and we typically read large blocks of text in full. Whereas source code tends to have lots of short lines, and a few very long lines. We typically skim most of the text, then focus in tightly to study in detail a small section of the text at a time. And any limit we choose is going to be a compromise between the need to avoid giant one-liners and the nuisance value of splitting a conceptual line of code over multiple physical lines. Being a compromise, there will always be cases where it is sub-optimal. Nevertheless, we can say this about typical Python source code: 1. 79 characters is *very generous* for most lines of code; I did a quick sample of code and found an average of 51 columns including the leading indents. This is, of course, an imperfect and biased sample because long lines have been split to keep the 79 char limit, but even a brief glance at the std lib shows that most lines of code tend to fit within 50-60 characters. 2. When a single line goes beyond 80 columns, it often wants to go a long way beyond. Perl-ish one-liners are merely a extreme case of this. 3. Such long lines are often complex, which makes them hard to read and hard to debug. Opinion: we really shouldn't be encouraging people to write long complex lines of code. If a single line has more than a dozen method calls in it, it might be a tad too complex for one physical line regardless of how wide your monitor is :-) Splitting such complex expressions over multiple lines, or even multiple statements, can have advantages beyond merely keeping to the 79 column limit. It can often result in better code that is easier to understand, debug and maintain. 4. But one notable exception to this is the case where you have a long format string, often passed to "raise Exception", or print. They're rarely complicated or hard to read: at worst, substituting a few variables into a format string. These are often indented four or five levels deep, and they really are a pain-point. They're sometimes hard to split over multiple lines. And not only are they conceptually simple, but we rarely need to read them in detail. Its the surrounding code we need to read closely. (Raymond's post singles these kinds of lines out as especially problematic, and his observations agree with my experience.) Opinion: common sense should prevail here. If you have a line "raise ValueError(...)" which would reach 80 or even 90 characters, don't let PEP 8 alone tell you otherwise. It's just a rule, not a law of physics. We have rules so that you *think before you break them*. But if you have a more substantial code that exceeds 80 columns, that's a code smell and you ought to think long and hard before breaking it. Proposal: - keep PEP 8's current recommendation; - but remind people that the rule can be relaxed for lines that are conceptually simple, such as the "raise Exception(...)" pattern; - and also remind people that long *complex* lines are an anti-pattern. Such complex lines can be improved by splitting them over multiple lines, and should be. I know we try to think in hard limits. "If 79 is too short, then 90 or 100 or 150 or ..." I'm making a plea for the opposite: if you intend to break 80 columns, consider the line itself before breaking it. Don't just increase the limit. That effectively says "any amount of complexity is OK in a single line, so long as it remains below X columns". I'd rather people look at the line and decide "this is too complex, split it" or "it's just a format string (or whatever), let it be". -- Steven
Chris, the convention to limit text to somewhere around 60-80 characters predates old terminals by *literally centuries*.
Not for code, it doesn’t— and centuries ago, there were other technical issues on play for papermaking, hand writing, and typesetting.
(And did they ever stop to wonder why those old terminals
standardized on 80 columns?)
CRTs were small and low resolution? A 200 char line would have been very expensive back in the day, and I’m pretty sure the old tractor feed paper terminal I first learned to code on was a lot more than 80 char wide. But now that you mention it, I suspect the 80 char punch cards had an influence. How many of us still type on QWERTY keyboards? Even on a phone, like I am now. The point is that we conform to s lot of conventions without re-adding whether the original reasons for those conventions apply. And no one on this thread has cited a study about optimum line length for readability of code. I have no idea if that’s ever been done — but that is the question at hand. “Typesetters hundreds of years ago used less than 80 chars per line, so that’s what we should do for Python code now” is a pretty weak argument.
Go back and read the thread.
I have read the thread. And Raymond made a pretty good argument for why, in some cases, a shorter line limit is a problem— and I have had much the same experience. and the nuisance value of splitting a conceptual
line of code over multiple physical lines.
I think one key question is whether it’s a nuisance, or actually makes some code harder to read.
1. 79 characters is *very generous* for most lines of code;
I’ve found a common exception for this is string literals and trailing comments. And I often prefer 80+ char trailing comments to an extra comment line. 2. When a single line goes beyond 80 columns, it often wants to go a
long way beyond.
Often True, but I’ve found setting my linter to 95 char makes a big difference in my code
Opinion: we really shouldn't be encouraging people to write long complex lines of code.
Agreed — but as you point out, those are often MUCH longer, so pushing the line limit to < 100 chars doesn’t really change that. 4. But one notable exception to this is the case where you have a long
format string, often passed to "raise Exception",
...
These are often indented four or five levels deep, and they really are a pain-point.
Oh yeah, that was Raymond’s point, and I concurred and emphasized it.
Yup - the trick here is that it’s hard to define clearly in a style guide, and even harder in a linter. One issue with all this is that there’s been a move toward automated enforcement (or checking) of style. Which I think is an overall good thing, but then it’s hard to allow judgement as well. But if you have a more substantial code that exceeds 80 columns, that's
a code smell and you ought to think long and hard before breaking it.
My reading of your points above is that the really smelly code is well over 80 chars, so having a slightly larger limit would work fine as well. Proposal:
- keep PEP 8's current recommendation;
As long as that includes the “ you can raise it to up to 100 char, sure :-)
- but remind people that the rule can be relaxed for lines that are conceptually simple, such as the "raise Exception(...)" pattern;
It would be nice, if possible, to clearly define this relaxation. - and also remind people that long *complex* lines are an anti-pattern.
Such complex lines can be improved by splitting them over multiple lines, and should be.
Not sure that’s needed, but why not?
Agreed — you can have too much complexity in 80 char. Which is why I think the 80 char limit is about what fits on a screen, not complexity. -CHB -- Christopher Barker, PhD Python Language Consulting - Teaching - Scientific Software Development - Desktop GUI and Web Development - wxPython, numpy, scipy, Cython
Christopher Barker wrote:
(And did they ever stop to wonder why those old terminals standardized on 80 columns?)
Probably because IBM decided on 80 columns for their punched cards. And that probably didn't have anything to do with a readable width for text. Nobody used computers for word processing back then. In fact punched cards predate computers altogether, originally being developed for electromechanical accounting and record keeping machines.
Line printers were traditionally 120 chars wide, but again that had nothing to do with text. It was so that accountants could print reports with a ridiculously large number of columns of figures.
How many of us still type on QWERTY keyboards? Even on a phone, like I am now.
Once you're used to qwerty, anything else is a nuisance, even if you're not touch typing on it. A place I park at recently installed machines you enter your car's license number into. The keyboard has the letters in alphabetical order, presumably because someone thought it would be "easier". But nowadays I suspect it just makes it harder for most people!
“Typesetters hundreds of years ago used less than 80 chars per line, so that’s what we should do for Python code now” is a pretty weak argument.
But that's not the entire argument -- the point it is that typesetters had the goal of making lines of text readable, which is similar (if not quite the same) as the goal of making lines of program code readable. It's a lot closer than, for example, the goal of fitting in an accountant's spreadsheet.
Agreed — you can have too much complexity in 80 char. Which is why I think the 80 char limit is about what fits on a screen, not complexity.
I would say it the other way around. Once you've reduced the complexity of a line to something a human can handle, *most* of the time 80 chars is enough. There will be exceptions, but as long as the exceptions are rare, making your editing window any wider will mostly just waste screen space. -- Greg
On Fri, Feb 22, 2019 at 5:10 PM Greg Ewing <greg.ewing@canterbury.ac.nz> wrote:
+1 It has been known for a very long time. These are *old *books that talk about *refactoring* (the word wasn't used then) of complex code (assigning subexpressions to variables, or extracting code into functions, reverting conditionals, etc.), not for line length, but for understandability, yet resulting nevertheless in much shorter lines: - Software Tools (also Software Tools in Pascal), Kernighan and Plauger, 1976 https://smile.amazon.com/Software-Tools-Brian-W-Kernighan/dp/020103669X - Code Complete (also the second edition), Steve Mc Connell, 1993, https://smile.amazon.com/Software-Tools-Brian-W-Kernighan/dp/020103669X I do make an exception in that after taking 8 spaces of indentation to write the implementation of a method in Python, the sweet spot is more around 100 chars. -- Juancarlo *Añez*
Hi, Le 22/02/2019 à 22:10, Greg Ewing a écrit :
I totally agree with Greg Ewing on that point. The only time when line length is a hinder by itself to me is when I can't split the windows side by side and fit both the lines of the code and it's unit-tests. And this case never happen alone as the "I can't describe easily what this line of code does" is a way bigger problem than the line length. Alexandre Dubois --- L'absence de virus dans ce courrier électronique a été vérifiée par le logiciel antivirus Avast. https://www.avast.com/antivirus
Textile looms, actually. Neither here nor there about the length of lines in PEP8 but an interesting factoid none the less. IBM (and possibly others) took punch cards from looms. On the subject of the 79 character line limit, its come up a lot in the past. * PEP-8 is the guidelines for the standard library that python-dev doesn't even strictly enforce. While it makes a decent starting point for your own project guidelines, change anything you want. * 79 characters is a reasonable ball-park figure for how long a line should be for most people * Going much above 79 characters is an indication of code smell * No matter what number you come up with, someone is going to be upset. There is no way to win in changing the guideline. PEP-8 is not a universal truth, or even a standard, we really shouldn't be treating it like it is.
Alex Walters writes:
There is no way to win in changing the guideline.
IMO this is true, despite the comment below:
PEP-8 is not a universal truth, or even a standard, we really shouldn't be treating it like it is.
Unfortunately, it's not us (at least, I don't think it is), and it's not our choice. Despite repeated warnings on the lists and even in the PEP that this is specific to the Python standard library, there are a lot of projects that choose to use the pep8 and flake8 utilities to more or less enforce PEP 8 as a standard. I believe the OP was in that situation, and it usually comes up when we have these discussions. They want us to take leadership in enforcing their standard on the rest of the world. But I don't see what's in it for us, given how divided we are on the issue. -- Associate Professor Division of Policy and Planning Science http://turnbull.sk.tsukuba.ac.jp/ Faculty of Systems and Information Email: turnbull@sk.tsukuba.ac.jp University of Tsukuba Tel: 029-853-5175 Tennodai 1-1-1, Tsukuba 305-8573 JAPAN
On Feb 22, 2019, at 1:10 PM, Greg Ewing <greg.ewing@canterbury.ac.nz> wrote:
The issue with reference to typesetter rules is that they were targeted at blocks of prose rather than heavily nested hanging indents with non-trivial string literals or a dotted attribute notation. Typesetters were also dealing with fixed page widths and need to leave gutter space for binding. The "rules" aren't comparable at all.
That would make sense if we started at column 0; however, if you have your prefix your thoughts with something like ''' class TestRemote(unittest.TestCase): def test_heartbeat(self): ... self.assertIsInstance(... ''' then the meant of the part "a human can handle" starts at column 30. Then if you need good variable names and/or have to module.function prefixes, there is sometimes little to left to work with. Raymond
As a human, and one who reads and writes code even, I know that MY ability to understands the meaning of a line of code starts to plummet when it reaches about 65-70 characters in length. Yes, of course there are some "it depends" caveats that make some lines easier and some harder. But an 80 characters "limit" is an excellent rule of thumb, as long as most coders usually "err" on the short side. My brain is a lot like those of people whom typesetters have typeset for for hundred of years, and whom scribes have written for for thousands. It's easy to be sophistical and discover that code is so very much different that roles of intelligibility don't apply. It's not though, and they do still. Or maybe everyone else in the thread is simply smarter and better able to handle complexity than I am. More power to you, but that definitely doesn't feel like "computer programming for everyone." If you want to write 100 or 120 characters lines, Python won't complain, but you've walled off your code from me as a potential reader of it. On Mon, Feb 25, 2019, 12:25 AM Raymond Hettinger < raymond.hettinger@gmail.com> wrote:
On 2/21/19 10:33 PM, Steven D'Aprano wrote:
(And did they ever stop to wonder why those old terminals standardized on 80 columns?)
Punch cards? https://softwareengineering.stackexchange.com/questions/148677 There's an ensuing discussion regarding the history of the size/shape of the punch card, too. Dan
Raymond Hettinger posted a helpful example to this list. Here, I run his example, and a variant, through https://black.now.sh Raymond class Frabawidget: @wozzle.setter def wibble(self, woozle): if not (self.min_woozle < woozle < self.max_woozle): raise ValueError(f"Expected woozle to be between {self.min_woozle} and {self.max_woozle}") self._wozzle = normalize(woozle) black.py class Frabawidget: @wozzle.setter def wibble(self, woozle): if not (self.min_woozle < woozle < self.max_woozle): raise ValueError( f"Expected woozle to be between {self.min_woozle} and {self.max_woozle}" ) self._wozzle = normalize(woozle) Raymond variant class Frabawidget: @wozzle.setter def wibble(self, woozle): if not (self.min_woozle < woozle < self.max_woozle < self.super_max_value) and do_this_or_that_(): raise ValueError(f"Expected woozle to be between {self.min_woozle} and {self.max_woozle}") self._wozzle = normalize(woozle) black.py class Frabawidget: @wozzle.setter def wibble(self, woozle): if ( not ( self.min_woozle < woozle < self.max_woozle < self.super_max_value ) and do_this_or_that_() ): raise ValueError( f"Expected woozle to be between {self.min_woozle} and {self.max_woozle}" ) self._wozzle = normalize(woozle) (By the way, I had to add the 'wibble' to the code above, to avoid a syntax error.) -- Jonathan
Yes, it's worse. You introduced twos bugs. First the space between the two fragments was lost. Second the f on the second f-string was dropped. I see these kinds of line-wrapping errors frequently. The bugs are CAUSED by the line length rule. Also, in the case of multi-line templates, there is no way to wrap them without getting very far from WYSIWYG: def run_diagnostics(location, system, test_engineer): ... if (failures): print(dedent(f'''\ There were {num_failures) anomalies detected in the {location} {system} at {event_time ::%I:%M:%S}}. These anomalies were classified as {level}. Further action is {'' if escalate else 'not'} recommended. ''') else: print(dedent(f'''\ A total of {num_test_cases} diagnostics were run in the {location} {system} as of {event_time::%I:%M:%S}}. No anomalies were detected and further action is not required. Test signed by {test_engineer.title()}. ... Raymond
On Thu, 21 Feb 2019 11:59:56 -0800 Raymond Hettinger <raymond.hettinger@gmail.com> wrote:
PEP 8 is mostly about readability. However, the line length limit often seems to cause less readable code.
There are well-known typography rules around line length and readability, both on screen and in print. See e.g.: https://baymard.com/blog/line-length-readability It's not straight-forward how to apply these for code, because it is typically indented, with varying levels of indentation (should the indentation count towards character line length when making up a rule of thumb for readability?). However, there is a commonly held idea - with centuries of experience backing it - that overly long lines makes text or code less readable (look at your typical newspaper or magazine: it splits pages of text into a number of columns so as to limit line width). And "overly long" starts rather early, around 50-80 characters for non-indented text according to most typographers. For code, a 80 character limit is common, as are other limits such as 90 and 100. In any case, each project can customize their pep8 / flake8 settings easily. PEP 8 doesn't aim to be an inflexible standard (we don't even apply it mechanically in the stdlib). Regards Antoine.
saw that today 80 Characters per Line Is a Standard Worth Sticking to Even Today https://dev.to/nickjj/80-characters-per-line-is-a-standard-worth-sticking-to... Abdur-Rahmaan Janhangeer http://www.pythonmembers.club | https://github.com/Abdur-rahmaanJ Mauritius On Tue, 19 Feb 2019, 08:38 Simon, <simon.bordeyne@gmail.com> wrote:
Same arguments made in this thread. I noticed that most of the comments were from folks disagreeing:-) Anyway, the only point to have UNH this discussion on this list is to suggest changes to PEP8. And clearly there is no consensus to increase the line length in the Style guide. So I would like to propose the softening of the language a bit as I proposed earlier in this thread, and other than that call it done. Here’s what I wrote: We could reword: """ Some teams strongly prefer a longer line length. For code maintained exclusively or primarily by a team that can reach agreement on this issue, it is okay to increase the nominal line length from 80 to 100 characters (effectively increasing the maximum length to 99 characters), provided that comments and docstrings are still wrapped at 72 characters. """ To be a bit less harsh -- that is, change the clause: "For code maintained exclusively or primarily by a team that can reach agreement on this issue, it is okay ..." To maybe just "For code maintained by a team that can reach agreement on this issue, it is okay ..." -CHB -- Christopher Barker, PhD Python Language Consulting - Teaching - Scientific Software Development - Desktop GUI and Web Development - wxPython, numpy, scipy, Cython
i thought it interesting as it presented a non py's view of things (web dev) for the 80 chars length. Abdur-Rahmaan Janhangeer http://www.pythonmembers.club | https://github.com/Abdur-rahmaanJ Mauritius
On 26/02/2019 02:01, Christopher Barker wrote:
I would prefer not. The wording as given emphasizes that the team isn't expecting outsiders to work on their code. I think that's quite important, especially when you consider that PEP8 only really has force for the standard library. -- Rhodri James *-* Kynesim Ltd
On Wed, Feb 27, 2019 at 5:53 AM Rhodri James <rhodri@kynesim.co.uk> wrote:
Huh? in the case of the stdlib, the "team" is the python core devs -- they could decide to increase the line length if they want (though I imagine if they did, they's probably change the PEP :- ) Anyway, not a biggie -- just might get folks to chill out a bit and stop pushing to change the PEP ... -CHB -- Christopher Barker, Ph.D. Oceanographer Emergency Response Division NOAA/NOS/OR&R (206) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317 main reception Chris.Barker@noaa.gov
participants (36)
-
Abdur-Rahmaan Janhangeer -
Abe Dillon -
Alex Walters -
Alexandre Dubois -
Anders Hovmöller -
Antoine Pitrou -
Brendan Barnwell -
Cameron Simpson -
Chris Angelico -
Chris Barker -
Christopher Barker -
Dan Sommers -
David Mertz -
Greg Ewing -
James Lu -
Jonathan Fine -
Joni Orponen -
Juancarlo Añez -
Lele Gaifax -
M.-A. Lemburg -
Mike Miller -
Mike Müller -
Nicolas Rolin -
Paul Ferrell -
Paul Moore -
pylang -
Raymond Hettinger -
Rhodri James -
Samuel Colvin -
Simon -
simon.bordeyne
-
Stephen J. Turnbull -
Steve Barnes -
Steven D'Aprano -
Stéfane Fermigier -
Terry Reedy