PEP 8 Modernisation(hg.python.org)
hg.python.org
PEP 8 Modernisation
http://hg.python.org/peps/rev/fb24c80e9afb
10 comments
Code is meant to be consumed by machines
I hope you're joking...
I hope you're joking...
Poor word choice on my part. The intention was that machines don't need to jump through any hoops to be able to figure out what code means - it's a language designed such that it can be parsed mechanically without ambiguity. Compare this to a machine interpreting English.
I was not intending to downplay the significance of code being intended for human consumption.
I was not intending to downplay the significance of code being intended for human consumption.
But how many characters are in a typical line of English?
Traditionally,
Anything from 45 to 75 characters is widely-regarded as a satisfactory
length of line for a single-column page set in a serifed text face in
a text size. The 66-character line (counting both letters and spaces)
is widely regarded as ideal.
It depends on your typography.
That is in stark contrast to SICP: "programs must be written for people to read, and only incidentally for machines to execute"
Whom should I listen to... Hmmm, tough choice...
I mean, I've just seen Gerry Sussman in a recent video saying he doesn't know how to compute, so you must be a winner.
Whom should I listen to... Hmmm, tough choice...
I mean, I've just seen Gerry Sussman in a recent video saying he doesn't know how to compute, so you must be a winner.
I'm sorry, but I disagree. As it stands, it is currently more important to display code as it appears in the file. One day, everyone may have their style for all languages and every tool supports it etc. That's not today.
I agree. I'm saying this is a bug. The fact that we need to care about this is a bug.
If I'm working with code on my phone, I'm going to have different preferences than on my tablet, or my laptop, or doing side-by-side comparisons, or my 30" display, or a projector.
Probably the best current examples of what can be done with this are docco and it's friends. iPython notebook is another example of what we can do when we decide that hardware improvements in the past couple decades may be taken advantage of to improve production and consumption of code, rather than declaring that no progress shall be made after 1976.
If I'm working with code on my phone, I'm going to have different preferences than on my tablet, or my laptop, or doing side-by-side comparisons, or my 30" display, or a projector.
Probably the best current examples of what can be done with this are docco and it's friends. iPython notebook is another example of what we can do when we decide that hardware improvements in the past couple decades may be taken advantage of to improve production and consumption of code, rather than declaring that no progress shall be made after 1976.
The hardware may have improved, but the meatware has not. We don't use narrow, fixed-width columns because of technical limitations, but because they are easier for human beings to read.
Alrighty. Where will you be implementing it first?
And how will you get every editor available on board?
Does it matter?
Progress sometimes requiring taking a couple steps backward if we've reached a local maximum. An unwillingness to compromise backward compatibility - a perennial commitment towards designing for the lowest common denominator - limits the progress that can be made.
Progress sometimes requiring taking a couple steps backward if we've reached a local maximum. An unwillingness to compromise backward compatibility - a perennial commitment towards designing for the lowest common denominator - limits the progress that can be made.
> An unwillingness to compromise backward compatibility
Are you referring to the unwillingness to bump up the maximum line length? I don't think it's because of backward compatibility. I limit just about every line of code I write in any language to 80 columns, and my horizontal screen real estate is 5760 pixels.
Are you referring to the unwillingness to bump up the maximum line length? I don't think it's because of backward compatibility. I limit just about every line of code I write in any language to 80 columns, and my horizontal screen real estate is 5760 pixels.
Find me an alternative to side-by-side diff tools (such as meld) that work poorer with longer lines, and then we can talk.
Code is simply easier to read by humans when it isn't stretched out obtusely in one direction. We should be making code easier to be read by humans. Machines don't matter.
Code is simply easier to read by humans when it isn't stretched out obtusely in one direction. We should be making code easier to be read by humans. Machines don't matter.
[deleted]
Completely agreed.
Newer versions of emacs do nice code wrapping (dynamically, to the width of the buffer, without modifying the buffer text). Xcode does nice code wrapping. I've stopped manually wrapping my code, and it's great.
Newer versions of emacs do nice code wrapping (dynamically, to the width of the buffer, without modifying the buffer text). Xcode does nice code wrapping. I've stopped manually wrapping my code, and it's great.
What do you do when you view a diff, and what you see there doesn't match your editor?
Edit: I know emacs can probably view diffs. That's not the point, unless you expect every window to be the same width, and every tool to wrap everything exactly the same.
Edit: I know emacs can probably view diffs. That's not the point, unless you expect every window to be the same width, and every tool to wrap everything exactly the same.
We should fix the diff tools too while we are at it. Why are we diffing by lines and not doing a semantic diff of the code? If the compiler doesn't care about it, why should the diff?
You essentially want to replace Unix pipelines with an API then. Nobody else has managed to do this successfully, completely replacing text.
Isn’t this the heart of the problem, though?
Raw text is a limited medium, and working at the level of plain text analysis rather than semantic analysis does limit how much our tools can achieve. The UNIX philosophy of having many small, text-based tools and chaining them together represents a common platform, but it’s also a least common denominator platform.
As long as we allow that glass ceiling to remain, the best our tools will ever do is push it incrementally higher, one tiny step at a time. If we want to make big leaps, we’re going to have to sacrifice some of that generality so we can use more powerful but specific tools. Unfortunately, that means that any new programming language wanting to take on the established standards needs not only a compiler/interpreter, but also the rest of the ecosystem: a comprehensive tool chain, ample library coverage, documentation and training resources, and so on. It is also, almost inevitably, going to need some standardised way of bridging the gap to today’s established languages for interoperability and backward compatibility purposes.
This is why I think the view that programming languages should be designed optimally for humans is short-sighted, and I suspect most of the big success stories in the coming years will be languages that were designed with clean semantics and easy parsing in mind. Those languages will better support building that surrounding ecosystem, and a good language with a good ecosystem is more practically useful than a slightly better language with a limited ecosystem.
Raw text is a limited medium, and working at the level of plain text analysis rather than semantic analysis does limit how much our tools can achieve. The UNIX philosophy of having many small, text-based tools and chaining them together represents a common platform, but it’s also a least common denominator platform.
As long as we allow that glass ceiling to remain, the best our tools will ever do is push it incrementally higher, one tiny step at a time. If we want to make big leaps, we’re going to have to sacrifice some of that generality so we can use more powerful but specific tools. Unfortunately, that means that any new programming language wanting to take on the established standards needs not only a compiler/interpreter, but also the rest of the ecosystem: a comprehensive tool chain, ample library coverage, documentation and training resources, and so on. It is also, almost inevitably, going to need some standardised way of bridging the gap to today’s established languages for interoperability and backward compatibility purposes.
This is why I think the view that programming languages should be designed optimally for humans is short-sighted, and I suspect most of the big success stories in the coming years will be languages that were designed with clean semantics and easy parsing in mind. Those languages will better support building that surrounding ecosystem, and a good language with a good ecosystem is more practically useful than a slightly better language with a limited ecosystem.
> working at the level of plain text analysis rather than semantic analysis does limit how much our tools can achieve.
We can add semantic analysis. I have no problem with that. But removing or harming the ability to do text analysis might not stop us from using more sophisticated tools, but it does stop us from putting tools together quickly in a way not previously predicted. This is why Unix is so powerful. If you haven't read The Art of Unix Programming, I urge you to do so. It puts the argument and examples forward far more convincingly than I can.
Would moving to semantic tools harm the ability to use our existing text-based tools? I'd say so. A simple tool like diff works better, for example, if you take your big list of Python imports and put each one on a separate line, and keep them sorted. Patching works smoother this way too, reducing the likelyhood of the need for manual conflict resolution. If we eliminate doing this kind of arrangement by hand, and instead start relying on a semantic editor, we'll lose this ability. I have yet to see a tool that does semantic diffs, patches and merges better than diff, patch and git do.
We can add semantic analysis. I have no problem with that. But removing or harming the ability to do text analysis might not stop us from using more sophisticated tools, but it does stop us from putting tools together quickly in a way not previously predicted. This is why Unix is so powerful. If you haven't read The Art of Unix Programming, I urge you to do so. It puts the argument and examples forward far more convincingly than I can.
Would moving to semantic tools harm the ability to use our existing text-based tools? I'd say so. A simple tool like diff works better, for example, if you take your big list of Python imports and put each one on a separate line, and keep them sorted. Patching works smoother this way too, reducing the likelyhood of the need for manual conflict resolution. If we eliminate doing this kind of arrangement by hand, and instead start relying on a semantic editor, we'll lose this ability. I have yet to see a tool that does semantic diffs, patches and merges better than diff, patch and git do.
But removing or harming the ability to do text analysis [...] does stop us from putting tools together quickly in a way not previously predicted.
Well, OK, but we’ve been using these text-based tools for a year or two now, and I don’t see many radical advances taking place in how we use or combine them. Are you sure you’re not chasing an illusion here?
The freeform text-based tools represent a great deal of flexibility, to be sure, but they were conceived at a time when flexible text manipulation was about as much as one could hope for. Today, we can do more.
I have yet to see a tool that does semantic diffs, patches and merges better than diff, patch and git do.
As long as everything is limited to manipulation of freeform text files, perhaps you never will. That doesn’t mean better tools aren’t possible; it just means they aren’t possible within the constraints you’re choosing to impose.
Well, OK, but we’ve been using these text-based tools for a year or two now, and I don’t see many radical advances taking place in how we use or combine them. Are you sure you’re not chasing an illusion here?
The freeform text-based tools represent a great deal of flexibility, to be sure, but they were conceived at a time when flexible text manipulation was about as much as one could hope for. Today, we can do more.
I have yet to see a tool that does semantic diffs, patches and merges better than diff, patch and git do.
As long as everything is limited to manipulation of freeform text files, perhaps you never will. That doesn’t mean better tools aren’t possible; it just means they aren’t possible within the constraints you’re choosing to impose.
> Well, OK, but we’ve been using these text-based tools for a year or two now, and I don’t see many radical advances taking place in how we use or combine them. Are you sure you’re not chasing an illusion here?
I'm not claiming recent advances. I'm claiming existing power that has been around for decades, which we would lose if we compromised the text tooling available today.
Have you read TAOUP? Do you understand the extent of the power that existing text tooling gives us today? Are you experienced in the advanced use of the existing tools, so you are able to make comparisons about their power?
> As long as everything is limited to manipulation of freeform text files, perhaps you never will. That doesn’t mean better tools aren’t possible; it just means they aren’t possible within the constraints you’re choosing to impose.
This is backwards. We move forward when people show how it can be done. Please show us how we can improve diffs, patches and merges by moving to semantic data structures over text, without compromising any existing capabilities. Even just illustrating specifics of how these tools might work, rather than implementing them, will do something for your argument. The onus is on you.
I'm not claiming recent advances. I'm claiming existing power that has been around for decades, which we would lose if we compromised the text tooling available today.
Have you read TAOUP? Do you understand the extent of the power that existing text tooling gives us today? Are you experienced in the advanced use of the existing tools, so you are able to make comparisons about their power?
> As long as everything is limited to manipulation of freeform text files, perhaps you never will. That doesn’t mean better tools aren’t possible; it just means they aren’t possible within the constraints you’re choosing to impose.
This is backwards. We move forward when people show how it can be done. Please show us how we can improve diffs, patches and merges by moving to semantic data structures over text, without compromising any existing capabilities. Even just illustrating specifics of how these tools might work, rather than implementing them, will do something for your argument. The onus is on you.
I'm claiming existing power that has been around for decades, which we would lose if we compromised the text tooling available today.
Why would we lose it? The power of those tools isn’t in a particular executable, it’s in the algorithms they embody. For example, it is useful to compare two text streams reasonably efficiently and identify differences. How those differences are then presented obviously matters, but if you’ve got the algorithms and the ideas underlying them, producing a new tool to apply those ideas in a different context is the easy part.
The only significant difference I see is that if you made a major change, for example adopting a more structured storage model or using some sort of action/history analysis to better capture a programmer’s intent, then you would have more data to use in your algorithms, and you might therefore be able to present more interesting results.
Have you read TAOUP? Do you understand the extent of the power that existing text tooling gives us today? Are you experienced in the advanced use of the existing tools, so you are able to make comparisons about their power?
Yes, though I find your emphasis on that one book a little surprising. For one thing, the UNIX philosophy was established for decades before Raymond wrote that particular work. For another, I seem to recall that he gives examples of both text and binary formats being useful in the book. I don’t think his point was that text formats were good and non-text ones bad; I think he was arguing that things like adaptability and composability were good and that flexible and standardised formats helped to achieve those things.
We move forward when people show how it can be done.
Right, so why aren’t the programming language community picking up on decades of research and industrial progress with databases and HCI? Programming languages and the related tools are, fundamentally, just a user interface to design and control a complex, highly structured set of data.
Please show us how we can improve diffs, patches and merges by moving to semantic data structures over text, without compromising any existing capabilities.
You’re begging the question, by starting from the position that having an equivalent to today’s text-based diffs, patches and merge tools is desirable. I don’t think that is necessarily true.
As a programmer, I want to be able to specify how my software should work, and I want to be able to explore and modify that specification effectively, and I need to be able to do these things in collaboration with others. My claim is that to do those things much better than we do them today, we may need to move to a different representation than freeform text and then build new tools that are designed to solve our problems in terms of that new representation.
The problem is that there is so much momentum behind text-based formats today that we are effectively stuck around a local maximum. No one individual could possibly meet your challenge today, and I’m sure you were well aware of that when you made it. That doesn’t mean the community as a whole couldn’t do it, but it would need some serious collaboration, which realistically means one of the heavyweight organisations with the resources to bootstrap a whole new software development ecosystem would need to throw its weight behind such a project. Unfortunately, most if not all such organisations are commercial in nature, and the commercial incentives don’t align with moving in that direction.
Why would we lose it? The power of those tools isn’t in a particular executable, it’s in the algorithms they embody. For example, it is useful to compare two text streams reasonably efficiently and identify differences. How those differences are then presented obviously matters, but if you’ve got the algorithms and the ideas underlying them, producing a new tool to apply those ideas in a different context is the easy part.
The only significant difference I see is that if you made a major change, for example adopting a more structured storage model or using some sort of action/history analysis to better capture a programmer’s intent, then you would have more data to use in your algorithms, and you might therefore be able to present more interesting results.
Have you read TAOUP? Do you understand the extent of the power that existing text tooling gives us today? Are you experienced in the advanced use of the existing tools, so you are able to make comparisons about their power?
Yes, though I find your emphasis on that one book a little surprising. For one thing, the UNIX philosophy was established for decades before Raymond wrote that particular work. For another, I seem to recall that he gives examples of both text and binary formats being useful in the book. I don’t think his point was that text formats were good and non-text ones bad; I think he was arguing that things like adaptability and composability were good and that flexible and standardised formats helped to achieve those things.
We move forward when people show how it can be done.
Right, so why aren’t the programming language community picking up on decades of research and industrial progress with databases and HCI? Programming languages and the related tools are, fundamentally, just a user interface to design and control a complex, highly structured set of data.
Please show us how we can improve diffs, patches and merges by moving to semantic data structures over text, without compromising any existing capabilities.
You’re begging the question, by starting from the position that having an equivalent to today’s text-based diffs, patches and merge tools is desirable. I don’t think that is necessarily true.
As a programmer, I want to be able to specify how my software should work, and I want to be able to explore and modify that specification effectively, and I need to be able to do these things in collaboration with others. My claim is that to do those things much better than we do them today, we may need to move to a different representation than freeform text and then build new tools that are designed to solve our problems in terms of that new representation.
The problem is that there is so much momentum behind text-based formats today that we are effectively stuck around a local maximum. No one individual could possibly meet your challenge today, and I’m sure you were well aware of that when you made it. That doesn’t mean the community as a whole couldn’t do it, but it would need some serious collaboration, which realistically means one of the heavyweight organisations with the resources to bootstrap a whole new software development ecosystem would need to throw its weight behind such a project. Unfortunately, most if not all such organisations are commercial in nature, and the commercial incentives don’t align with moving in that direction.
Scaling.
The same diff tool works for text files, latex and other markup files, for any computer language, and so on. I can write downstream tools that take the output of the diff and do further processing, without worrying about what the output might look like for brainfuck. And how long would we have to wait for Torvalds to add a C++ or Java extension to git? :)
The same diff tool works for text files, latex and other markup files, for any computer language, and so on. I can write downstream tools that take the output of the diff and do further processing, without worrying about what the output might look like for brainfuck. And how long would we have to wait for Torvalds to add a C++ or Java extension to git? :)
Not all languages are compiled - sometimes line breaks are meaningful, and it would be good if diff tools work across all languages.
Good question. When I do a diff from within emacs, using ediff, it "just works" -- diffs are shown side-by-side w/ the same wrapping applied. (Ediff is also good at showing you what changed within the line.)
If I'm diffing in an external tool (like gitx, or just on the command line), then I just see (possibly) long lines. So far, it hasn't been an issue for me. Obviously, diff, as a line-oriented protocol, breaks down as lines get really long -- but it's still just code, so it's not like my lines are ever insanely-long. :)
I also use a mode that highlights my current (physical) line in the file, so I still tend to have a very good sense of what the physical line in the file is, despite the wrapped visual display. E.g., http://imgur.com/a/wAXHJ
One of the oft-touted benefits of wrapping lines at (say) 80 chars is it makes it easy to do side-by-side viewing of files -- using dynamic wrapping gives you this same benefit, but even more so, since you can heads-up different files at whatever width your current display happens to have. (Or however many files you want to have side-by-side.)
Also, there's a nice side-benefit to diffs, which is you don't get the noise that comes from a change that forces a manual rewrapping -- e.g., maybe I decide my variable "id" was too generic, so I change it to "frobnackId", but then this pushes some function call over the 80-character limit. If I'm manually rewrapping, I get a weird diff of multiple lines changing over the rewrap.
(On the other hand, a definite down-side is if you do find yourself using an editor that can't wrap nicely, code with long lines can be quite annoying.)
If I'm diffing in an external tool (like gitx, or just on the command line), then I just see (possibly) long lines. So far, it hasn't been an issue for me. Obviously, diff, as a line-oriented protocol, breaks down as lines get really long -- but it's still just code, so it's not like my lines are ever insanely-long. :)
I also use a mode that highlights my current (physical) line in the file, so I still tend to have a very good sense of what the physical line in the file is, despite the wrapped visual display. E.g., http://imgur.com/a/wAXHJ
One of the oft-touted benefits of wrapping lines at (say) 80 chars is it makes it easy to do side-by-side viewing of files -- using dynamic wrapping gives you this same benefit, but even more so, since you can heads-up different files at whatever width your current display happens to have. (Or however many files you want to have side-by-side.)
Also, there's a nice side-benefit to diffs, which is you don't get the noise that comes from a change that forces a manual rewrapping -- e.g., maybe I decide my variable "id" was too generic, so I change it to "frobnackId", but then this pushes some function call over the 80-character limit. If I'm manually rewrapping, I get a weird diff of multiple lines changing over the rewrap.
(On the other hand, a definite down-side is if you do find yourself using an editor that can't wrap nicely, code with long lines can be quite annoying.)
Vim shows diffs with wrapped lines just fine as far as I can tell. I have it set up to show both versions side by side, with changed lines highlighted and the particular change on each line also highlighted. I can wrap one or both, depending on how wide I make either.
Can you explain what problem you think might occur? Its not clear to me what problems you anticipate.
Can you explain what problem you think might occur? Its not clear to me what problems you anticipate.
Humans are set up to see differences visually when they see patterns. If the way that lines wrap depends on the width of your window, then it becomes hard to match up the output visually from windows of different widths.
An example: I type "git diff" into one window, and look for some particular change area in my editor in a different window. If the wrap and alignments depend on the widths of my windows, then they won't match unless the widths of my windows also match. And if I have to make them match, then the original ideal of "make your window however wide you want and it'll just look right" is defeated.
An example: I type "git diff" into one window, and look for some particular change area in my editor in a different window. If the wrap and alignments depend on the widths of my windows, then they won't match unless the widths of my windows also match. And if I have to make them match, then the original ideal of "make your window however wide you want and it'll just look right" is defeated.
Can't say I experience this problem, the highlighting of relevant lines takes care of this. Human eyes are terrible at tracking across long lines of text without jumping up or down a line (this is why splitting text into columns is common in large books). On the other hand jumping between regions of color is easy.
Furthermore, I don't think this is true: "And if I have to make them match, then the original ideal of "make your window however wide you want and it'll just look right" is defeated." Being able to resize both, with the constraint that they must both be kept in sync (which to be clear, I don't consider necessary), is better than the alternative: no effective resizing at all.
You should probably look into integrating git-diff with your editor though (use git-difftool).
Furthermore, I don't think this is true: "And if I have to make them match, then the original ideal of "make your window however wide you want and it'll just look right" is defeated." Being able to resize both, with the constraint that they must both be kept in sync (which to be clear, I don't consider necessary), is better than the alternative: no effective resizing at all.
You should probably look into integrating git-diff with your editor though (use git-difftool).
>What do you do when you view a diff, and what you see there doesn't match your editor?
Mentally account for one more line or two?
Mentally account for one more line or two?
I upvoted you for this - I think it's a really interesting idea.
Why can't my editor tokenize my code and then show it in the format I want? Why do I, as the programmer, have to worry about whether one whitespace convention works for you versus me, when you could just come up with whatever scheme you like and view code that way?
Why can't my editor tokenize my code and then show it in the format I want? Why do I, as the programmer, have to worry about whether one whitespace convention works for you versus me, when you could just come up with whatever scheme you like and view code that way?
>Why can't my editor tokenize my code and then show it in the format I want?
Because editors are written by humans. And as of now, we haven't sold a whole lot of problems with their use.
For example, you get an IDE with lots of features, but a subpar editor, crammy UI and GC pauses (3 of the five most popular are written in Java).
Or you get something like VIM, with a great editor, but subpar compatibility with the rest of your system, not very good understanding of the code (refactoring, tokenizing etc). '80s GUI capabilities etc, ad-hoc collection of plugins to fix basic pain points (like file navigation).
Or you get Emacs, with millions of configurable options, a subpar extension language, script in various stages of great and rot, '80s GUI capabilities, etc.
In general, we lack tools that run the whole gamut: great editor, fluent shortcuts (either Emacs or Vim style), 2013 GUI capabilities, refactoring and intimate knowledge of program syntax (to the level of understanding the AST, no BS regex used for syntax highlighting), embedded REPLs and terminals, etc.
Something like a Lisp Machine + Smalltalk UI + Light Table + Visual Studio + Vim/Emacs combo.
Because editors are written by humans. And as of now, we haven't sold a whole lot of problems with their use.
For example, you get an IDE with lots of features, but a subpar editor, crammy UI and GC pauses (3 of the five most popular are written in Java).
Or you get something like VIM, with a great editor, but subpar compatibility with the rest of your system, not very good understanding of the code (refactoring, tokenizing etc). '80s GUI capabilities etc, ad-hoc collection of plugins to fix basic pain points (like file navigation).
Or you get Emacs, with millions of configurable options, a subpar extension language, script in various stages of great and rot, '80s GUI capabilities, etc.
In general, we lack tools that run the whole gamut: great editor, fluent shortcuts (either Emacs or Vim style), 2013 GUI capabilities, refactoring and intimate knowledge of program syntax (to the level of understanding the AST, no BS regex used for syntax highlighting), embedded REPLs and terminals, etc.
Something like a Lisp Machine + Smalltalk UI + Light Table + Visual Studio + Vim/Emacs combo.
"something like VIM, with a great editor, but subpar compatibility with the rest of your system"
Excuse me, but vim has much better compatibility/interoperability with the rest of my system than all the IDEs written in Java.
Excuse me, but vim has much better compatibility/interoperability with the rest of my system than all the IDEs written in Java.
Between ^Z, :<range>!, :grep, make, and other tools, vim has great compatibility with my system, thanks :)
Do it have an in-editor terminal?
An in-editor debugger?
Does it offer a REPL?
Does it work with your build system and your SCM system without some ho-hum third party plugins?
An in-editor debugger?
Does it offer a REPL?
Does it work with your build system and your SCM system without some ho-hum third party plugins?
In-editor terminal? ^Z or :shell (Asking for an in-editor terminal makes about as much sense as my whinging that Eclipse doesn't have an in-terminal editor)
In-editor debugger? I admit this is less than ideal.
A REPL? Languages suited to REPLs have REPLs, and a lot of them support SLIME, allowing me to interact with the REPL from vim. For everything else there's tmux.
Build system? :make and errorformat
SCM integration? ^Z. Or fugitive I guess. (a third party plugin, yes. But if you think it's ho-hum, you probably haven't used it).
In-editor debugger? I admit this is less than ideal.
A REPL? Languages suited to REPLs have REPLs, and a lot of them support SLIME, allowing me to interact with the REPL from vim. For everything else there's tmux.
Build system? :make and errorformat
SCM integration? ^Z. Or fugitive I guess. (a third party plugin, yes. But if you think it's ho-hum, you probably haven't used it).
Visual Studio with a VIM emulator plugin is pretty nice...
Well, there's stuff like word wrap and GNU indent and a host of pretty-printers, but I think you're looking for something more resource-intensive and integrated.
The question then becomes, why configure a transformer when you can just format it right the first time?
The question then becomes, why configure a transformer when you can just format it right the first time?
Because, aside from Python and its One True Way to format, different people have different ideas of what "formatting it right" means.
Funny, someone was just talking about 79 characters per line in regards to using soft tabs for editor display consistency, the other day.
http://www.reddit.com/r/java/comments/1j7iv4/would_it_not_be...
These are useful for static code analysis and finding congruence with typesetting conventions:
https://pypi.python.org/pypi/flake8
https://pypi.python.org/pypi/condent
https://pypi.python.org/pypi/pep8ify
http://www.reddit.com/r/java/comments/1j7iv4/would_it_not_be...
These are useful for static code analysis and finding congruence with typesetting conventions:
https://pypi.python.org/pypi/flake8
https://pypi.python.org/pypi/condent
https://pypi.python.org/pypi/pep8ify
"Code is meant to be consumed by machines"
Well, partly. Code is actually a piece of writing intended for two very different audiences - one human, one machine. The machine doesn't actually care how long your lines are - this is an optimization for humans.
And I hear you about fixing the tools. Wouldn't it be easy if everyone used the same editor. But alas, this isn't a problem with the tools. It's an inherent limitation of text. That "figuring out visual structure" bit only works if your editor deeply understands your language. And different editors understand languages to different degrees and in different ways.
They say parsing is a solved problem, but I dare you to parse Ruby or Python correctly.
Well, partly. Code is actually a piece of writing intended for two very different audiences - one human, one machine. The machine doesn't actually care how long your lines are - this is an optimization for humans.
And I hear you about fixing the tools. Wouldn't it be easy if everyone used the same editor. But alas, this isn't a problem with the tools. It's an inherent limitation of text. That "figuring out visual structure" bit only works if your editor deeply understands your language. And different editors understand languages to different degrees and in different ways.
They say parsing is a solved problem, but I dare you to parse Ruby or Python correctly.
While Ruby and Perl cannot be parsed, Python can be parsed correctly.
Uh, ruby can be parsed, it's just hard. It's waaaay saner than perl.
If you emulate the way the MRI parses it, sure.
For example:
For example:
# Is this some_method with an empty block, or an empty hash?
some_method {}
# Is this a regex or a comment?
#
# It depends how many arguments "whatever" takes, and you
# don't know that until you run the code that defines it.
#
# Interpretation is implementation-defined. It just so
# happens that the MRI determines that the below ISN'T a
# regex because it has a SPACE character just after the "/".
whatever / 25 ; # / ; raise SystemExit.new;I don't understand what you mean by parsing if not what the interpreter does. Can you give an example?
Perl (and I assume Ruby from the comment) requires the running context of the interpreter to make decisions about how to interpret some code constructs. Because you need the running state, it is not parseable.
Parsing as in determining what constructs different lines represent, without running them. Imagine e.g. a documentation generator that needs to figure out what all your methods and parameters are, but not actually execute them (obviously there are many other use cases).
A friend at an old job had a piece of perl code where one of the lines would be a comment or not when you ran it, depending on user input. He would bring it out whenever someone suggested writing something in perl.
A friend at an old job had a piece of perl code where one of the lines would be a comment or not when you ran it, depending on user input. He would bring it out whenever someone suggested writing something in perl.
Technically correct. Practically there is a tiny subset of Perl that the parser cannot decide correctly, which is used by virtually nobody. Almost all of the code on CPAN can be parsed just fine by this module: https://metacpan.org/module/PPI
No, thanks. Reasonably short lines means I can get a good idea of what's going on by skimming in one direction: downwards. If there are lines that run off towards the eastern horizon, even if they fit on my screen, I still have to follow along them to make sure nothing of interest is being hidden.
Plus, just getting the code to do the thing I want is enough work; let's not also start worrying about how to write code in such a way that most tools will understand how to wrap it. That sounds like bringing all the joys of CSS to my plain text. Because the tools are _not_ going to be perfect. Have you ever seen Perl code with punctuation in a comment at the end of a line, because some idiot syntax highlighter got confused about where a regex ended?
Plus, just getting the code to do the thing I want is enough work; let's not also start worrying about how to write code in such a way that most tools will understand how to wrap it. That sounds like bringing all the joys of CSS to my plain text. Because the tools are _not_ going to be perfect. Have you ever seen Perl code with punctuation in a comment at the end of a line, because some idiot syntax highlighter got confused about where a regex ended?
I'm disappointed to see this is still the top comment, for a few reasons.
1) Lines longer than 80 are an indicator that your code is getting too verbose, at least for Python. 2) You should be taking the time to figure out how to maximize readability of your code. And breaking the lines is damn near instantaneous when compared to the time taken to pick a good variable name or decide on overall design structure. 3) Not everyone will have the same editor. Your code should stand on its own and be readable in its own right.
1) Lines longer than 80 are an indicator that your code is getting too verbose, at least for Python. 2) You should be taking the time to figure out how to maximize readability of your code. And breaking the lines is damn near instantaneous when compared to the time taken to pick a good variable name or decide on overall design structure. 3) Not everyone will have the same editor. Your code should stand on its own and be readable in its own right.
> 1) Lines longer than 80 are an indicator that your code is getting too verbose, at least for Python.
I completely disagree, partly because I prefer to err on the side of verboseness, and partly because 80 is just ridiculously short. Look at the examples in PEP 8:
I understand that readability is subjective, but I find it extremely hard to believe that anyone honestly finds that more readable on two lines than one.
I completely disagree, partly because I prefer to err on the side of verboseness, and partly because 80 is just ridiculously short. Look at the examples in PEP 8:
def __init__(self, width, height,
color='black', emphasis=None, highlight=0):
I understand that readability is subjective, but I find it extremely hard to believe that anyone honestly finds that more readable on two lines than one.
>but I find it extremely hard to believe that anyone honestly finds that more readable on two lines than one.
FWIW, I do. Especially since the new line is a clear point of separation between required and optional arguments.
But I also find HN extremely hard to read because of the ridiculously long lines, and often find myself jumping to the wrong line when I reach end of the screen.
FWIW, I do. Especially since the new line is a clear point of separation between required and optional arguments.
But I also find HN extremely hard to read because of the ridiculously long lines, and often find myself jumping to the wrong line when I reach end of the screen.
I hadn't noticed the line break serving as the separation between required and optional arguments. That's a good point, and I now don't see an issue with that particular line break in that context. But I still think it's silly to always break at 80 character in similar examples.
Exactly. 80 columns with python is incredibly frustrating to hold to. Python is a verbose language at the best of times, when you add in 4 or even 8 column indent it's just silly. 20% of your line is probably taken up by leading spaces or one or more 'self.'s. The introduction of keyword args only compounded the issue.
I think it's worth the time to spend a little while with an IDE that PEP-8 checks your code in real-time. It really forces you to think about better formatting and breaking up complex statements. In your example, if my declaration is running that long, I put the first line break after the open-parenthesis. Then all parameters end up in a nice block, and I've found that to be very easy on the eyes when going back to look at forgotten code. Generally speaking, I've found that adhering to the 80-char limit has greatly improved my code formatting and readability. 100 is okay with me too, though.
Nice to see some movement away from the 79 character limit. I've had to make some incredibly unreadable code in the past just to comply with it.
I disagree, but only as of about 2 months ago. For awhile I stuck to 79 cols but understood if people elsewhere wanted to move to 100 or 120.
I've changed my mind because I've started doing a lot of code-reading on my phone. It's got a big screen (Galaxy S3) but even still, 80 columns is the perfect width to fit all the code on my screen without needing to scroll.
What's old is new again. We went from tiny monitors to huge monitors and now we're back to tiny "monitors" again. Anywhere where I am able to make the determination, 79 columns will be the standard.
I've changed my mind because I've started doing a lot of code-reading on my phone. It's got a big screen (Galaxy S3) but even still, 80 columns is the perfect width to fit all the code on my screen without needing to scroll.
What's old is new again. We went from tiny monitors to huge monitors and now we're back to tiny "monitors" again. Anywhere where I am able to make the determination, 79 columns will be the standard.
Just curious: why are you reading code on your phone? I've heard of doing basic web-dev stuff via mobile (using stuff like Diet Coda) but rarely anything else.
I read a lot of code. Links from Twitter to interesting projects, peeking at pull requests while I'm away from my computer, etc.
I read a lot of code.
I read a lot of code.
Guido just proposed a patch that undoes this change and restores the old 79 character limit...
http://bugs.python.org/issue18472#msg194089
--- a/pep-0008.txt
+++ b/pep-0008.txt
@@ -159,12 +159,11 @@
Maximum Line Length
-------------------
-Aim to limit all lines to a maximum of 79 characters, but up to 99
-characters is acceptable when it improves readability.
+Limit all lines to a maximum of 79 characters.
EDIT: formatting/description
http://bugs.python.org/issue18472#msg194089
--- a/pep-0008.txt
+++ b/pep-0008.txt
@@ -159,12 +159,11 @@
Maximum Line Length
-------------------
-Aim to limit all lines to a maximum of 79 characters, but up to 99
-characters is acceptable when it improves readability.
+Limit all lines to a maximum of 79 characters.
EDIT: formatting/description
The full patch also includes 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 line 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.
+
+The Python standard library is conservative and requires limiting
+lines to 79 characters (and docstrings/comments to 72).
+
Good point, didn't see that. It's interesting how clearly it differentiates between core CPython style and 3rd party style. I'm guilty of thinking of PEP8 as the definitive general style guide. But this not what it claims to be- it's just the core development style guide. So it's reasonable for it to be a bit conservative while saying, this is a hardline stand that you may want to deviate from.
I couldn't figure out if they have that dumb indentation rule.
https://gist.github.com/radiosilence/6133713
I mean how can anyone say that the former is better than the latter?
https://gist.github.com/radiosilence/6133713
I mean how can anyone say that the former is better than the latter?
What? There's no proscription against either of those. However a little common sense would go a long way in your first example. Break at spaces/hyphens/other natural break points in strings. Also the + symbols aren't necessary. String continuation is implicit inside parentheses.
I always stick to 79 chars and stick to the latter method for indentation. I am completely happy with the readability of my code as a result. Thus, I'm not really happy with the new 99 char rule.
I don't think of it as a new limit at 99 chars, meaning you should switch, but that the 79 limit isn't a hard limit, just a guideline.
If you have a line that would suffer under 79 chars, let it go a little long, but no farther than 99.
If you have a line that would suffer under 79 chars, let it go a little long, but no farther than 99.
Anyone changing their editor settings based on the new guidelines?
In vim, I'm thinking about using:
In vim, I'm thinking about using:
set colorcolumn=79
set textwidth=99Even the old PEP8 was stating:
When applying the rule would make the code less readable, even for someone who is used to reading code that follows the rules.Thing is the code will also become less readable for many people if your line is longer than 79 chars. My terminals have a fixed width so that they fit perfectly side by side on my multiple monitors. Using random higher numbers just means that I have to use random window sizes and what not.
Yeah, I could have 300 char wide terms, or 600 if I really wanted to. There was a reason for 79. There isn't for 99.
Edit: Glad to see that section might get an update http://bugs.python.org/issue18472#msg194086
Edit2: Gudio van Rossum proposes a patch https://codereview.appspot.com/12269044/diff/1/pep-0008.txt
Yeah, I could have 300 char wide terms, or 600 if I really wanted to. There was a reason for 79. There isn't for 99.
Edit: Glad to see that section might get an update http://bugs.python.org/issue18472#msg194086
Edit2: Gudio van Rossum proposes a patch https://codereview.appspot.com/12269044/diff/1/pep-0008.txt
Unable to edit this any more, but the patch has been applied http://bugs.python.org/issue18472#msg194144
Thanks for pointing that out. Also, the second link, being a perfectly clear and readable side-by-side diff is exactly the reason why 79 chars is important.
My N=5 anecdote is the opposite; people who respect that limit have better looking - and simpler - code then those who don't.
There's a reason newspaper stories are in columns.
There's a reason newspaper stories are in columns.
Agreed. Text of the revised recommendation:
> Aim to limit all lines to a maximum of 79 characters, but up to 99 characters is acceptable when it improves readability.
> Aim to limit all lines to a maximum of 79 characters, but up to 99 characters is acceptable when it improves readability.
Nobody ever specifies whether or not 0x0a counts towards their limit.
http://i.imgur.com/LypKK8I.png
http://i.imgur.com/LypKK8I.png
The reason it's 79 instead of 80 is to allow for at least one funky glyph at the end of the line since many editors do that kind of thing.
No, its so a diff looks good (with < or > lines in the first column)
edit: you're correct, that's the rationale in the pep. It's not why I stick at 79 though, I do it for git log -p, etc.
edit: you're correct, that's the rationale in the pep. It's not why I stick at 79 though, I do it for git log -p, etc.
That's between lines, isn't it?
OTOH, 0x0d definitely counts toward the limit!
OTOH, 0x0d definitely counts toward the limit!
Take it away and there is no line, just a text fragment: /bin/echo -n and then
In other words, it's a line ending, not a line separator.
In other words, it's a line ending, not a line separator.
I've always used my best judgement. It's a peeve of mine that devs stick to that as a hard-and-fast rule, even when you're 1 or 2 characters over, and apply some crazy indent structure just to get past it.
While we're at it, can we ditch the convention of indenting arguments to line up with the method name? A single tab per-nested level will do.
While we're at it, can we ditch the convention of indenting arguments to line up with the method name? A single tab per-nested level will do.
"ignore = E501" is easy, free productivity and maintainability boost.
I'm in two minds. I prefer not to have to have everything too wide, as that messes up running editors side-by-side and for viewing side-by-side diffs.
I think I'm fine with it provided that readability doesn't suffer if my editor or viewer wraps line >79 characters. I don't want to be forced to make everything wider to see that extra readability. But if making it wider makes it more readable even if my editor wraps the line, then that makes sense.
I think I'm fine with it provided that readability doesn't suffer if my editor or viewer wraps line >79 characters. I don't want to be forced to make everything wider to see that extra readability. But if making it wider makes it more readable even if my editor wraps the line, then that makes sense.
The only thing that makes me really sad is the aversion to tab indentation
I get it, it looks nicer with 4 spaces. I'm still not convinces it's a straight win.
(Of course, you should never mix tabs and spaces, and I'm glad Python 3 enforces this)
I get it, it looks nicer with 4 spaces. I'm still not convinces it's a straight win.
(Of course, you should never mix tabs and spaces, and I'm glad Python 3 enforces this)
I'm one of the few guys who prefer tabs to spaces... but I actually find this change welcome:
before, some people criticized my choice believing that the PEP8 favored one of the 2 approaches, when in fact it just acknowledged that spaces were used more often, and in no case that was an excuse to change pre-existing code... there was some confusion
At least now I can/have-to concede that there's one preferred way
OTOH: I still find subpar the handling of space indentation in most editors nowaday (emacs, vim, gedit... you name it: they all behave similarly)... I could write some emacs-lisp to make the editor behave as I wish, but I never found that hitch worth scratching enough
before, some people criticized my choice believing that the PEP8 favored one of the 2 approaches, when in fact it just acknowledged that spaces were used more often, and in no case that was an excuse to change pre-existing code... there was some confusion
At least now I can/have-to concede that there's one preferred way
OTOH: I still find subpar the handling of space indentation in most editors nowaday (emacs, vim, gedit... you name it: they all behave similarly)... I could write some emacs-lisp to make the editor behave as I wish, but I never found that hitch worth scratching enough
What is the problem with space handling that makes it sub-par?
More keystrokes when navigating the code
(I know, if vim was second nature to me, this point would probably be moot... but I'm still using the arrow keys a lot :) )
(I know, if vim was second nature to me, this point would probably be moot... but I'm still using the arrow keys a lot :) )
In vim, you can have the tab key print 4 (or n) space characters, have movement keys jump over the 4 spaces like they would with tab characters, and delete the 4 spaces with one keystroke the same way. I don't remember the settings right now but I'll add them to this post when I get home.
please do... when I looked it, I was only able to find how to insert n spaces, and delete n spaces with a single keypress, but I sorely missed the ability to have the arrow keys jump :)
Actually, I'm not sure if I figured out how to make the movement keys treat spaces as tabs, I guess I normally end up using 0/b/$/^ if I need to navigate around them (sorry!). These settings are what I use, and will at least change backspace to delete 4 spaces in one keystroke instead of 4, which is what always annoyed me most.
set tabstop=4
set shiftwidth=4
set softtabstop=4
set expandtabThe point is also moot in Emacs. What editor are you using that forces you to navigate one space at a time rather than being able to at least jump around by word?
I use vim. When indenting with tabs, I can use "x" (delete one character) to remove a level of indentation. When indenting with spaces, I can't. The dedent command is more verbose than just hitting "x". If I forget when working in a file with spaces, then I have a three space indent. That off-by-one-character is harder to see and correct than a giant missing tab.
Why have one of the most common semantic units in source code (indentation) represented by four characters when there is an otherwise unused character that has already great editor support. Tabs work well in every editor I've used (except notepad.exe, which can't change their display width). Spaces only work well in smart editors.
Why have one of the most common semantic units in source code (indentation) represented by four characters when there is an otherwise unused character that has already great editor support. Tabs work well in every editor I've used (except notepad.exe, which can't change their display width). Spaces only work well in smart editors.
In vim, ">>" and "<<" will indent and dedent the current line. It doesn't work with spaces and tabs mixed in with the line though. Bonus is you can do things like "10<<". This works even better with ":set rnu" turned on.
Rebind dedent to a little-used key, perhaps? I don't dedent so often that hammering a key twice is a big deal, though.
Editors aren't the only place code appears. I see it in my terminal, in git, in various web-based tools, in email, in browser textareas, etc. I don't want to reconfigure all of these things to make your code look like you see it (if they're even possible to reconfigure), also potentially breaking other applications that take for granted that a tab character aligns to 8.
Editors aren't the only place code appears. I see it in my terminal, in git, in various web-based tools, in email, in browser textareas, etc. I don't want to reconfigure all of these things to make your code look like you see it (if they're even possible to reconfigure), also potentially breaking other applications that take for granted that a tab character aligns to 8.
[deleted]
I see. I'm unaffected by this problem in my editor. Also, I am able to (and do) use a mouse most of the time.
Thanks for clarifying!
Thanks for clarifying!
The problem is that many people and many editors conflate the 'tab key' and the ASCII TAB character.
Both Emacs and Vi correctly allow you to indent by 4 spaces rather than foolishly inserting a TAB and indenting by the standard 8. Other editors like Sublime Text stupidly insert a TAB and expect you to muck with how TABs are rendered in order to indent correctly.
Since many people don't understand that distinction, they map TAB to 4 columns which is incompatible with most formatters (including all printers and HTML). Switching to spaces is the only solution which really fixes this.
Both Emacs and Vi correctly allow you to indent by 4 spaces rather than foolishly inserting a TAB and indenting by the standard 8. Other editors like Sublime Text stupidly insert a TAB and expect you to muck with how TABs are rendered in order to indent correctly.
Since many people don't understand that distinction, they map TAB to 4 columns which is incompatible with most formatters (including all printers and HTML). Switching to spaces is the only solution which really fixes this.
I prefer not hitting tab at all because my editor already knows how far to indent. But when it does indent, I like it to use tab characters as a way to distinguish semantic indentation from alignment indentation.
And because emacs and vim are still "dumb" editors in some ways: They still conflate the arrow keys with "move one character", when they should really mean "move one character, unless you are in non-alignment indentation, in which case move one level of indentation, which happens to correspond to four spaces since this particular file is python." They have similar problems with backspace and delete, regexes and search/replace, etc.
Further, what if you prefer 2 or 3 space indentation? If you use semantic tabs, you can have that simply by changing the display width of the tab character. It needn't be equivalent in width to 8 characters. To my knowledge, emacs and vim are both too dumb to display code indented with spaces at a different indentation width than saved in the file.
Note that when using semantic tabs, tabs only represent semantic indentation. A new block adds a tab. Further indentation for the purpose of aligning multi-line statements must be done with spaces. Tabs following spaces on a line are always wrong. Tabs are not to be used to align to columns. If you want to do that, use spaces.
For example:
And because emacs and vim are still "dumb" editors in some ways: They still conflate the arrow keys with "move one character", when they should really mean "move one character, unless you are in non-alignment indentation, in which case move one level of indentation, which happens to correspond to four spaces since this particular file is python." They have similar problems with backspace and delete, regexes and search/replace, etc.
Further, what if you prefer 2 or 3 space indentation? If you use semantic tabs, you can have that simply by changing the display width of the tab character. It needn't be equivalent in width to 8 characters. To my knowledge, emacs and vim are both too dumb to display code indented with spaces at a different indentation width than saved in the file.
Note that when using semantic tabs, tabs only represent semantic indentation. A new block adds a tab. Further indentation for the purpose of aligning multi-line statements must be done with spaces. Tabs following spaces on a line are always wrong. Tabs are not to be used to align to columns. If you want to do that, use spaces.
For example:
def foo():
--->if (long_named_function_that_returns_a_boolean() and
--->....thing2() and thing3()):
--->--->do_stuff()
def foo():
->if (long_named_function_that_returns_a_boolean() and
->....thing2() and thing3()):
->->do_stuff()
> Further, what if you prefer 2 or 3 space indentation?
This, alone, is why I always use tabs, no matter what any style guide says. People have different tastes. Using tabs allows any editor to indent according to personal tastes.
This, alone, is why I always use tabs, no matter what any style guide says. People have different tastes. Using tabs allows any editor to indent according to personal tastes.
The only exception to that rule that I personally make is indenting in-line comments; I've found that some comment-heavy code benefits from alignment, but multiparagraph alignment is a futile and counterproductive goal, so the tab mark is a good fit.
I prefer not to have to juggle invisible characters when editing plain text.
Tabs are visible in my editor. And so are the spaces at the end of a line it's sweet:
:set listchars=tab:\|·,trail:·
Isn't it a little self-defeating to make indentation visible? The whole idea is that it's easy to pick out blocks by the shape of the left margin, i.e., where the first visible character is.
If your indentation scheme only works when configuring your editor to mark whitespace, we might as well go back to MUMPS and indent with dots.
If your indentation scheme only works when configuring your editor to mark whitespace, we might as well go back to MUMPS and indent with dots.
I'm using ST3 (and ST2 before that) with the default tab handling options, and it inserts spaces and not tabs. I don't think it'd have the rapid adoption among Python programmers if it didn't.
Just add
"translate_tabs_to_spaces": true
That doesn't work if I'm editing a TABs-Are-8 file and still want to be able to indent by 4.
You need to use spaces for alignment, so indenting with tabs and aligning stuff (in the way suggested by PEP8[0]) is impossible without mixing tabs and spaces.
[0]: http://www.python.org/dev/peps/pep-0008/#maximum-line-length
[0]: http://www.python.org/dev/peps/pep-0008/#maximum-line-length
If you read carefully, you'll see that you don't actually _need_ to align, you can always indent it further
In fact, I always found space-alignment cumbersome and sometimes ugly... always indenting with tabs was thus perfectly consistent
But that's the past, now :)
In fact, I always found space-alignment cumbersome and sometimes ugly... always indenting with tabs was thus perfectly consistent
But that's the past, now :)
YMMV but I always felt the spirit of that rule was "Don't mix tabs and spaces for indenting (ie. where it matters to the interpreter)".
Indeed, a quick test with python -tt shows that the tab-indent/space-align method does not throw an error, while using tabs and spaces to indent does.
Indeed, a quick test with python -tt shows that the tab-indent/space-align method does not throw an error, while using tabs and spaces to indent does.
As pointed out to me by a friend that's forced to use the style guide at their new job, the Pet Peeves[1] section is somewhat ironic. It talks about avoiding extraneous whitespace (such as when lining up equal signs in variable declarations) and then proceeds to use extraneous whitespace in the Yes/No tags preceding code blocks. Apparently it does nothing for code readability, but it's useful for the information on the page...
[1]: http://www.python.org/dev/peps/pep-0008/#pet-peevesThe tags aren't code though so the style guide wouldn't apply there. In this case they're lined up for clarity as to the differences between the lines.
/pedantic
/pedantic
The Yes/No tags are not code. The PEP is not advocating their style for all text documents.
Obviously. Yet they are both presenting lists of items, with identifiers and values. I find expressing examples of a rule using a method the rule expressly outlines not to use (even if in a different language), ironic.
Here is a more readable diff: https://www.draftable.com/compare/9spTfcM
That looks nice, but do a quick comparisson:
go to the "Maximum Line Length" section. Now try to understand the changes wit the side-by-side one.
Now go to the original article link and do the same. It's much easier. At least for me.
go to the "Maximum Line Length" section. Now try to understand the changes wit the side-by-side one.
Now go to the original article link and do the same. It's much easier. At least for me.
My one beef with the pep still is the one module per line recommendation:
"Imports should usually be on separate lines ... No: import sys, os"
Why not? I don't really spend a lot of time studying stdlib imports, nor need them on separate lines. Pyflakes will yell at me if something was not imported.
After all, one does (and is legal in the pep): from subprocess import Popen, PIPE, ... So how is that different conceptually than doing from stdlib import os, re, sys, ...
I certainly agree with separating stdlib, 3rd party libs, and your own modules by blank lines.. but why should usually trivial stdlib imports need so many lines?
"Imports should usually be on separate lines ... No: import sys, os"
Why not? I don't really spend a lot of time studying stdlib imports, nor need them on separate lines. Pyflakes will yell at me if something was not imported.
After all, one does (and is legal in the pep): from subprocess import Popen, PIPE, ... So how is that different conceptually than doing from stdlib import os, re, sys, ...
I certainly agree with separating stdlib, 3rd party libs, and your own modules by blank lines.. but why should usually trivial stdlib imports need so many lines?
If I see `from subprocess ...`, I know immediately that this module does something with subprocesses, and I don't much care about the rest of the line.
If I see `import os, sys, foo, bar...` then I don't get that information without actually inspecting the rest of the line.
The difference is minor, but skimming is valuable.
If I see `import os, sys, foo, bar...` then I don't get that information without actually inspecting the rest of the line.
The difference is minor, but skimming is valuable.
Ah crap, say it ain't so. Never noticed that before (in the "Comments" section):
"You should use two spaces after a sentence-ending period."Most code is read in fixed-width fonts. I don't see why this is controversial. The argument to use only one space after a sentence-ending period only makes sense when reading in a variable-width font as the width of the space is corrected when rendered (and two spaces over-corrects).
No, extra space after a period is always in poor taste.
(Some people go as far as to recommend less than word space after a period or comma, since the blank area above the punctuation mark contributes to the total visual white space.)
Use a single word space between sentences. In the nineteenth century,
which was a dark and inflationary age in typography and type design,
many compositors were encouraged to stuff extra space between sentences.
Generations of twentieth century typists were then taught to do the
same, by hitting the spacebar twice after every period. Your typing
as well asyour typesetting will benefit from unlearning this quaint
Victorian habit. As a general rule, no more than a single space is
required after a period, colon, or any other mark of punctuation.
Larger spaces (e.g., en spaces) are *themselves* punctuation.
(Some people go as far as to recommend less than word space after a period or comma, since the blank area above the punctuation mark contributes to the total visual white space.)
Do any variable-width fonts actually do that? Looking at your comment, for example, the spaces after periods look the same width as those between words to my eye.
The em space fell out of favor when HTML got popular, because HTML renderers (ie. your browser) will strip extra spaces. So when looking at a web page, there actually is no difference between one and one hundred spaces (or two).
I'm not sure I'd call it controversial, but it is definitely a small annoyance because of muscle memory.
Anyway, in the grand scheme of things this is really insignificant :) The fact that PEP8 exists at all is just one of the things making Python great!
Anyway, in the grand scheme of things this is really insignificant :) The fact that PEP8 exists at all is just one of the things making Python great!
Ya. Seems like it would have been better if the implementation of variable-width fonts didn't goof and over-correct when presented with two spaces. As it is, they need to do something special when they see Mr. SoAndSo or Dr. SoAndSo, which would be, presumably, language-dependent. Then, everyone could always type two spaces after a sentence-ending period and it would always look good, regardless of whether it was rendered as fixed- or variable-width.
I thought only technology-illiterate people made that error. Very surprised to see that.
Or those of us who learned to type back in the days of Ye Typewriter.
It's supposed to be an em-space, not two normal spaces, but that is hard to to in ASCII.
vim does it by default (eg. when rewrapping a paragraph). I only recently discovered the nojoinspaces option to turn it off. Before that I was removing the extra space by hand all the time.
Say it ain't so...
:%s/\. /\. /g
:%s/\. /\. /g
It's not worth typing all that to remove one extra space.
"/ ^Mx" is easier.
the command gJ does a join without the space logic.
I really, really never understood why to indent with spaces, instead of tabs.
I hoped this would've changed, but no...
I want to set for myself how much spaces represent an indentation, not someone else, it depends so much on your setup, the monitor, resolution, font settings, editor setup, if 2 spaces are fine, or 3 or 4...
I want to set for myself how much spaces represent an indentation, not someone else, it depends so much on your setup, the monitor, resolution, font settings, editor setup, if 2 spaces are fine, or 3 or 4...
My personal frustration with Python's coding standards is the combination of PascalCaseNames and snake_case_names. Rust has adopted the same coding style. :(
Plenty of C++ code uses UPPERCASE_SNAKE_CASE_NAMES for macros, but that doesn't seem so bad because macros are ugly and should be used less frequently than classes and functions. (I hope!)
Plenty of C++ code uses UPPERCASE_SNAKE_CASE_NAMES for macros, but that doesn't seem so bad because macros are ugly and should be used less frequently than classes and functions. (I hope!)
Curious, why's that bother you? Different things should look different, and all. :) The alternative for class names is Camel_Snake, which will get you smacked in virtually any language.
Python code does tend to use UPPERCASE_SNAKE for "constants" as well, probably inherited from C (sometimes via Perl or Ruby).
Python code does tend to use UPPERCASE_SNAKE for "constants" as well, probably inherited from C (sometimes via Perl or Ruby).
Mixing the styles just feels inconsistent. The only language I know where Camel_Snake is used is Ada.
What happens when you want to write a set of functions to handle a set of classes? Especially when you are given a class and want to figure out which handler to call dynamically - eg you have FooEvent, should the function be "handle_foo_event", "handle_FooEvent", "HandleFooEvent", or any of several other possibilities?
It would be nice to have a gofmt for python.
Or is there already a Ninja-IDE plugin that formats code?
Or is there already a Ninja-IDE plugin that formats code?
We do have a gofmt for Python.
pip install autopep8
Just pip search pep8 to see all the tooling.
It's not a "Ninja IDE" thingjobber, just a command line tool.
pip install autopep8
Just pip search pep8 to see all the tooling.
It's not a "Ninja IDE" thingjobber, just a command line tool.
It's 2013. Let's fix the tools.
You think we would have gotten past the point of having to manually figure out "where should I break these lines for the best readability." Code is meant to be consumed by machines, and a machine should be capable of parsing the stuff, figuring out visual structure, and wrapping dynamically to account for window width and readable line-lengths in a way that preserves the visual structure.