I actually love indentation, Python forces you to write readable code.
Python that complies and is faster than C would be my dream language. I'd also like it to work directly with Unity and Flutter, replacing C# and Dart.
for i in range(0, m):
for j in range(0, n):
doInner()
doOuter()
I guess it would be easy to just write your own preprocessor that requires curly braces everywhere and removes them for the python interpreter, but eh.
In addition to your example, it backfires for things like multiline formulas (need to add parentheses or escapes) or lambdas.
Braces (or even 'end' like ruby) would be much more practical.
for i in range(0, n) {
for i in range(0, n) {
doInner()
}
doOuter()
}
For example :
for i in range(0, m) :
for j in range(0, n) :
... inner ...
... outer ...
Additionally, you probably wouldn't want to write nested for-loops anyway, but something like flattening the inner loop into a return value.
The problem usually isn’t …inner… being dedented, but …outer… being indented. Which usually won’t produce an error, since anything that could be in …outer… could also be in …inner… without error.
> Additionally, you probably wouldn’t want to write nested for-loops anyway, but something like flattening the inner loop into a return value.
Nested for-loops aren’t uncommon in real-world code. And, I…am not sure what you are saying here. Loops are imperative constructs, not return values.
I strongly prefer braces. But I also increasingly languages with a standard style and formatter. Go and Rust both do this well.
I love Python's indentation based blocks (in Python) but this is the biggest issue I've had with it. That and maybe occasionally when word wrapping.
I think Python's general terseness mitigates most of the reasons I might miss blocks in C or Java.
// just copied some code into this while block, oops I copied an extra space out front...
while (...) {
if (...) {
...}
}
// after Ctrl+S tied to autoformat
while (...) {
if (...) {
...
}
} for line in lines_to_paste:
paste(current_indent .. line)Making copy/paste bugs too hard discourages copy/pasting code rather than reading and rewriting, so, mixed bag there, IMO.
That was my experience in Python.
-> These statements need to be in this other loop.
-> Cut...paste
-> Reindent
-> Turn my brain to extreme paranoia, and double-check that I properly indented the first and last lines of the code I moved.
In braces-languages, it was just cut..paste..autoformat. If you missed a brace, you hear about it from the compiler.
Python is a great language in a lot of ways, but I caught myself making indentation mistakes twice a week. Significant indentation is, in my opinion, an error in language design.
Personally I've been way more annoyed when I've typed something up in the REPL and can't paste that over directly because of the >>> and ... but that's really a small tooling issue; a smarter editor would remove the REPL marks when pasting. Same for other REPL languages, most of them have PSn...
if other < mine:
update_comments(other, mine)
write_billing(other)
And yeah, pasting code into a repl would be easier too if I could rely on braces to convey scope.
Which one is more advanced
In three of five FAANG companies are using Nim, then it's probably a stable technology.
Are people really doing this copy from SO thing ? I always thought it was just a meme.
Your doing a PR review, assuming this dev is sloppy, would you rather it be in C++ or Python ?
I didn't like Python or Ruby at first, but now whenever I need to write a small tool, it's Python. Before Python I was using JavaScript, but I've fallen in love with how clean Python is
I'd rather it be in Python because I haven't touched C++ with any seriousness since the 1990s.
But not because of formatting (in either case, I’d prefer a standardized code formatter be in use, which gets you a lot farther than Python’s whitespace sensitivities alone.)
I really do want to program, until I retire because I really hate trying to manage people.
I prefer to write code the way I want/need then apply a formatter to unify my code with that of myself and colleagues.
So a formatter might opt to format on a best-effort basis even in the presence of syntax problems, but then there's the risk of creating different semantics than intended (once the syntax problem is fixed).
One example I can remember was an empty if or for loop body where everything beyond it was raised into its scope.
I'm taking about pycharm formatter specifically here. This does also happen with braces sometimes, but this would've simply been a syntax error in most other languages or just pulled up the single next line not the entire following code.
if foo:
bar
foo().then(f => {
return bar(f)
}).then(b => {
print(b)
})
foo().then(f => {
return bar(f)
}).then(b => {
print(b)
})
foo().then(bar).then(print)
Sure, but your problem code uses only single-expression lambdas with superfluous blocks (where, in fact, the lambdas are also superfluous), so its literally the worst possible thing to say that Python can't express as cleanly.
Also, single-expression lambdas can handle a lot, because expressions are easy to combine to arbitrary levels, it's only multistatement imperative blocks you can't do in a lambda, but Python has expression forms that cover lots of uses of imperative blocks already.
No, it doesn't. It's quite possible to write hard-to-read Python.
Python is a remarkable language because it's just so clean.
I don't get this indent issue all of you keep complaining about, just use a good IDE.
Dynamic typing and passing around *kwargs make this so trivial often the documentation doesn't even help and your IDE can't help you without executing the entire program.
One example is that booleans in Python are considered integers (0 and 1) for all purposes, including arithmetic: True+True produces 2 with no warning whatsoever. Even in C++, where this is also legal, you usually also get a warning.
And conversely, Python is much more flexible when it comes to interpreting other things as booleans: on top of implicitly treating null pointers and integers as false like C does, Python does the same to empty strings and even collections. Then there's the part where "and" and "or" don't just return true/false, but rather the value of one of the operands, which needs not be a boolean.
Sequence comprehensions are also a mighty tool for producing unreadable code if desired, especially if you nest them and/or use the conditional operator. This is more so in Python due to the unusually ordered syntax for both.
Here's a fizzbuzz code golf example that combines these techniques:
[f"{(not x % 3) * 'Fizz'}{(not x % 5) * 'Buzz'}" or x for x in range(1, 20)]I still can't get basic Rust examples to work and I've been programming for about 8 years.
I understand why rust is harder than python, as a systems language needs to accommodate for different needs.
I will admit using Python in a bigger application can be hell on earth since the type system is so loose.
Doing just about anything imperative at import-time makes it hard to reason about what happens when. Even experienced Python programmers can get tripped up by the import system's order of evaluation.
Even in the REPL, which is extremely annoying. To this date Python REPL examples tend to have this kind of artifical comments (quoting from [1]):
>>> class Weekday(Enum):
... MONDAY = 1
... TUESDAY = 2
... WEDNESDAY = 3
... THURSDAY = 4
... FRIDAY = 5
... SATURDAY = 6
... SUNDAY = 7
... #
... @classmethod
... def from_date(cls, date):
... return cls(date.isoweekday())
[1] https://docs.python.org/3.11/howto/enum.html#basic-enum-tuto...
Vi and emacs had ways to do soft tabs. It’s not like it was an editor problem.