7 ms·

Why are people so enthused about Python syntax? Some problems off the top of my head: - The lack of new variable declaration keyword makes scopes less explici

Why are people so enthused about Python syntax? Some problems off the top of my head: - The lack of new variable declaration keyword makes scopes less explicit. nonlocal is not simpler in the large than `let x = ...` - The lack of multi-line lambdas is very limiting for anyone coming from JS, C#, Rust, Kotlin... heck even Java - The ternary operator (... if ... else ...) is needlessly different for other mainstream languages

mmoskal 3y ago
I agree (and would add explicit self argument, the fact that all your imports are exported and more) I think the point here is to reuse the Python ecosystem especially in ML.
kstrauser 3y ago
Throwing this out there: - I’ve used nonlocal 0 times ever. - I get that people miss them, but you can define nested functions if you want. Nameless functions are nifty, but I’ve never lost sleep over putting `def foo` in front of what would’ve been a lambda in other languages. - I kinda like the Python ternaries. Preferences are A-OK, and I’m not saying you’re wrong. Just chiming in that the things you mention aren’t universally disliked.
- chombier 3y ago
  > I’ve used nonlocal 0 times ever. Same here, but I got bitten by weird scoping rules quite a few times. Separating variable definition from assignment (e.g. with 'let') would probably help a lot in this case.
bookmark1231 3y ago
I concede about multi line lambdas but far too many languages take a “syntax is bikeshedding and unimportant” approach to language design. New languages are still using “&&” and “||” as if it’s 1975 and syntax highlighting doesn’t exist. Looking at C++, Rust and even Zig code is unnecessarily complicated for someone who isn’t intimately familiar with the syntax meanwhile for the most part anyone can understand Python syntax (well, at least Python syntax that doesn’t abuse decorators and obscure dunder overloads)
- Shikadi 3y ago
  I personally find && and || easier to read than "and" and "or" because instead of using words to separate words, it's symbols separating words. Sure syntax highlighting helps, but I don't think there's an objective choice here
- lambda_garden 3y ago
  The issues I raised were pretty concrete, and not merely "this symbol is better than that symbol"
- alpaca128 3y ago
  > New languages are still using “&&” and “||” as if it’s 1975 Because it's consistent and people don't want to relearn minor details each time they switch. And Python has a lot of those little differences. Though the "and" and "or" keywords are among the few things I actually like. > meanwhile for the most part anyone can understand Python syntax What matters more to me is how the syntax works in the long term. I have no trouble reading and writing a lot of Rust code, but even after years with Python I still can't remember the difference between "[-1:]", "[1:]", "[:1]" etc for slicing lists/strings. Recursive list comprehensions with their lack of parentheses are unreadable to me to this day (e.g.: `[item for sublist in list_of_lists for item in sublist]`). Python is very easy and quick to pick up, really productive for prototyping, but I don't consider its syntax to be its big advantage.
  - mathisfun123 3y ago
    the lady doth protest a bit too much me thinks > Recursive list comprehensions with their lack of parentheses are unreadable to me to this day (e.g.: `[item for sublist in list_of_lists for item in sublist]`) 1. there's no recursion here 2. it's literally just a double nested loop flattened (i.e. exactly matching the semantics) to be on the same line instead of indented and on two lines: [item for sublist in list_of_lists for item in sublist] is the same as for sublist in list_of_lists: for item in sublist: item like why would you need parens when you know the for starts the next nested loop.
vosper 3y ago
Most AI/ML work is done in Python. It’s very compute intensive and there’s value in making it faster. There’s also a lot money sloshing around for doing AI stuff. Therefore there might be money for Modular in making a Python-compatible thing to make AI stuff faster. In other words, I don’t think this is about the syntax at all
IshKebab 3y ago
Yeah it was pretty good in the Python 2 era but definitely not something to copy now. Another big issue is that it's not expression based. For example you can't do `foo = (yield a).b` you have to do `x = yield a; foo = x.b`. Having a special syntax for the expression version of if else is another example as you said. I was disappointed to discover Dart made the same mistake there. There's a totally different syntax for match statements and match expressions. Why?? Ok maybe backwards compatibility.. but still. They fixed nullability properly and it wasn't too bad.
- ptx 3y ago
  > For example you can't do `foo = (yield a).b` you have to do `x = yield a; foo = x.b`. The first snippet actually works fine. Yield expressions were introduced with PEP 342 in Python 2.5.
  - IshKebab 3y ago
    Ah I misremembered. I was actually trying to do this x = [yield a for a in b] Which yields (heh) an `Invalid Syntax` error. Thanks for the link to that PEP though - turns out the answer is that you almost always have to parenthesise it. x = [(yield a) for a in b] > SyntaxError: yield inside list comprehension Ok my original point stands.
- bafe 3y ago
  The fact python is statement-heavy to me shows that it was originally conceived in another age. It is really annoying after you use expression oriented languages
rvrs 3y ago
I'd like to add that forced whitespace is infuriating. It's annoying to navigate (in vim I can't easily go to the beginning/end of a code block like I can in languages where scopes are defined by braces), and it's annoying to read because it's not always intuitive how deep I am within nested scopes
- kstrauser 3y ago
  That’s an issue with your vim setup. You can absolutely navigate Python code in vim.
  - rvrs 3y ago
    Got any recommendations? Also, I didn't say it was impossible to navigate, but it is cumbersome and annoying. Forced whitespace sucks.
    - SirensOfTitan 3y ago
      emacs has a bunch of packages for treesitter based ast motions—might be worth seeing if vim has any analogues.
- frodowtf 3y ago
  > ... it's not intuitive how deep I am within nested scopes The ONLY piece of information that is available to you regardless of how deep you are into a function is INDENTATION. Your curly braces won't help you. Besides that, you should seriously reconsider your coding style if this is an actual problem for you.
  - rvrs 3y ago
    >The ONLY piece of information that is available to you regardless of how deep you are into a function is INDENTATION. ...No? It sounds like you write very long, messy code blocks. Consider the following example, I will write a nested loop in 2 languages: In Python: for _ in range(10): for _ in range(10): print("Inner") print("Outer") Here's something similar in JS: for (const _ of foo) { for (const _ of foo) { console.log("Inner"); } console.log("Outer"); } In isolation, while I'm writing this comment, I would say these code blocks are equally easy to parse. In the context of frantically debugging, scurrying around a file, I may (and have!) missed the indentation difference in the Python example. Curly braces allow me to have 3 visual indicators that a block is finished: a visual text object (the brace itself), an extra line separator (the closing brace lives on its own line), and indentation. In Python, I only have one of those things (just indentation). I can have 2 (indentation + line sparation) if I always insert a newline before `print("Outer")`, but empty lines can get deleted and I may forget to include them as I write code. You'd need to configure a linter to guarantee the line separation indicator in a language that delimits scopes by whitespace.
deleted 3y ago
[deleted]
JodieBenitez 3y ago
Tiny details that are not relevant in the big picture though.
SirensOfTitan 3y ago
Yeah, I highly dislike working with python, everything is special syntax or different for no reason. In addition to what you mentioned: * try catch is different keywords from virtually all other languages. * walrus tusks, the general order in list comprehensions generally where bindings come after expression * typing is awful, unsound in a lot of cases, there’s a ton of special non straightforward plugins in mypy. This is partially better in pyright but not considerably. * package management is silly. Poetry is like a poor imitation of npm. Venvs are a pain in the butt. … all of this for a pretty slow language.
- pushfoo 3y ago
  > typing is awful, unsound in a lot of cases tl;dr: 1. This is my biggest issue with Python. 2. Are there any tolerable solutions you've found? 3. Are there any non-Python languages you'd recommend? The root of Python's typing issues seems to be ad-hoc syntax recycling as a stand-in for a thoroughly planned type system. Understandably, Guido and others advise using Protocol types to make up for earlier design decisions. It sort of works, but: 1. It's effectively an unspoken deprecation for parts of the standard library 2. Current design choices create new problems 3. It still doesn't reliably prevent runtime errors Things break down further as you move beyond the built-ins: 1. Pydantic and other tools come with their own problems 2. Ugly things happen at boundary lines in APIs (ctypes vs OOP) 3. All of these get even worse as Sphinx gets involved The last two items came up in a recent PR discussion. The other commenter's point seemed correct: simple, specific, and rigid types prevent problems. But then why should we have Generic and Union at all? I'm still going to use Python when necessary, but it makes the grass look very green near languages like OCaml and Elm. If Rider can make .NET's packaging tolerable, maybe F# would be good too. Are there any others you'd suggest?
- dragonwriter 3y ago
  > try catch is different keywords from virtually all other languages Python : try/except/finally/else C# : try/catch/finally (no equivalent of “else”) VB.net : try/catch/finally (no equivalent of “else”) JavaScript : try/catch/finally (no equivalent of “else”) Java : try/catch/finally (no equivalent of “else”) Ruby: begin/rescue/ensure (no equivalent of “else”) C++: try/catch (no equivalent of “finally” or “else”) Python’s try/except/finally/else seem to use nearly the same keywords as many other popular languages (Ruby is an oddball here, using similar semantics with different keywords), except that it uses “except” in place of “catch”, and “else” is a unique feature, and C++ lacks “finally”. EDIT: The above has been edited throughout to correct an initial thinko that had Python using the common “catch” instead of “except”, which I really can’t explain because I've been wading throw Python exception handling code a lot recently.
qaq 3y ago
" The lack of new variable declaration keyword makes scopes less explicit" You can declare variables (such as x in the above main() function) with var to create a mutable value, or with let to create an immutable value.

mmoskal 3y ago

I agree (and would add explicit self argument, the fact that all your imports are exported and more) I think the point here is to reuse the Python ecosystem especially in ML.

kstrauser 3y ago

Throwing this out there: - I’ve used nonlocal 0 times ever. - I get that people miss them, but you can define nested functions if you want. Nameless functions are nifty, but I’ve never lost sleep over putting `def foo` in front of what would’ve been a lambda in other languages. - I kinda like the Python ternaries. Preferences are A-OK, and I’m not saying you’re wrong. Just chiming in that the things you mention aren’t universally disliked.

chombier 3y ago
> I’ve used nonlocal 0 times ever. Same here, but I got bitten by weird scoping rules quite a few times. Separating variable definition from assignment (e.g. with 'let') would probably help a lot in this case.

bookmark1231 3y ago

I concede about multi line lambdas but far too many languages take a “syntax is bikeshedding and unimportant” approach to language design. New languages are still using “&&” and “||” as if it’s 1975 and syntax highlighting doesn’t exist. Looking at C++, Rust and even Zig code is unnecessarily complicated for someone who isn’t intimately familiar with the syntax meanwhile for the most part anyone can understand Python syntax (well, at least Python syntax that doesn’t abuse decorators and obscure dunder overloads)

Shikadi 3y ago
I personally find && and || easier to read than "and" and "or" because instead of using words to separate words, it's symbols separating words. Sure syntax highlighting helps, but I don't think there's an objective choice here
lambda_garden 3y ago
The issues I raised were pretty concrete, and not merely "this symbol is better than that symbol"
alpaca128 3y ago
> New languages are still using “&&” and “||” as if it’s 1975 Because it's consistent and people don't want to relearn minor details each time they switch. And Python has a lot of those little differences. Though the "and" and "or" keywords are among the few things I actually like. > meanwhile for the most part anyone can understand Python syntax What matters more to me is how the syntax works in the long term. I have no trouble reading and writing a lot of Rust code, but even after years with Python I still can't remember the difference between "[-1:]", "[1:]", "[:1]" etc for slicing lists/strings. Recursive list comprehensions with their lack of parentheses are unreadable to me to this day (e.g.: `[item for sublist in list_of_lists for item in sublist]`). Python is very easy and quick to pick up, really productive for prototyping, but I don't consider its syntax to be its big advantage.
- mathisfun123 3y ago
  the lady doth protest a bit too much me thinks > Recursive list comprehensions with their lack of parentheses are unreadable to me to this day (e.g.: `[item for sublist in list_of_lists for item in sublist]`) 1. there's no recursion here 2. it's literally just a double nested loop flattened (i.e. exactly matching the semantics) to be on the same line instead of indented and on two lines: [item for sublist in list_of_lists for item in sublist] is the same as for sublist in list_of_lists: for item in sublist: item like why would you need parens when you know the for starts the next nested loop.

vosper 3y ago

Most AI/ML work is done in Python. It’s very compute intensive and there’s value in making it faster. There’s also a lot money sloshing around for doing AI stuff. Therefore there might be money for Modular in making a Python-compatible thing to make AI stuff faster. In other words, I don’t think this is about the syntax at all

IshKebab 3y ago

Yeah it was pretty good in the Python 2 era but definitely not something to copy now. Another big issue is that it's not expression based. For example you can't do `foo = (yield a).b` you have to do `x = yield a; foo = x.b`. Having a special syntax for the expression version of if else is another example as you said. I was disappointed to discover Dart made the same mistake there. There's a totally different syntax for match statements and match expressions. Why?? Ok maybe backwards compatibility.. but still. They fixed nullability properly and it wasn't too bad.

ptx 3y ago
> For example you can't do `foo = (yield a).b` you have to do `x = yield a; foo = x.b`. The first snippet actually works fine. Yield expressions were introduced with PEP 342 in Python 2.5.
- IshKebab 3y ago
  Ah I misremembered. I was actually trying to do this x = [yield a for a in b] Which yields (heh) an `Invalid Syntax` error. Thanks for the link to that PEP though - turns out the answer is that you almost always have to parenthesise it. x = [(yield a) for a in b] > SyntaxError: yield inside list comprehension Ok my original point stands.
bafe 3y ago
The fact python is statement-heavy to me shows that it was originally conceived in another age. It is really annoying after you use expression oriented languages

rvrs 3y ago

I'd like to add that forced whitespace is infuriating. It's annoying to navigate (in vim I can't easily go to the beginning/end of a code block like I can in languages where scopes are defined by braces), and it's annoying to read because it's not always intuitive how deep I am within nested scopes

kstrauser 3y ago
That’s an issue with your vim setup. You can absolutely navigate Python code in vim.
- rvrs 3y ago
  Got any recommendations? Also, I didn't say it was impossible to navigate, but it is cumbersome and annoying. Forced whitespace sucks.
  - SirensOfTitan 3y ago
    emacs has a bunch of packages for treesitter based ast motions—might be worth seeing if vim has any analogues.
frodowtf 3y ago
> ... it's not intuitive how deep I am within nested scopes The ONLY piece of information that is available to you regardless of how deep you are into a function is INDENTATION. Your curly braces won't help you. Besides that, you should seriously reconsider your coding style if this is an actual problem for you.
- rvrs 3y ago
  >The ONLY piece of information that is available to you regardless of how deep you are into a function is INDENTATION. ...No? It sounds like you write very long, messy code blocks. Consider the following example, I will write a nested loop in 2 languages: In Python: for _ in range(10): for _ in range(10): print("Inner") print("Outer") Here's something similar in JS: for (const _ of foo) { for (const _ of foo) { console.log("Inner"); } console.log("Outer"); } In isolation, while I'm writing this comment, I would say these code blocks are equally easy to parse. In the context of frantically debugging, scurrying around a file, I may (and have!) missed the indentation difference in the Python example. Curly braces allow me to have 3 visual indicators that a block is finished: a visual text object (the brace itself), an extra line separator (the closing brace lives on its own line), and indentation. In Python, I only have one of those things (just indentation). I can have 2 (indentation + line sparation) if I always insert a newline before `print("Outer")`, but empty lines can get deleted and I may forget to include them as I write code. You'd need to configure a linter to guarantee the line separation indicator in a language that delimits scopes by whitespace.

deleted 3y ago

[deleted]

JodieBenitez 3y ago

Tiny details that are not relevant in the big picture though.

SirensOfTitan 3y ago

Yeah, I highly dislike working with python, everything is special syntax or different for no reason. In addition to what you mentioned: * try catch is different keywords from virtually all other languages. * walrus tusks, the general order in list comprehensions generally where bindings come after expression * typing is awful, unsound in a lot of cases, there’s a ton of special non straightforward plugins in mypy. This is partially better in pyright but not considerably. * package management is silly. Poetry is like a poor imitation of npm. Venvs are a pain in the butt. … all of this for a pretty slow language.

pushfoo 3y ago
> typing is awful, unsound in a lot of cases tl;dr: 1. This is my biggest issue with Python. 2. Are there any tolerable solutions you've found? 3. Are there any non-Python languages you'd recommend? The root of Python's typing issues seems to be ad-hoc syntax recycling as a stand-in for a thoroughly planned type system. Understandably, Guido and others advise using Protocol types to make up for earlier design decisions. It sort of works, but: 1. It's effectively an unspoken deprecation for parts of the standard library 2. Current design choices create new problems 3. It still doesn't reliably prevent runtime errors Things break down further as you move beyond the built-ins: 1. Pydantic and other tools come with their own problems 2. Ugly things happen at boundary lines in APIs (ctypes vs OOP) 3. All of these get even worse as Sphinx gets involved The last two items came up in a recent PR discussion. The other commenter's point seemed correct: simple, specific, and rigid types prevent problems. But then why should we have Generic and Union at all? I'm still going to use Python when necessary, but it makes the grass look very green near languages like OCaml and Elm. If Rider can make .NET's packaging tolerable, maybe F# would be good too. Are there any others you'd suggest?
dragonwriter 3y ago
> try catch is different keywords from virtually all other languages Python : try/except/finally/else C# : try/catch/finally (no equivalent of “else”) VB.net : try/catch/finally (no equivalent of “else”) JavaScript : try/catch/finally (no equivalent of “else”) Java : try/catch/finally (no equivalent of “else”) Ruby: begin/rescue/ensure (no equivalent of “else”) C++: try/catch (no equivalent of “finally” or “else”) Python’s try/except/finally/else seem to use nearly the same keywords as many other popular languages (Ruby is an oddball here, using similar semantics with different keywords), except that it uses “except” in place of “catch”, and “else” is a unique feature, and C++ lacks “finally”. EDIT: The above has been edited throughout to correct an initial thinko that had Python using the common “catch” instead of “except”, which I really can’t explain because I've been wading throw Python exception handling code a lot recently.

qaq 3y ago

" The lack of new variable declaration keyword makes scopes less explicit" You can declare variables (such as x in the above main() function) with var to create a mutable value, or with let to create an immutable value.