We Keep Coding

Avoiding indentation in Python else and elif

In writing a Python code in Wing or IDLE, inside the if condition, we must have an indentation for each line. But the else and the elif part must be aligned with if. However when I type else: or elif: in a newline, it has an indentation and I must remove it manually. I have seen it in several IDEs like Wing.
Is there any way to avoid indentation for else and elif? Indeed I need this:
if (condition):
do this
else:
do this
But when I type it, it's like:
if (condition)
do this
else:
do this

You seem to believe the editor will somehow know how many lines the indented suites of code should have.
It would be easy to make editors "outdent" if those suites were all one line, but a cursory inspection of any moderately complex Python program will show that is clearly not the case.
Which means it's up to us to indicate the end by outdenting manually, usually with SHIFT-TAB, at the end of the clause.

Python proper code formatting (PEP8)

So I just learned about "List Comprehensions" in python. some of these are getting too long for a single line (PEP8) and I'm trying to figure out the best (most readable) way to break these out.
I've come up with this
questions = [
(
q,
q.vote_set.filter(choice__exact='Y'),
q.vote_set.filter(choice__exact='N'),
request.session.get(str(q.id))
)
for q in questions
]
but it still complains about whitespace before the ], the specific pep8 error is E202
this is in an indented block.

I would probably do it like this:
questions = [(q,
q.vote_set.filter(choice__exact='Y'),
q.vote_set.filter(choice__exact='N'),
request.session.get(str(q.id)))
for q in questions]
Keep in mind that PEP8 is intended to be used along with your best judgement; they aren't intended to be followed absolutely in all circumstances. They also aren't structured to always make sense when multiple rules conflict.
It's OK to intentionally break the rules once in a while; checkers like that are just intended to make sure you don't break them accidentally.
Edit: Moving my comment into my answer.
Your code looks a little bit too much like a Lisp-like parenthesis language or a C-like curly-braces language because of you putting brackets and parenthesis on separate lines.
In Python, you just use indentation to show what you would normally show with a bracket / parenthesis / brace on a separate line in another language. If you take your code and make that change, it's identical to my version.
Really though, don't worry too much about the PEP checker. If you really like the extra whitespace you get from putting the parenthesis and brackets on separate lines, then do it. It doesn't make it "bad code" nor does it decrease the readability.

Depends upon to the tool, I guess. Which tool is giving you E202? I copy pasted and tried with this pep8 tool and it did not give any error. But I specifically but a whitespace after questions and got the error.
The E202 on the ] says that it is finding a whitespace before that. Make sure that you don't have that in the code. Try closing ] soon after questions.

Consider writing your statement using a generator expression.
questions = ((q,
q.vote_set.filter(choice__exact='Y'),
q.vote_set.filter(choice__exact='N'),
request.session.get(str(q.id)),)
for q in questions)
Additionally, not that its "wrong", but in general I don't recommend redefining declared variables cause it may cause confusion in the code. In this case you are changing the questions instance to another type.

I was also unable to reproduce your PEP8 warning with the code you showed above. Perhaps you could put your exact code in a pastebin?
The example test cases for PEP8 (if you use the --show-pep8 option) are as follows:
Avoid extraneous whitespace in the following situations:
- Immediately inside parentheses, brackets or braces.
- Immediately before a comma, semicolon, or colon.
Okay: spam(ham[1], {eggs: 2})
E201: spam( ham[1], {eggs: 2})
E201: spam(ham[ 1], {eggs: 2})
E201: spam(ham[1], { eggs: 2})
E202: spam(ham[1], {eggs: 2} )
E202: spam(ham[1 ], {eggs: 2})
E202: spam(ham[1], {eggs: 2 })
E203: if x == 4: print x, y; x, y = y , x
E203: if x == 4: print x, y ; x, y = y, x
E203: if x == 4 : print x, y; x, y = y, x
Also, I haven't actually used Textmate, but if you're doing on the fly checking similar to emacs' flymake mode, then it could also be that pep8 is getting called on an old version of the file, and the issue may go away when you save the file. We may need more information to debug further.
As for the formatting of the list comprehension itself, you may want to take a look at this other SO question as well as the take from the Google style guide. I personally have no problem with the way you did it. I suppose you could also do something like
def _question_tuple(q):
return (
q,
q.vote_set.filter(choice__exact='Y'),
q.vote_set.filter(choice__exact='N'),
request.session.get(str(q.id))
)
question_tups = [_question_tuple(q) for q in questions]
but it's really about what will be the most readable/maintainable, and that's up to your own judgment.

Python indentation in "empty lines"

Which is preferred ("." indicating whitespace)?
A)
def foo():
x = 1
y = 2
....
if True:
bar()
B)
def foo():
x = 1
y = 2
if True:
bar()
My intuition would be B (that's also what vim does for me), but I see people using A) all the time. Is it just because most of the editors out there are broken?

If you use A, you could copy paste your block in python shell, B will get unexpected indentation error.

The PEP 8 does not seem to be clear on this issue, although the statements about "blank lines" could be interpreted in favor of B. The PEP 8 style-checker (pep8.py) prefers B and warns if you use A; however, both variations are legal. My own view is that since Python will successfully interpret the code in either case that this doesn't really matter, and trying to enforce it would be a lot of work for very little gain. I suppose if you are very adamantly in favor of one or the other you could automatically convert the one to the other. Trying to fix all such lines manually, though, would be a huge undertaking and really not worth the effort, IMHO.

Adding proper indentation to blank lines (style A in the question) vastly improves code readability with display whitespace enabled because it makes it easier to see whether code after a blank line is part of the same indentation block or not.
For a language like Python, where there is no end statement or close bracket, I'm surprised this is not part of PEP. Editing Python with display whitespace on is strongly recommended, to avoid both trailing whitespace and mixed indentation.
Compare reading the following:
A)
def foo():
....x = 1
....y = 2
....
....if True:
........bar()
B)
def foo():
....x = 1
....y = 2
....if True:
........bar()
In A, it is far clearer that the last two lines are part of foo. This is even more useful at higher indentation levels.

That empty line belongs to foo(), so I would consider A to be the most natural. But I guess it's just a matter of opinion.

TextMate breaks block collapsing if you use B, and I prefer A anyway since it's more "logical".

My experience in open-source development is that one should never leave whitespace inside blank lines. Also one should never leave trailing white-space.
It's a matter of coding etiquette.

I wouldn't necessarily call the first example "broken", because I know some people hate it when the cursor "jumps back" when moving the cursor up or down in code. E.g. Visual Studio (at least 2008) automatically prevents this from happening without using any whitespace characters on those lines.

B is preferred - i.e. no indentation. PEP 8 says:
Avoid trailing whitespace anywhere. Because it's usually invisible, it can be confusing: e.g. a backslash followed by a space and a newline does not count as a line continuation marker. Some editors don't preserve it and many projects (like CPython itself) have pre-commit hooks that reject it.

Emacs does B) for me, but I really don't think it matters. A) means that you can add in a line at the correct indentation without any tabbing.

vi implicitly discourages the behaviour in A because the {/} navigations no longer work as expected. git explicitly discourages it by highlighting it in red when you run git diff. I would also argue that if a line contains spaces it is not a blank line.
For that reason I strongly prefer B. There is nothing worse than expecting to skip six or so lines up with the { motion and ending up at the top of a class def.

Is it true that I can't use curly braces in Python?

I was reading that Python does all it's "code blocks" by indentation, rather than with curly braces. Is that right? So functions, if's and stuff like that all appear without surrounding their block with curly braces?

You can try to add support for braces using a future import statement, but it's not yet supported, so you'll get a syntax error:
>>> from __future__ import braces
File "<stdin>", line 1
SyntaxError: not a chance

Correct for code blocks. However, you do define dictionaries in Python using curly braces:
a_dict = {
'key': 'value',
}
Ahhhhhh.

Yes. Curly braces are not used. Instead, you use the : symbol to introduce new blocks, like so:
if True:
do_something()
something_else()
else:
something()

Python with Braces is a variant of python that lets you do exactly that.
It's a project that I've been working on lately together with my friend.

Use Whyton:
http://writeonly.wordpress.com/2010/04/01/whython-python-for-people-who-hate-whitespace/

Yup :)
And there's (usually) a difference between 4 spaces and a tab, so make sure you standardize the usage ..

Yes.
if True:
#dosomething
else:
#dosomething else
#continue on with whatever you were doing
Basically, wherever you would've had an opening curly brace, use a colon instead. Unindent to close the region. It doesn't take long for it to feel completely natural.

>>> from __future__ import braces
File "<stdin>", line 1
SyntaxError: not a chance
Well that explains a lot.
Note however, that Python does natively support curly brace-d code blocks! Take a look at below:
if x: #{
x += 1
#}
For Ada or Pascal programmers, I take delight in revealing to you:
if x: #BEGIN
...
#END
Taken from the docs:
Python's parser is also sophisticated enough to recognize mixed
notations, and it will even catch missing beginning or end
delimiters and correct the program for the user. This allows the
following to be recognized as legal Python:
if x: #BEGIN
x = x + 1
#}
And this, for Bash users:
if x:
x=99
#fi
Even better, for programmers familiar with C, C++, etc. you can omit the curly braces completely for only one statement:
if x:
do_stuff()
Beautiful. As mentioned before, Python can also automatically correct code with incorrect delimiters, so this code is also legal:
if x:
do_a_hundred_or_more_statements()
x = x + 1
print(x)
As this must make you love Python even more, I send you off with one last quote from the docs.
Now as you can see from this series of examples, Python has
advanced the state of the art of parser technology and code
recognition capabilities well beyond that of the legacy languages.
It has done this in a manner which carefully balances good coding
style with the need for older programmers to feel comfortable with
look of the language syntax.
The only limitation is that these special delimiters be preceded by a hashtag symbol.

Python does not use curly braces for code blocks:
>>> while True {
File "<stdin>", line 1
while True {
^
SyntaxError: invalid syntax
>>> from __future__ import braces
File "<stdin>", line 1
SyntaxError: not a chance
(Notice the "not a chance" message – this is an Easter egg reflecting this design decision.)
As a language designed to be easy to use and read, Python uses colons and indentation to designate code blocks. Defining code blocks by indentation is unusual and can come as a surprise to programmers who are used to languages like C++ and C# because these (and many other languages) don't care about extra whitespace or indentation. This rule is intended to increase readability of Python code, at the cost of some of the programmer's freedom to use varying amounts of whitespace.
An increase in the indentation level indicates the start of a code block, while a decrease indicates the end of the code block. By convention, each indentation is four spaces wide.
Here's a simple example which sums all the integers from 0 to 9. Note that ranges in Python include the first value, up to but not including the last value:
j = 0
for i in range(0, 10):
j += i
print(j)

Yes you can use this library/package { Py }
Use curly braces instead of indenting, plus much more sugar added to Python's syntax.
https://pypi.org/project/brackets/
// Use braces in Python!
def fib(n) {
a, b = 0, 1
while (a < n) {
print(a, end=' ')
a, b = b, a+b
}
print()
}
/*
Powerful anonymous functions
*/
print([def(x) {
if(x in [0, 1]) {
return x
};
while (x < 100) {
x = x ** 2
};
return x
}(x) for x in range(0, 10)])

As others have mentioned, you are correct, no curly braces in Python. Also, you do not have no end or endif or endfor or anything like that (as in pascal or ruby). All code blocks are indentation based.

Yes, code blocks in Python are defined by their indentation. The creators of Python were very interested in self-documenting code. They included indentation in the syntax as a way of innately enforcing good formatting practice.
I programmed in Python for a few years and became quite fond of its code structure because it really is easier. Have you ever left out a closing curly brace in a large program and spent hours trying to find it? Not a problem in Python. When I left that job and had to start using PHP, I really missed the Python syntax.

I will give some thoughts about this question.
Admittedly at first I also thought it is strange to write code without curly braces. But after using Python for many years, I think it is a good design.
First, do we really need curly braces? I mean, as a human. If you are allowed to use curly braces in Python, won't you use indentation anymore? Of course, you will still use indentation! Because you want to write readable code, and indentation is one of the key points.
Second, when do we really need curly braces? As far as I think, we only strictly need curly braces when we need to minify our source code files. Like minified js files. But will you use Python in a situation that even the size of source code is sensitive? Also as far as I think, you won't.
So finally, I think curly braces are somehow like ;. It is just a historical issue, with or without it, we will always use indentation in Python.

In Python, four spaces() are used for indentation in place of curly braces ({). Though, curly braces are used at few places in Python which serve different purpose:
Initialize a non-empty set (unordered collection of unique elements):
fuitBasket = {'apple', 'orange', 'apple', 'pear', 'orange', 'banana'}
Citation
Initialize an empty dictionary (key-value pairs):
telephoneNumbers = {}
Initialize a non-empty dictionary (key-value pairs):
telephoneNumbers = {'jack': 4098, 'sape': 4139}
Citation

In relation to format string, curly braces take on a different meaning. See https://docs.python.org/3/library/string.html?highlight=curly :
Format strings contain “replacement fields” surrounded by curly braces
{}. Anything that is not contained in braces is considered literal
text, which is copied unchanged to the output. If you need to include
a brace character in the literal text, it can be escaped by doubling:
{{ and }}.

Is there a way to convert indentation in Python code to braces?

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.