The whitespace doesn’t bother me. Any IDE worth a damn will manage that for you. As for the type system, yeah, I strongly prefer static typing, but for simpler projects I can see the convenience of it.
My real issue with Python comes with managing a development environment when multiple developers are working on it. Dependency management in Python is a headache, and while in theory, virtual envs should help with synchronizing environments from machine to machine, I still find it endlessly fiddly with a bunch of things that can go wrong that are hard to diagnose.
Python is great for small scripts, proofs-of-concept, and such, but I wouldn’t write anything more heavy-duty than that in it.
You can totally write heavy duty things if you know what you’re doing: use type hints, static checkers, tests, etc. It just takes a bit more effort and care.
Because “more effort and care” in Python is still way less of a pain in the ass than the minimum enforced boilerplate necessary in most other languages.
I mean, is it? I personally haven’t found Python using much less boilerplate. It’s possible, but you end up with something inflexible that’s hard to maintain.
“Look, Python is way easier to use than other languages! Look how complex this easy task is in Python versus other languages like assembly and brainfuck!”
I’m not saying “do stuff in C it’s easier than Python”, but if I took e.g. C# then it’s also just two lines. That supports everything and is also faster than the Python implementation.
Nah it’s also a language matter.
People complain about Rusts complexity, meanwhile I complain about everything else in other languages, and am faster than in any other language, not necessarily because writing code is faster, but because I am able to just focus on writing code. I cannot tell that about other languages, because e.g. the packaging system is bad, or configuring an environment, or debugging stuff which a strong type-system would have caught already. Also IDE experience I think is the one thing that keeps me away from dynamic languages. Rust analyzer is so much better than anything else I’ve tried, and it keeps getting better (e.g. recently it was added to show whether a trait is object safe or not, and why it is not).
Another thing that is often missed when comparing static with dynamic languages is just performance, python heavily relies on stuff written in a system language, as soon as a hot-loop is written in python, things get bad…
Eh, it’s most definitely part of it, but the biggest time sink that I expect when working with Python is fixing the build system every two weeks on different devs’ PCs. I do imagine, if you eventually find a solution that works on most PCs that this workload will go down, but we had a substantial Python part in my previous project and over the course of the 1½ years that we worked on it, it really felt like we were making negative progress. Near the end of it, I couldn’t use PyCharm anymore, because I couldn’t figure out for the life of me, how to make it recognize the dependencies again.
Yeah, working on python projects professionally is always a nightmare of configuring env variables and trying to get your system to perfectly match the reference dev system. I find Node.js projects to often be the simplest and most pain free to setup, but even compiled languages like C# and Java are often easier to get up and going than python.
You, god, pretty much any Formatter and ide.
Black Formatter: “All leading tabs are converted to spaces, but tabs inside text are preserved.”
Vscode has a command to convert between the two,
and non-leading tabs are a simple replace/regex away from being converted.
If you mean unorthodox spacing, if you have code with like 7 leading spaces, then that’s a matter for a priest.
Haha: “A space breaks everything.” Fuck YES! Are you kidding me‽ It’s one of the best features!
Why? Because it’s so easy to see. In other languages you’ve got semicolons which are surprisingly difficult to notice when they’re missing. Depending on the situation (or if you’re just new to programming) you could spend a great deal of time troubleshooting your code only to find out that you’re missing a semicolon. It’s frustrating and it makes you feel stupid which is never a good thing for people who are new programming.
Types are in a different category altogether with seemingly infinite reasons why you’d want a feature-rich, low-level type system and also why you’d want to avoid that.
IMHO, the point of Python is to be a simple language that’s quick to write yet also very powerful and speedy when you need it to be (by taking advantage of modules written in C or better, Rust). If it had a complex type system I think it would significantly lower the value of the language. Just like how when I see an entire code repo using Pydantic and type hints everywhere it makes the code unnecessarily complex (just use type hints where it matters 🙄).
I’m not saying using type hints on everything is a terrible thing… I just think it makes the code harder to read which, IMHO defeats the point of using Python and adds a TON of complexity to the language.
The promise of type hints is that they’ll enable the interpreter to significantly speed up certain things and reduce memory utilization by orders of magnitude at some point in the future. When that happens I’ll definitely be reevaluating the situation but right now there doesn’t seem to be much point.
For reference, I’ve been coding in Python for about 18 years now and I’ve only ever encountered a bug (in production) that would’ve been prevented by type hints once. It was a long time ago, before I knew better and didn’t write unit tests.
These days when I’m working on code that requires type hints (by policy; not actual necessity) it feels like doing situps. Like, do I really need to add a string type hint to a function called, parse_log()? LOL!
I don’t mean this insultingly because lots of programming jobs don’t require this and for the ones that do we still tend to all start here, but in all honesty this sounds like it’s coming from someone who’s never worked on a large project maintained by multiple people over time.
First of all, the hysteria over semicolons is ridiculous when JavaScript, Typescript, C#, Java, Go, Swift, etc. etc. wil all automatically highlight missing semicolons, if not automatically insert them for you when paired with an IDE and standard linter. On top of that, JavaScript and Typescript do not require semicolons at all, but they are still used alongside braces, because they make your code more scannable, readable, and moveable.
Secondly, without type safety your code is no longer predictable or maintainable. If you’re working to quickly sketch out some new fangled logic for a research paper it’s one thing, if you need to write test code so that your codebase can be tested an infinite number of times by other coders and whatever CI/ CD pipelines to make sure that nothing’s broken, then all of the sudden you start seeing the value in strict typing.
Honestly, complaining about type safety adding “extra code” is a complaint that almost every coder has when they start out, before you eventually realize that all that “extra code” isn’t just boiler plate for no reason but is adding specificity, predictability, reusability, and maintainability to your code base.
When defining types looked like this it was one thing:
String name = newString("Charles Xavier");
But when it looks like this, there’s no reason not to use strong typing:
I started out with Visual Basic using the Variant type all the time, and even though I was usually just working on one-person projects it was a fucking disaster. You don’t even have to collaborate to see the virtues of strong typing.
Right, so this is the part where I get to sound like a smart ass, because I snuck a “tons of” into there.
What you do always need, is tests serving as a specification of the intended behavior, to document it for your team members and your future self.
But the thing that static typing is an alternative to, is integration tests for many code paths. For example, in dynamic languages you have no reassurance that a call to your database library still works, unless you have an integration test which actually calls into the database. Similarly, you hardly know whether the many error-handling code paths are working, unless you write tests for those, too.
In static languages, we don’t test this stuff outside of the specification-like integration tests, because the database library and the error handling library are already separately tested, and the type system ensures that we interface with them correctly.
without type safety your code is no longer predictable or maintainable
This sounds like someone who’s never worked on a large Python project with multiple developers. I’ve been doing this for almost two decades and we never encounter bugs because of mismatched types.
For reference, the most common bugs we encounter are related to exception handling. Either the code captured the exception and didn’t do the right thing (whatever that is) in specific situations or it didn’t capture the exception in the right place so it bubbles up waaaaay too high up the chain and we end up with super annoying troubleshooting where it’s difficult to reproduce or difficult to track down.
This sounds like someone who’s never worked on a large Python project with multiple developers. I’ve been doing this for almost two decades and we never encounter bugs because of mismatched types.
Have you worked on major projects in other languages in that time period to be able to compare and contrast?
The last two python projects I had to work on didn’t have bugs because of type issues, but it was much harder to come into the codebase and understand what was going on given that you didn’t have type information in many many places which forced you to go back and comb through the code instead.
because semicolons are tiny characters that oftenhave to be appended to the end of lines (precisely the worst place for them to be easily visible, since they’ll blend in with the previous character)
whitespace meanwhile is very easy to notice that it’s missing, as i’m sure you noticed when reading the above sentence.
It’s kinda funny that Godot’s custom language GDScript is, at least on a surface level, pythonic (no list comprehensions, context managers, decorators, etc, it’s mostly syntactical similarities). But type hints do make it run faster!
I was blessed to get to skip most of the old pains in python. I only had a handful of scripts that ever needed to be ported from 2 and they didn’t rely on any libraries. The ecosystem is easy to work with and I’m looking forward to working with Python for the foreseeable future
I have never once, in nearly 20 years of using python, encountered IndentationError. Until today actually. I tried to make it happen because I couldn’t remember the class name.
Pyright language server makes Typethon out of your Python at the cost of massive bugs and performance. I used to like it, until I got really sick of waiting about 10 seconds for a suggestion to appear when typing open() and really fucking sick of the entire server crashing after I type pow()
Type checking for python is not bad these days, just run pyright (or mypy, I would like to prefer the non MS solution, but we have found pyright much more rigorous) on your code. Yes obviously you can still get out of it with an ignore statement, and that might occasionally be necessary for some libraries, but if you enforce no errors in pre-commit or CI then it’s only a little worse than compile time.
Yes, I love rust and use it regularly, but it is suitable for totally different use cases than python. Have you worked on a python project using strict type checking enforced in CI? It really isn’t so bad.
I haven’t, but everytime I try python I want to quit it so quickly because of the messed up packaging system and more importantly IDE experience (and I don’t think unless you are extremely disciplined with type annotations, that you’re getting even close to rust-analyzers performance). I enjoy just exploring dependencies with go to definition, and the trust I can have in the type system.
I’m swearing everyday in my job about typescript, which is just javascript with leaky and unnecessary complex type annotations. So yeah I even consider typescript bad (and I doubt that python is better with type-checking).
In my experience which is pretty extensive with python but only moderate with typescript I’d say it’s probably better, easier to work with and offers a similar level of flexibility.
Not sure what you mean by performance but it’s easy to be disciplined when you can’t commit something that isn’t fully annotated. I feel like I can trust it fairly well, except for rare occasions where external library code is wrongly annotated and I have to put some ugly shim in.
Afaik you can just go to definition in literally any language, typing or no.
I’m in total agreement about the packaging though, it sucks.
Like raw runtime performance, if I write the code in python, it’s ~ 100x slower than in Rust. You often get away with dumber stuff in Rust as the compiler is able to optimize it well. With python you would have to write your native bindings either in Rust/C or C++. So why not straight use Rust (as the other choices aren’t sa(f/n)e at this point anymore).
Afaik you can just go to definition in literally any language, typing or no.
No you can’t, at least not in the same way that a static type-system allows.
As dynamically-typed programs are evaluated on runtime, so you often don’t know at the time while coding what is run.
In untyped/dynamically typed languages you often use heuristics to jump into stuff, which is just less precise.
There’s more to this, but I think you get what I mean, when you programmed more intensively with static generics in Rust (compared to something similar in say javascript or python without types), IDE experience is just more precise and correct (and more fun).
Lmao, bruh. How do people keep praising a language where messing up a space breaks everything and there is no real type system?
The whitespace doesn’t bother me. Any IDE worth a damn will manage that for you. As for the type system, yeah, I strongly prefer static typing, but for simpler projects I can see the convenience of it.
My real issue with Python comes with managing a development environment when multiple developers are working on it. Dependency management in Python is a headache, and while in theory, virtual envs should help with synchronizing environments from machine to machine, I still find it endlessly fiddly with a bunch of things that can go wrong that are hard to diagnose.
Python is great for small scripts, proofs-of-concept, and such, but I wouldn’t write anything more heavy-duty than that in it.
You can totally write heavy duty things if you know what you’re doing: use type hints, static checkers, tests, etc. It just takes a bit more effort and care.
But why would I use something that takes more effort and care?
I’m sure you’re right and it’s possible, but if I don’t have to fix another python project at work I’ll be in heaven.
Because “more effort and care” in Python is still way less of a pain in the ass than the minimum enforced boilerplate necessary in most other languages.
I mean, is it? I personally haven’t found Python using much less boilerplate. It’s possible, but you end up with something inflexible that’s hard to maintain.
Implement a basic socket connection in C (20 lines of manipulating
struct sockaddrs and such), then do the same in Python (2 lines).And then go back and make the C version support IPV6, because your initial implementation didn’t.
Or use a statically typed language that’s actually modern instead of C
“Look, Python is way easier to use than other languages! Look how complex this easy task is in Python versus other languages like assembly and brainfuck!”
I’m not saying “do stuff in C it’s easier than Python”, but if I took e.g. C# then it’s also just two lines. That supports everything and is also faster than the Python implementation.
it’s more effort and care compared to a throwaway script, not necessarily compared to other languages
Personally, my estimate doubles when we’re asked to implement something in Python…
That’s a proficiency matter. Python is the language I can get something done the fastest today, but 6 years ago that would be Java or even JS for me.
Nah it’s also a language matter. People complain about Rusts complexity, meanwhile I complain about everything else in other languages, and am faster than in any other language, not necessarily because writing code is faster, but because I am able to just focus on writing code. I cannot tell that about other languages, because e.g. the packaging system is bad, or configuring an environment, or debugging stuff which a strong type-system would have caught already. Also IDE experience I think is the one thing that keeps me away from dynamic languages. Rust analyzer is so much better than anything else I’ve tried, and it keeps getting better (e.g. recently it was added to show whether a trait is object safe or not, and why it is not).
Another thing that is often missed when comparing static with dynamic languages is just performance, python heavily relies on stuff written in a system language, as soon as a hot-loop is written in python, things get bad…
Eh, it’s most definitely part of it, but the biggest time sink that I expect when working with Python is fixing the build system every two weeks on different devs’ PCs. I do imagine, if you eventually find a solution that works on most PCs that this workload will go down, but we had a substantial Python part in my previous project and over the course of the 1½ years that we worked on it, it really felt like we were making negative progress. Near the end of it, I couldn’t use PyCharm anymore, because I couldn’t figure out for the life of me, how to make it recognize the dependencies again.
Yeah, working on python projects professionally is always a nightmare of configuring env variables and trying to get your system to perfectly match the reference dev system. I find Node.js projects to often be the simplest and most pain free to setup, but even compiled languages like C# and Java are often easier to get up and going than python.
Yeah in like 10% of cases. I’m copying something from a pdf my prof gave. The only ones able fix spacing now are me and God
You, god, pretty much any Formatter and ide. Black Formatter: “All leading tabs are converted to spaces, but tabs inside text are preserved.” Vscode has a command to convert between the two, and non-leading tabs are a simple replace/regex away from being converted. If you mean unorthodox spacing, if you have code with like 7 leading spaces, then that’s a matter for a priest.
Haha: “A space breaks everything.” Fuck YES! Are you kidding me‽ It’s one of the best features!
Why? Because it’s so easy to see. In other languages you’ve got semicolons which are surprisingly difficult to notice when they’re missing. Depending on the situation (or if you’re just new to programming) you could spend a great deal of time troubleshooting your code only to find out that you’re missing a semicolon. It’s frustrating and it makes you feel stupid which is never a good thing for people who are new programming.
Types are in a different category altogether with seemingly infinite reasons why you’d want a feature-rich, low-level type system and also why you’d want to avoid that.
IMHO, the point of Python is to be a simple language that’s quick to write yet also very powerful and speedy when you need it to be (by taking advantage of modules written in C or better, Rust). If it had a complex type system I think it would significantly lower the value of the language. Just like how when I see an entire code repo using Pydantic and type hints everywhere it makes the code unnecessarily complex (just use type hints where it matters 🙄).
I’m not saying using type hints on everything is a terrible thing… I just think it makes the code harder to read which, IMHO defeats the point of using Python and adds a TON of complexity to the language.
The promise of type hints is that they’ll enable the interpreter to significantly speed up certain things and reduce memory utilization by orders of magnitude at some point in the future. When that happens I’ll definitely be reevaluating the situation but right now there doesn’t seem to be much point.
For reference, I’ve been coding in Python for about 18 years now and I’ve only ever encountered a bug (in production) that would’ve been prevented by type hints once. It was a long time ago, before I knew better and didn’t write unit tests.
These days when I’m working on code that requires type hints (by policy; not actual necessity) it feels like doing situps. Like, do I really need to add a string type hint to a function called,
parse_log()? LOL!I don’t mean this insultingly because lots of programming jobs don’t require this and for the ones that do we still tend to all start here, but in all honesty this sounds like it’s coming from someone who’s never worked on a large project maintained by multiple people over time.
First of all, the hysteria over semicolons is ridiculous when JavaScript, Typescript, C#, Java, Go, Swift, etc. etc. wil all automatically highlight missing semicolons, if not automatically insert them for you when paired with an IDE and standard linter. On top of that, JavaScript and Typescript do not require semicolons at all, but they are still used alongside braces, because they make your code more scannable, readable, and moveable.
Secondly, without type safety your code is no longer predictable or maintainable. If you’re working to quickly sketch out some new fangled logic for a research paper it’s one thing, if you need to write test code so that your codebase can be tested an infinite number of times by other coders and whatever CI/ CD pipelines to make sure that nothing’s broken, then all of the sudden you start seeing the value in strict typing.
Honestly, complaining about type safety adding “extra code” is a complaint that almost every coder has when they start out, before you eventually realize that all that “extra code” isn’t just boiler plate for no reason but is adding specificity, predictability, reusability, and maintainability to your code base.
When defining types looked like this it was one thing:
String name = new String("Charles Xavier");But when it looks like this, there’s no reason not to use strong typing:
const name = "Charles Xavier";Anyone who thinks a strong type system is a drawback has never worked on any real project where you actually have to collaborate with others.
I started out with Visual Basic using the Variant type all the time, and even though I was usually just working on one-person projects it was a fucking disaster. You don’t even have to collaborate to see the virtues of strong typing.
Yeah, the alternative to static typing is to write tons of unit tests, which definitely adds a lot more code to your codebase.
That’s not an alternative, you always need tests
Right, so this is the part where I get to sound like a smart ass, because I snuck a “tons of” into there.
What you do always need, is tests serving as a specification of the intended behavior, to document it for your team members and your future self.
But the thing that static typing is an alternative to, is integration tests for many code paths. For example, in dynamic languages you have no reassurance that a call to your database library still works, unless you have an integration test which actually calls into the database. Similarly, you hardly know whether the many error-handling code paths are working, unless you write tests for those, too.
In static languages, we don’t test this stuff outside of the specification-like integration tests, because the database library and the error handling library are already separately tested, and the type system ensures that we interface with them correctly.
This sounds like someone who’s never worked on a large Python project with multiple developers. I’ve been doing this for almost two decades and we never encounter bugs because of mismatched types.
For reference, the most common bugs we encounter are related to exception handling. Either the code captured the exception and didn’t do the right thing (whatever that is) in specific situations or it didn’t capture the exception in the right place so it bubbles up waaaaay too high up the chain and we end up with super annoying troubleshooting where it’s difficult to reproduce or difficult to track down.
Also, testing is completely orthogonal to types.
Have you worked on major projects in other languages in that time period to be able to compare and contrast?
The last two python projects I had to work on didn’t have bugs because of type issues, but it was much harder to come into the codebase and understand what was going on given that you didn’t have type information in many many places which forced you to go back and comb through the code instead.
So the code did have type hints, just not consistently. Sounds like bad code.
What are you writing your code in? Windows notepad? How the hell do you not see the semicolon missing?
because semicolons are tiny characters that oftenhave to be appended to the end of lines (precisely the worst place for them to be easily visible, since they’ll blend in with the previous character)
whitespace meanwhile is very easy to notice that it’s missing, as i’m sure you noticed when reading the above sentence.
In both cases, you press compile and the compiler goes “you missed a whitespace/semicolon HERE”
It’s kinda funny that Godot’s custom language GDScript is, at least on a surface level, pythonic (no list comprehensions, context managers, decorators, etc, it’s mostly syntactical similarities). But type hints do make it run faster!
I was blessed to get to skip most of the old pains in python. I only had a handful of scripts that ever needed to be ported from 2 and they didn’t rely on any libraries. The ecosystem is easy to work with and I’m looking forward to working with Python for the foreseeable future
Exactly! I’ve wasted more time hunting missing semicolons in languages that use them, than fixing wrong indentation in Python.
Not even the worst. This function declarations with separations between positional and enum variables… Or the infamous global…
I have never once, in nearly 20 years of using python, encountered IndentationError. Until today actually. I tried to make it happen because I couldn’t remember the class name.
A statically typed Python would be my dream programming language.
Can someone please make Typethon?
Pyright language server makes Typethon out of your Python at the cost of massive bugs and performance. I used to like it, until I got really sick of waiting about 10 seconds for a suggestion to appear when typing open() and really fucking sick of the entire server crashing after I type pow()
Type checking for python is not bad these days, just run pyright (or mypy, I would like to prefer the non MS solution, but we have found pyright much more rigorous) on your code. Yes obviously you can still get out of it with an ignore statement, and that might occasionally be necessary for some libraries, but if you enforce no errors in pre-commit or CI then it’s only a little worse than compile time.
because it’s easy to use. I don’t like strangling my code because it’s screaming about semicolons again
To me it’s as natural as using periods
Messing up some character breaks everything in any language, skill issue
What does “real” mean? It’s pretty robust these days.
Have you tried Rust?
Yes, I love rust and use it regularly, but it is suitable for totally different use cases than python. Have you worked on a python project using strict type checking enforced in CI? It really isn’t so bad.
I haven’t, but everytime I try python I want to quit it so quickly because of the messed up packaging system and more importantly IDE experience (and I don’t think unless you are extremely disciplined with type annotations, that you’re getting even close to rust-analyzers performance). I enjoy just exploring dependencies with go to definition, and the trust I can have in the type system.
I’m swearing everyday in my job about typescript, which is just javascript with leaky and unnecessary complex type annotations. So yeah I even consider typescript bad (and I doubt that python is better with type-checking).
In my experience which is pretty extensive with python but only moderate with typescript I’d say it’s probably better, easier to work with and offers a similar level of flexibility.
Not sure what you mean by performance but it’s easy to be disciplined when you can’t commit something that isn’t fully annotated. I feel like I can trust it fairly well, except for rare occasions where external library code is wrongly annotated and I have to put some ugly shim in.
Afaik you can just go to definition in literally any language, typing or no.
I’m in total agreement about the packaging though, it sucks.
Like raw runtime performance, if I write the code in python, it’s ~ 100x slower than in Rust. You often get away with dumber stuff in Rust as the compiler is able to optimize it well. With python you would have to write your native bindings either in Rust/C or C++. So why not straight use Rust (as the other choices aren’t sa(f/n)e at this point anymore).
No you can’t, at least not in the same way that a static type-system allows. As dynamically-typed programs are evaluated on runtime, so you often don’t know at the time while coding what is run. In untyped/dynamically typed languages you often use heuristics to jump into stuff, which is just less precise.
There’s more to this, but I think you get what I mean, when you programmed more intensively with static generics in Rust (compared to something similar in say javascript or python without types), IDE experience is just more precise and correct (and more fun).