PEP8 clearly specifies 79 characters, however, PyCharm defaults to 120 and gives me the warning "PEP8: line too long (... > 120 characters)".
Did previous versions of PEP8 use 120 and PyCharm not update its PEP8 checker? I couldn't find any previous versions of the PEP8 Guide, however, I can easily find previous version of the PEP8 Python scripts.
I'm starting a new Python project and I'm not sure which to use.
References:
http://legacy.python.org/dev/peps/pep-0008/
PyCharm is built on top of IntelliJ. IntelliJ has a default line length of 120 characters.
This is probably because you can't fit a common Java name like: #annotated public static MyObjectFactoryFactory enterpriseObjectFactoryFactoryBuilderPattern { in a mere 80 character line. (I'm poking fun, but Java names do tend to be longer by convention).
The pep8 checker is configurable, so you can specify a better max line length - like 79 characters.
The error is misleading because the pep8 checker formats the text with something like "PEP8: line too long(... > %s characters)" % max_line_setting. So it's using the pep8 checker, with a specific configuration, not claiming that pep8 specifies a 120 character line.
If you want to remove the limit warning altogether you can take the following steps:
In PyCharm, click File > Settings
In the project settings section, click Editor > Inspections
In the list that appears, expand Python
Under Python, scroll down and click "PEP8 coding style violation"
Click the + button next to "Ignore errors" in the bottom right
Type out E501 and click Apply and/or OK
Sources:
http://iambigblind.blogspot.com/2013/02/configuring-pep8py-support-in-pycharm-27.html
https://intellij-support.jetbrains.com/hc/en-us/community/posts/205816889-Disable-individual-PEP8-style-checking-line-length-
AFAIK, PEP8 has never allowed 120 characters, but not everyone follows PEP8.
To answer your question: stay under 80 characters, both from common courtesy and good sense.
So im looking at some code and bringing it up to PEP 8 standard with the help of pylint and i noticed that if i was using triple quotes for a print statement where the text went past 120 chars (we are allowing 120 instead of 79) pylint didn't complain.
Is this a bug in pylint or does it think it might be a comment and is more lenient with the length of lines or does it not care about how far over you go with strings in trippple quotes because you may want to format them that way?
For clarity: yes pylint works normally in every other case of going over the line length.
Having used pylint regularly, I have also noticed this inconsistency. In the Maximum Line Length section of PEP8, it says:
Therefore, please limit all lines to a maximum of 79 characters. For flowing long blocks of text (docstrings or comments), limiting the length to 72 characters is recommended.
I know that pylint does not at all enforce the 79 character or the 72 character line length limits for docstrings and comments, so I would guess that this is a pylint bug since it is non-compliant with PEP8 in this area.
As pylint maintainer, I can tell this is definitly a bug.
#Jacxel : if you've trouble registering on logilab.org, you can still post the pb on the python-projects#logilab.org mailing list
thanks
I've been using the version of python.el found here for a couple of years in Emacs 23 without incident. I decided to try the stock python.el, and ran into a strange issue:
When using tabs for indentation and a tab width of 4, the stock python.el will indent two tab characters for every level instead of 1. With a tab width of 5, the indentation will be 1 tab plus 3 spaces. So, when indent-tabs-mode is t, indent-for-tab-command seems to always force a tab size of 8, regardless of what tab-width is set to.
Is there some other tab-related variable I can set to override this behavior?
I think I've figured this out after digging through the source code for the stock Emacs 23 python.el and the newest python.el on the block.
Given these settings in a python-mode buffer, indentation with tabs and a tab-width of 4 works as expected in stock python.el:
(setq indent-tabs-mode t
tab-width 4
python-indent 4)
For the new python.el, you need to change python-indent to python-indent-offset. I'm using both settings for both modes without issue.
If someone has a better solution to this problem, please add it and I'll gladly accept it as the correct answer.
stuck using tabs? check
trying out emacs 23 with python.el? check
I've run into the same wall as you recently... what I've learned is that I truly hate tabs and that I find python's whitespace significance incredibly annoying.
Are you setting tab-width in your init or with customize?
I had to make sure to change tab-width in the "Editing Basics" section via customize to get "4 space" tabs to stick (something to do with global/local scope). But the fun doesn't end there... python.el seems to only want to indent to the first tab-stop (column 4 now) and no further no matter what I set indent-tab-mode or tab-always-indent to. I finally gave up and went back to using python-mode.el, which has it's own set of idiosyncrasies, but at least python code is indenting "correctly".
Normally when you hit tab on an empty line in emacs python mode it will cycle through the available tab indentations. When I hit tab when the point is at the deepest indent level I get the pabbrev buffer containing the last best match options. Does anyone else have this problem, is there an easy way around it without writing any elisp?
EDIT:
Trey, I want to keep pabbrev working in python mode not turn it off.
So lets say there are 2 indent levels, either none, or 1 level normally if it hit tab 3 times the first would put the point at 4 spaces in (or whatever indent is set to), the second back to 0 spaces, and the third back to 4 spaces.
With pabbrev mode on one indent puts the mark 4 spaces, the second brings up a buffer for autocomplete. This should not happen if there is no letters to the left of my point.
Does that make any more sense?
In light of the clarified requirements, you need something along the lines of this. I'm pretty sure you can't get away w/out writing some elisp. What's nice (IMO) is that this should work for all modes, not just python mode.
(defadvice pabbrev-expand-maybe (around pabbrev-expand-maybe-when-not-after-whitespace activate)
"prevent expansion when only whitespace between point and beginning of line"
(if (save-match-data
(save-excursion
(let ((p (point)))
(string-match "^\\s-*$" (buffer-substring-no-properties (progn (beginning-of-line) (point)) p)))))
(let ((last-command (if (eq last-command this-command) (pabbrev-get-previous-binding) last-command))
(this-command (pabbrev-get-previous-binding)))
(pabbrev-call-previous-tab-binding))
ad-do-it))
How is this for a late response?
This should work out of the box now, thanks to a patch from Trey. Binding tab in the way that pabbrev.el is somewhat naughty, but what are you to do if you want rapid expansion.
No elisp? Sure:
M-x pabbrev-mode
should toggle it off. But, if you don't mind cutting/pasting elisp, you can turn off pabbrev mode in python buffers:
(add-hook 'python-mode (lambda () (pabbrev-mode -1)))
I am a totally blind programmer who would like to learn Python. Unfortunately the fact that code blocks are represented with different levels of indentation is a major stumbling block. I was wondering if there were any tools available that would allow me to write code using braces or some other code block delimiter and then convert that format into a properly indented representation that the Python interpreter could use?
There's a solution to your problem that is distributed with python itself. pindent.py, it's located in the Tools\Scripts directory in a windows install (my path to it is C:\Python25\Tools\Scripts), it looks like you'd have to grab it from svn.python.org if you are running on Linux or OSX.
It adds comments when blocks are closed, or can properly indent code if comments are put in. Here's an example of the code outputted by pindent with the command:
pindent.py -c myfile.py
def foobar(a, b):
if a == b:
a = a+1
elif a < b:
b = b-1
if b > a: a = a-1
# end if
else:
print 'oops!'
# end if
# end def foobar
Where the original myfile.py was:
def foobar(a, b):
if a == b:
a = a+1
elif a < b:
b = b-1
if b > a: a = a-1
else:
print 'oops!'
You can also use pindent.py -r to insert the correct indentation based on comments (read the header of pindent.py for details), this should allow you to code in python without worrying about indentation.
For example, running pindent.py -r myfile.py will convert the following code in myfile.py into the same properly indented (and also commented) code as produced by the pindent.py -c example above:
def foobar(a, b):
if a == b:
a = a+1
elif a < b:
b = b-1
if b > a: a = a-1
# end if
else:
print 'oops!'
# end if
# end def foobar
I'd be interested to learn what solution you end up using, if you require any further assistance, please comment on this post and I'll try to help.
I personally doubt that there currently is at the moment, as a lot of the Python afficionados love the fact that Python is this way, whitespace delimited.
I've never actually thought about that as an accessibility issue however. Maybe it's something to put forward as a bug report to Python?
I'd assume that you use a screen reader here however for the output? So the tabs would seem "invisible" to you? With a Braille output, it might be easier to read, but I can understand exactly how confusing this could be.
In fact, this is very interesting to me. I wish that I knew enough to be able to write an app that will do this for you.
I think it's definately something that I'll put in a bug report for, unless you've already done so yourself, or want to.
Edit: Also, as noted by John Millikin There is also PyBraces Which might be a viable solution to you, and may be possible to be hacked together dependant on your coding skills to be exactly what you need (and I hope that if that's the case, you release it out for others like yourself to use)
Edit 2: I've just reported this to the python bug tracker
Although I am not blind, I have heard good things about Emacspeak. They've had a Python mode since their 8.0 release in 1998 (they seem to be up to release 28.0!). Definitely worth checking out.
You should be able to configure your editor to speak the tabs and spaces -- I know it's possible to display whitespace in most editors, so there must be an accessibility option somewhere to speak them.
Failing that, there is pybraces, which was written as a practical joke but might actually be useful to you with a bit of work.
If you're on Windows, I strongly recommend you take a look at EdSharp from:
http://empowermentzone.com/EdSharp.htm
It supports all of the leading Windows screenreaders, it can be configured to speak the indentation levels of code, or it has a built in utility called PyBrace that can convert to and from braces syntax if you want to do that instead, and it supports all kinds of other features programmers have come to expect in our text editors. I've been using it for years, for everything from PHP to JavaScript to HTML to Python, and I love it.
All of these "no you can't" types of answers are really annoying. Of course you can.
It's a hack, but you can do it.
http://timhatch.com/projects/pybraces/
uses a custom encoding to convert braces to indented blocks before handing it off to the interpreter.
As an aside, and as someone new to python - I don't accept the reasoning behind not even allowing braces/generic block delimiters ... apart from that being the preference of the python devs. Braces at least won't get eaten accidentally if you're doing some automatic processing of your code or working in an editor that doesn't understand that white space is important. If you're generating code automatically, it's handy to not have to keep track of indent levels. If you want to use python to do a perl-esque one-liner, you're automatically crippled. If nothing else, just as a safeguard. What if your 1000 line python program gets all of its tabs eaten? You're going to go line-by-line and figure out where the indenting should be?
Asking about it will invariably get a tongue-in-cheek response like "just do 'from __ future __ import braces'", "configure your IDE correctly", "it's better anyway so get used to it" ...
I see their point, but hey, if i wanted to, i could put a semicolon after every single line. So I don't understand why everyone is so adamant about the braces thing. If you need your language to force you to indent properly, you're not doing it right in the first place.
Just my 2c - I'm going to use braces anyway.
I appreciate your problem, but think you are specifying the implementation instead of the problem you need solved. Instead of converting to braces, how about working on a way for your screen reader to tell you the indentation level?
For example, some people have worked on vim syntax coloring to represent python indentation levels. Perhaps a modified syntax coloring could produce something your screen reader would read?
Searching an accessible Python IDE, found this and decided to answer.
Under Windows with JAWS:
Go to Settings Center by pressing JawsKey+6 (on the number row above the letters) in your favorite text editor. If JAWS prompts to create a new configuration file, agree.
In the search field, type "indent"
There will be only one result: "Say indent characters". Turn this on.
Enjoy!
The only thing that is frustrating for us is that we can't enjoy code examples on websites (since indent speaking in browsers is not too comfortable — it generates superfluous speech).
Happy coding from another Python beginner).
I use eclipse with the pydev extensions since it's an IDE I have a lot of experience with. I also appreciate the smart indentation it offers for coding if statements, loops, etc. I have configured the pindent.py script as an external tool that I can run on the currently focused python module which makes my life easier so I can see what is closed where with out having to constantly check indentation.
There are various answers explaining how to do this. But I would recommend not taking this route. While you could use a script to do the conversion, it would make it hard to work on a team project.
My recommendation would be to configure your screen reader to announce the tabs. This isn't as annoying as it sounds, since it would only say "indent 5" rather than "tab tab tab tab tab". Furthermore, the indentation would only be read whenever it changed, so you could go through an entire block of code without hearing the indentation level. In this way hearing the indentation is no more verbose than hearing the braces.
As I don't know which operating system or screen reader you use I unfortunately can't give the exact steps for achieving this.
Edsger Dijkstra used if ~ fi and do ~ od in his "Guarded Command Language", these appear to originate from the Algol68. There were also some example python guarded blocks used in RosettaCode.org.
fi = od = yrt = end = lambda object: None;
class MyClass(object):
def myfunction(self, arg1, arg2):
for i in range(arg1) :# do
if i > 5 :# then
print i
fi
od # or end(i) #
end(myfunction)
end(MyClass)
Whitespace mangled python code can be unambiguously unmangled and reindented if one uses
guarded blocks if/fi, do/od & try/yrt together with semicolons ";" to separate statements. Excellent for unambiguous magazine listings or cut/pasting from web pages.
It should be easy enough to write a short python program to insert/remove the guard blocks and semicolons.