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 }}.
Related
I am using Python
but the space gap is making my life very hard with it
example
when I use the if statement
if Parm2 == 1:
Ch = "A"
elif Parm2 == 2:
Ch = "B"
elif Parm2 == 3:
Ch = "C"
else:
continue
mdl = CallFunc(Parm2)
print("XX Always Print XX")
now the "XX Always Print XX" should be printed regardless
but due to my mistake it is inside the if statement which cause me long time to find
the actual if statement is nested and longer
I wonder if there is a method I can use begin/end or {} in such statements in Python
something like
UPDATE
for the people who focus on the IF statement
if Parm2 == 1:
{
Ch = "A"
}
elif Parm2 == 2:
{
Ch = "B"
}
elif Parm2 == 3:
{
Ch = "C"
}
else:
{
mdl = CallFunc(Parm2)
}
print("XX Always Print XX")
Happy now??
ok now how to get the brackets work in Python?
Python is indentation based. Yeah, its harder to read and easier to make mistakes like you indicated, but that's what it is.
Think about downloading an IDE for python, like Pycharm, they are helpful for identifying errors like this one, they also have an "auto-indent" feature. But no, Python is indentation based.
What the Python designers realized is that braces or begin/end keywords are mostly noise to human programmers. They generally recognize the structure of code by its layout. For instance, if you were to write the C code:
if (condition)
x = y;
w = z;
a human would often not notice that the braces are missing, and assume that both assignments are controlled by the condition. Writing code like this is a common error, especially when you start with a block that has just one statement (so the braces are optional and were omitted), and forget to add braces when a second statement is added. (See Why is it considered a bad practice to omit curly braces?).
Conversely, if you write
if (condition) {
x = y;
w = z;
}
it looks like w = z; is not part of the conditional.
Braces mainly exist for the benefit of software that processes code (compilers, editors, IDEs), they make it easier for them to detect groups of code. The Python designers decided to mirror the way humans read code in their parser, rather than forcing humans to adapt to the computer's needs.
Braces allow for more flexible code layout, but in practice it's usually condiered wrong to take advantage of this. Writing code like
while (something) { statement1; statement2;
statement3; }
is less readable than
while something:
statement1
statement2
statement3
Python does allow some flexibility: You can separate statements on the same line with ;, and put the contents of a conditional on the same line after the :. But writing like this is not considered Pythonic, and should be used only in very special circumstances (this blog post describes those cases).
There's always some adjustment necessary when you're learning a new programming language and you're accustomed to the patterns of the languages you previously used (many programmers have refused to learn Lisp, because of its Lots of Irritating, Stupid Parentheses). But give it a little time and you'll get used to it.
This shows how you can hack it:
if True: {
print("hello")
}
If you do a google search for "python what if you don't want to use indentation for blocks" you might get:
peach pit python indentation
Programmers familiar with other languages often bristle at the thought that indentation matters: Many programmers like the freedom to format their code how they please. However, Python indentation rules are quite simple, and most programmers already use indentation to make their code readable. Python simply takes this idea one step further and gives meaning to the indentation.
i.e. they force you not to use indentation.
My problem with this is that I love to use emacs auto-indentation to reindent the whole code file but this totally screws up the indentation in python; in C or C++ this finds the indentation problems and makes them evident; in python it loses all your information and changes the meaning of the program;
Don't get me wrong I want to use BOTH rigorous indentation AND curly braces;
You can use the hack above to "circumvent" python indentation but when writing code for anyone other than yourself it won't be popular.
Basic example:
>>> table = {'username': 'John Doe'}
>>> msg = f'Hello {table['username']}'
File "<stdin>", line 1
msg = f'Hello {table['username']}'
^
SyntaxError: invalid syntax
>>> msg = f"Hello {table['username']}"
Why doesn't it work when both the format string and the inner string literal use the same quote type (both single-quoted or double-quoted)? Is this a bug in Python 3.6, or is this intentional?
edit: To make it clear why I'm asking this, something like this works fine in C#:
using System;
public static class Program {
public static void Main() {
Console.WriteLine($"Hello {"world"}");
}
}
Proof
This has nothing to do with interpolated strings. An interpolated string is read the same as any other string literal* and then interpolated, and you can't put unescaped quote characters in the middle of any string:
>>> msg = 'Hello {table['username']}'
File "<stdin>", line 1
'Hello {table['username']}'
^
SyntaxError: invalid syntax
>>> msg = 'Hello 'world''
File "<stdin>", line 1
msg = 'Hello 'world''
^
SyntaxError: invalid syntax
This is exactly why we have a choice of two different quote characters—and, when that isn't enough, triple-quoted strings. And of course escaping.
So, why can't Python be smarter here? Think about what "smarter" would mean. Assuming it can't read your mind, it would have to parse every possible way that pairs of quotes could be matched up if some of them were skipped and then figure out which one made for a valid result. That might not seem too bad for a simple one-liner at the interactive interpreter, but if it had to do that across an entire file, every time you run a non-trivial script or import a module with more than a few quotes in it, it would take minutes to try all the parses, and the result could well be ambiguous anyway.
Could they instead add special rules for handling quotes only in interpolated strings, only inside currently-open braces (but not double braces, of course, because those are escapes), and so on?
Sure, That wouldn't make the parser exponential, just more complicated. But more complicated is not good either.
The fact that Python has a simple set of rules that anyone can knock out a LL(1) implementation of—and, maybe even more importantly, that anyone can keep in their heads and work through—is a major feature of the language as compared to, say, C++. So every time there's a tradeoff between nice syntactic sugar vs. keeping the parser simple, it has to be thought through, and the answer is always keeping the parser simpler. In fact, this was an explicit decision in the Python 3 transition:
Simple is better than complex. This idea extends to the parser. Restricting Python's grammar to an LL(1) parser is a blessing, not a curse. It puts us in handcuffs that prevent us from going overboard and ending up with funky grammar rules like some other dynamic languages that will go unnamed, such as Perl.
Also, of course, that would be a difference between f-strings and str.format, which would be another rule to learn, and to relearn every time you come back to Python after a few months away. Which is a different rule from the Zen: Special cases aren't special enough to break the rules.
the problem is that it is a string and you did not do the interpolation, because that was the error, you should use string.Template to define a format string or you can use the format method of str class with which you can substitute values inside of a String
'Hello {table['username']}' this is bad
you can use 'Hello {username}'.format(username=table['username'])
see for more information: here
I got a function online to help me with my current project and it had semicolons on some of the lines. I was wondering why? Is it to break the function?
def containsAny(self, strings=[]):
alphabet = 'abcdefghijklmnopqrstuvwxyz0123456789'
for string in strings:
for char in string:
if char in alphabet: return 1;
return 0;
The function I got online with little modification:
for string in strings:
for char in string:
if char in alphabet: return 1;
Is the above saying the following?
if char in alphabet:
return 1
break
The semicolon does nothing in the code you show.
I suspect this is someone who programs in another language (C, Java, ...) that requires semicolons at the end of statements and it's just a habit (happens to me sometimes too).
If you want to put several Python statements on the same line, you can use a semi-colon to separate them, see this Python Doc:
A suite is a group of statements controlled by a clause. A suite can
be one or more semicolon-separated simple statements on the same line
as the header, following the header’s colon, or it can be one or more
indented statements on subsequent lines
The semicolon here does not do anything. People who come from C/C++/Java/(many other language) backgrounds tend to use the semicolon out of habit.
In general the semicolon does nothing. But if you are using the Jupyter Notebook (depending on your version), you might get a figure plotted twice. The semicolon at the end of your plot command prevents this:
df.plot();
Programmers of C, C++, and Java are habituated of using a semicolon to tell the compiler that this is the end of a statement, but for Python this is not the case.
The reason is that in Python, newlines are an unambiguous way of separating code lines; this is by design, and the way this works has been thoroughly thought through. As a result, Python code is perfectly readable and unambiguous without any special end-of-statement markers (apart from the newline).
As other answers point out, the semicolon does nothing there. It's a separator (e.g. print 1;print 2). But it does not work like this: def func():print 1;print 2;;print'Defined!' (;; is a syntax error). Out of habit, people tend to use it (as it is required in languages such as C/Java...).
More and more we use chained function calls:
value = get_row_data(original_parameters).refine_data(leval=3).transfer_to_style_c()
It can be long. To save long line in code, which is prefered?
value = get_row_data(
original_parameters).refine_data(
leval=3).transfer_to_style_c()
or:
value = get_row_data(original_parameters)\
.refine_data(leval=3)\
.transfer_to_style_c()
I feel it good to use backslash \, and put .function to new line. This makes each function call has it own line, it's easy to read. But this sounds not preferred by many. And when code makes subtle errors, when it's hard to debug, I always start to worry it might be a space or something after the backslash (\).
To quote from the Python style guide:
Long lines can be broken over multiple lines by wrapping expressions
in parentheses. These should be used in preference to using a
backslash for line continuation. Make sure to indent the continued
line appropriately. The preferred place to break around a binary
operator is after the operator, not before it.
I tend to prefer the following, which eschews the non-recommended \ at the end of a line, thanks to an opening parenthesis:
value = (get_row_data(original_parameters)
.refine_data(level=3)
.transfer_to_style_c())
One advantage of this syntax is that each method call is on its own line.
A similar kind of \-less structure is also often useful with string literals, so that they don't go beyond the recommended 79 character per line limit:
message = ("This is a very long"
" one-line message put on many"
" source lines.")
This is a single string literal, which is created efficiently by the Python interpreter (this is much better than summing strings, which creates multiple strings in memory and copies them multiple times until the final string is obtained).
Python's code formatting is nice.
What about this option:
value = get_row_data(original_parameters,
).refine_data(leval=3,
).transfer_to_style_c()
Note that commas are redundant if there are no other parameters but I keep them to maintain consistency.
The not quoting my own preference (although see comments on your question:)) or alternatives answer to this is:
Stick to the style guidelines on any project you have already - if not stated, then keep as consistent as you can with the rest of the code base in style.
Otherwise, pick a style you like and stick with that - and let others know somehow that's how you'd appreciate chained function calls to be written if not reasonably readable on one-line (or however you wish to describe it).
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.