3 ms·

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 differen

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.

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.
- SirensOfTitan 3y ago
  Python uses try/except and instead of throw uses raise.
- robertlagrant 3y ago
  Python is try/except, not try/catch. I don't think it matters in the least that it's different, but it is different.
- graypegg 3y ago
  Ruby does have a good reason to be oddball IMO. begin isn't always required. When inside a method, module, class, or do...end block definition (read: most of the time), you're able to use the rescue keyword solo. Anything raising an exception in the method above the rescue keyword will be caught. It can also be used postfixed to a statement that might raise an exception. Ruby is oddball here because it's subtly different. def a_method @value = dangerous_method_call rescue "default value in case of exception" do_something_else @value rescue puts "an error, oh no" end
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.

SirensOfTitan 3y ago
Python uses try/except and instead of throw uses raise.
robertlagrant 3y ago
Python is try/except, not try/catch. I don't think it matters in the least that it's different, but it is different.
graypegg 3y ago
Ruby does have a good reason to be oddball IMO. begin isn't always required. When inside a method, module, class, or do...end block definition (read: most of the time), you're able to use the rescue keyword solo. Anything raising an exception in the method above the rescue keyword will be caught. It can also be used postfixed to a statement that might raise an exception. Ruby is oddball here because it's subtly different. def a_method @value = dangerous_method_call rescue "default value in case of exception" do_something_else @value rescue puts "an error, oh no" end

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?