My indirect experience with python is that it is slow as hell. Anytime I install an app that includes python it lags 15-30 minutes on that step. Anytime I’m asked to install something with conda it takes 30 minutes to an hour.
I’m sure that is just due to environmental and implementation issues, but the Java fans say the same thing…
It’s near-universally regarded as a great prototyping language. For prod you should use something big-boy, like Java, or if you want to get fancy, Rust.
The “Big Boys” use tests to gauge when code is production ready, they don’t rely on a typing system and call it a day. I’ve seen monoliths made out of bash serve their purpose for years without a glitch, thanks to tests.
That feels like a packaging issue, which would be a problem specific to the developer of that app, not Python. For the most part, pip packages install basically instantaneously.
Yeah conda is slow af, but you can change the env solver which makes things much faster and there’s also mamba/miniconda which I haven’t tried but is supposedly much faster
With things like wsl, conda has also become less useful. Anaconda is terrible software and the need for conda managed packages is mostly lost outside of the windows OS in my opinion.
can you really call python programming though? The reason why python is so quick to write is because its so-called libraries are pre-compiled C programs. so you’re not writing new programs, you’re scripting existing ones.
But there are still if, while, function definitions, etc. in scripting languages. It doesn’t seem to me that different than even programming in assembler. In Assembler you also call subroutines, etc. and in every other language you also call functions from libraries.
The same is true for JVM bytecode, and C operations really are just aliases for ASM operations, and ASM (sometimes) is just aliases for microcode operations
Some languages are just worse to work with. like JavaScript. Console.log is like sure I’ll log your object but I’ll tell you what it is now, not what it was when you logged it.
Fwiw, Javascript’s object logging is a feature I often miss in other languages. If you just want to log the string, use formatted strings or just log obj+“” like you would need to do in every other language. Or even better, log a copy, like you probably wanted to do, with {…obj}.
I have many gripes with Javascript, but the logging API is pretty solid.
I’d just like to highlight what you mention below: Logging it as an object allows you to inspect it in the browser console, presumably with some JSON tree representation, rather than just a dumb string.
I’ve never had a complaint about logging stuff in python. It generally does what I expect.
“Create a copy of your object and print that” is what I ended up doing, but I don’t think most people would say that’s intuitive. I expect if i print something at a particular time, I get what it is at that point in time.
Javascript passes objects by reference in most cases. Passing logging objects by copy would actually be an anomaly within the language. The only unexpected part is that the browser console doesn’t toString your objects instantly (for performance reasons mostly), but the same happens in other frameworks for other languages (though often with less latency, milliseconds most of the time).
As I’ve personally experienced, this can make debugging concurrency issues real fun! Pre-composing your log messages as a string (within the same critical section) will prevent quite a few weird edge cases.
The Python console doesn’t allow you to expand and dig deep into the object hirerachy of the thing you’re dumping. You either implement a string conversion handler or manually convert the object to a string as well, whereas Javascript doesn’t need the extra string pass and doesn’t flatten the log hierarchy. There are a few JSON logging frameworks you can combine with log aggregators that provide the same functionality, but that’s quite heavy and complicated to set up.
A lot of people feel that way. If I need to generate a set of numbers or a certain string, though, it’s pretty easy to punch out a one-liner in GHCi, and that’s usually my use case.
I don’t know if you’re trying to be funny or your autocorrect is, but in Germany, when they switched from diploma to the bachelor/master system, both bachelor and master come with a theses. Many people leave with a bachelor, especially in computer science, so that might be why. Don’t know about other countries
I find Python is quick for the first 30 minutes. If you need any kind of libraries, or assistance from an IDE, or a distribution build, or you’re more familiar with another language, then it isn’t quicker.
It does, but the lack of static typing means it is more difficult to interact with foreign code (correctly).
When I pull in a library in a JVM language or Rust etc., I quickly glance at the documentation to get a rough idea of the entrypoint for the library.
Like, let’s say I want to create a .tar file, then the short “Writing an archive” example tells me all I need to know to get started: https://crates.io/crates/tar
If I need to find out more, like how to add a directory, then having the tar Builder initialized is enough for me to just ask my code completion. It will tell me the other available functions + their documentation + what parameters they accept.
If I make a mistake, the compiler will immediately tell me.
In Python, my experience was completely different. Pulling in a library often meant genuinely reading through its documentation to figure out how to call it, because the auto-completion was always unreliable at best.
Some libraries’ functions wouldn’t even tell you what types you’re allowed to feed into them, nor what type they return, and not even even diving into their code would help, because they just never had to actually specify it.
PyCharm a super powerful IDE, VSCode has tons of Python extensions that L rival PyCharm’s functionality, lots of other IDEs have decent python support
Yes, PyCharm is a super powerful IDE when compared to Nodepad++. But it’s a trashcan fire compared to IntelliJ or even the much younger RustRover.
Half the time it can’t assist you, because no one knows what types your code even has at that point.
The other half of the time, it can’t assist you, because, for whatever reason, the Python interpreter configured in it can’t resolve the imports.
And the third half of the time, it can’t assist you, because of what I already mentioned above, that the libraries you use just don’t specify types.
These are problems I’ve encountered when working on a larger project with multiple sub-components. It cost us so much time and eventually seemed to just be impossible to fix, so I ended up coding in a plain text editor, because at least that wouldn’t constantly color everything red despite there being no errors.
These problems are lessened for smaller projects, but in that case, you also don’t need assistance from an IDE.
or a distribution build
Not sure exactly what you mean by this
What I mean by that is that Python tooling is terrible. There’s five different ways to do everything, which you have to decide between, and in the end, they all have weird limitations (which is probably why four others exist).
or you’re more familiar with another language
Yeah this can be said about any language. “You’re quickest in the language you’re most familiar with”. That’s basically a tautology.
Yes. That is all I wanted to say by that. People just often claim that Python is a great prototyping language, to the point where the guy I was responding to, felt they’re doing the wrong thing by using the familiar tool instead. I’m telling them, they’re not.
What I mean by that is that Python tooling is terrible. There’s five different ways to do everything, which you have to decide between, and in the end, they all have weird limitations (which is probably why four others exist).
There’s actually at least 15 different ways (the fifteenth one is called rye and it’s where I got that article from). And yes your entire post is super accurate. The pycharm thing is ridiculous too because RubyMine is excellent in comparison. You just pull in a library with Ruby’s excellent (singular) package manager, and then RubyMine is able to autocomplete it pretty much perfectly. PyCharm can’t even manage to figure out that you added a new dependency to whatever flavor of the week package manager you’re using this time.
Look, it’s fine if you prefer other languages to python, I won’t besmirch anyone’s preferences. But literally everything in your post exists in nearly every programming language (minus some of the typing stuff, I’ll give you that, but it’s getting a lot better). Like, every language has some learning curve to setting up tooling, or configuring your IDE the way you like it, or learning how to navigate documentation so that it’s useful, or trying to decide on one of the multiple ways of doing things. I guarantee, as someone with limited experience with Java, I’d have a difficult time setting up and using IntelliJ, and figuring out which build/packaging system I need to use, and figuring out how to use whatever libraries I need, simply because I’m unfamiliar with the ecosystem. That’s all you’re describing - the initial learning curve in getting familiar with a new language. Which is why I pointed out all the things I pointed out. It’s where I start when I’m introducing developers to python.
No, it really is unique to python. Most other languages have one or two package managers, not 15 (15 is not an exaggeration). Ruby has one. Rust has one. Java has two (maven and gradle). Elixir has one. Swift has one.
Python programmers think it’s normal when it most definitely is not. Even your IntelliJ example isn’t correct because IntelliJ will literally install and set up the jdk for you, but pycharm is completely unable to do that and it’s not because JetBrains hasn’t tried. Python tooling is just really really really bad.
I firmly believe that every language has an equal proportion of spaghetti code to clean code. The only factor that might screw with this is how much a language is used in industry, which I’d expect raises the ratio. However, there’s plenty of hobbyists writing spaghetti code too so I don’t think even that factor has much effect.
Okay, I’ll grant you brainfuck… As for assembly, I don’t think it’s inherently spaghetti. You can split it up into functions just like you can with an actual programming language. It’s not impossible to make structured code.
That said, I never coded assembly outside of a mandatory university course, so I don’t feel super confident in saying that. But I don’t think of it as a programming language anyway - it’s a 1:1 translation to/from machine code, and machine code isn’t meant to make programming easy or scalable.
Did everyone become stupid in the last 10 or so years? We used to write huge apps in Python without any type checkers or static analysis tools and never had any problems we wouldn’t have had in statically typed languages.
Neither of those provide type inference? Type inference is when you give the compiler only occasional type hints and it can still figure out what the types are behind the scenes.
For example:
name = "World"
greeting = "Hello " + name
compile_error = greeting / 42
In a type-inferred language, the compiler would automatically know that:
the first line is of type String, because it’s trivially initiated as one.
the second line is of type String, because String + String results in a String.
the third line is non-sense, because greeting is a String and cannot be divided by a number. It could tell this before you run the program.
Mypy on the other hand can only tell these things, if you give the first two lines an explicit type hint:
Having to do this on every line of code is extremely noisy and makes refactoring annoying. I can absolutely understand that Python folks think you get productivity gains from duck typing, if this is the version of static typing they’re presented.
And we did excessively use mypy + type hints + pydantic on my most recent Python project. These are not the silver bullet you think they are…
If you’re going to post a code example, at least check that it works. Here’s your example, with no type hints, giving me errors both from the LSP, and when trying to run via mypy: https://imgur.com/a/Hq5Y5Gt.
I find it’s possible to operate Python as a statically typed language if you wanted, though it takes some setup with external tooling. It wasn’t hard, but had to set up pyright, editor integration, configuration to type check strictly and along with tests, and CI.
I even find the type system to be far more powerful than how I remembered Java’s to be (though I’m not familiar with the newest Java versions).
I don’t understand why people complain about their Python code breaking because it relies on indentation instead of explicit {} syntax. I’ve never had an issue with it and it’s not just because I’m used to it because Python is the only language I use that relies on whitespace like that. I think the complainers just don’t know how to indent properly, which makes me really glad they’re writing in a language that forces them to instead of pushing unreadable garbage in other languages.
Try finding a bug related to indentation in a 15 year old python codebase by the worst programmers on the planet. You won’t think that there’s no issues with it after that point. In any other language you literally just reformat and you’ll see the bug. That’s not the case in Python.
I’ve been coding around 25 years and got my start in perl. I absolutely hated python when I first used it. I use it all the time now. I still prefer my curly braces but I don’t have any trouble with python or mind the whitespace anymore. I just run it through ruff every save. I do the same with go everything goes through gofumpt. I really think a lot of it is a generational thing. Older people are just used to curly brackets.
I do get peoples complaints about the packaging. Unless you’re a dev already it’s a bit extra to deal with shuffling virtual environments because the system python environments almost never work out of the box, at least in the last few distros I’ve used. Once I adjusted though it’s no problem. I run half my dev stuff in toolboxes with their own environment anyway.
I mainly found it annoying while writing code, because the lack of braces makes it difficult to tell when a scope ends. Plenty times, I’ve wanted to add something to the end of a for-loop, but had too little indentation.
Usually this means I get a runtime error, because it can’t access some variable from the loop-scope. But worst case, it only executes once after the loop and I don’t notice the problem.
Another big thing I miss when not having explicit braces, is opening up new/anonymous scopes to isolate variables, which helps prevent mistakes down the line + reduces code complexity.
For example, this is a thing I do quite regularly:
let client = {
let client = new Client()
let timeout = config.load("client.timeout")
client.set_timeout(timeout)
client //implicit return value of this scope when evaluated as an expression
}
client.request_something()
It allows me to visually group the initialization code for the client and I don’t need to have the timeout variable in scope afterwards. Depending on the language, you can also have the client variable mutable inside the scope and then immutable outside.
Yes, this could be pulled out as a function to achieve something similar, but in my experience people (including me) will often just not do that, because it’s only the timeout variable or whatever.
I can see why you’d prefer braces in that case. I actually personally prefer {} over indentation as a matter of opinion, I just see them both as working fine 99% of the time. I’d also definitely take indentation over some shenanigans like start/end to define scopes.
wanted to add something to the end of a for-loop, but had too little indentation
To address this, I prefer reducing length & depth of nested code, so the for/while is rarely ever not visible along with everything inside it. Others have success with editors that draw indentation lines.
opening up new/anonymous scopes
I occasionally use Python nested functions for this purpose
its just not as clear especially when u are indenting stuff inside stuff with a bunch of conditions everywhere its hard to read just from indentation, and with the () or {} u can just click on it and most text editors will show u from where to where its going.
I once wrote a bot in python tdownloaded a ical file, looked for chances and informed me if found. The space indentation made it hell to follow the code in my opinion.
It’s because there is no clear indication of where a block ends.
Here is some sample code. I find it difficult to tell how many indentations I have or where I need to write if I want to continue at a certain level.
import time
import aiohttp
"""
Retreives the data from RSS URL and return the status codes as well as the data. Return -1 if something went wrong.
"""
async def get_rss_feed(rss_url):
async with aiohttp.ClientSession() as session:
try:
retry_count = 0
while retry_count < 5:
async with session.get(rss_url) as resp:
if resp.status == 200:
return {'status': resp.status, 'data': await resp.text()}
else:
retry_count += 1
time.sleep(60)
if retry_count == 5:
raise ValueError('To many failed connection attempts', retry_count)
except aiohttp.InvalidURL as error:
return {'status': -1, 'data': f"Error: {rss_url} is not a valid URL.", 'error': error}
except aiohttp.ClientConnectorError as error:
return {'status': -1, 'data': f"Error: Could not connect to {rss_url}.", 'error': error}
except ValueError as error:
return {'status': -1, 'data': f"Error: Could not connect to {rss_url} after {retry_count} attempts.", 'error': error}
Just curious, what about spaces made it hard? What language would have been easier? In curly brace languages, 99% of the time, a curly brace is followed by a line break and an indent. Python is similar except it’s typically a colon, line break, then indent.
What I have learned is: If the code is indented too deeply, it’s a code problem, not the language.
Too much nested code was likely part of the problem, but not being able to easily tell where a block of coded ended without seeing the top of the block made it difficult to work with.
That’s fair! Takes time to get used to. Modern editors make this easier by highlighting the current indent level, or can even make the top X lines of the current closure “stick” to the top of the editor for those really long blocks.
Having those features would really have made it easier. I have only ever written my python code in Sublime Text. While it is a sublime text editor, at is not ideal (compared to how it is to write Java in IntelliJ) for Python. (Maybe with addons but I never delved into that more than a few.)
Correct, I linked the source of the quote. My implication is the general idea is applicable here. Is python one of these languages where it is idiomatic to nest code deeply?
You are not logged in. However you can subscribe from another Fediverse account, for example Lemmy or Mastodon. To do this, paste the following into the search field of your instance: !programmerhumor@lemmy.ml
Post funny things about programming here! (Or just rant about your favourite programming language.)
Rules:
Posts must be relevant to programming, programmers, or computer science.
No NSFW content.
Jokes must be in good taste. No hate speech, bigotry, etc.
My indirect experience with python is that it is slow as hell. Anytime I install an app that includes python it lags 15-30 minutes on that step. Anytime I’m asked to install something with conda it takes 30 minutes to an hour.
I’m sure that is just due to environmental and implementation issues, but the Java fans say the same thing…
It’s near-universally regarded as a great prototyping language. For prod you should use something big-boy, like Java, or if you want to get fancy, Rust.
The “Big Boys” use tests to gauge when code is production ready, they don’t rely on a typing system and call it a day. I’ve seen monoliths made out of bash serve their purpose for years without a glitch, thanks to tests.
Tests are good too, although you can go overboard. You can write tests in Java or Rust or similar.
That feels like a packaging issue, which would be a problem specific to the developer of that app, not Python. For the most part, pip packages install basically instantaneously.
Yeah conda is slow af, but you can change the env solver which makes things much faster and there’s also mamba/miniconda which I haven’t tried but is supposedly much faster
Conda actually now uses the Mamba solver under the hood, as of the 23.10.0 release: https://docs.conda.io/projects/conda/en/latest/release-notes.html#id43
Unfortunately, their release notes page is buggy, so this link will stop pointing to the correct release when they publish their next release…
With things like wsl, conda has also become less useful. Anaconda is terrible software and the need for conda managed packages is mostly lost outside of the windows OS in my opinion.
And about 20 in perl. But the return trip is 300 years
can you really call python programming though? The reason why python is so quick to write is because its so-called libraries are pre-compiled C programs. so you’re not writing new programs, you’re scripting existing ones.
Is scripting programming?
not really, imo. its more like a sequenced list of pointers to various instruction sets.
But there are still if, while, function definitions, etc. in scripting languages. It doesn’t seem to me that different than even programming in assembler. In Assembler you also call subroutines, etc. and in every other language you also call functions from libraries.
The same is true for JVM bytecode, and C operations really are just aliases for ASM operations, and ASM (sometimes) is just aliases for microcode operations
Python, JavaScript, C#, Swift, Go…
Ah, the list of required skills on the last job posting I looked at…
😒
Ham/ster
Lol, at poo pooing typescript in a thread praising python of all languages
Dude… Java is not JavaScript
Java/Type Script
TypeScript might be fine, if it didn’t typically rely on a JavaScript stack that can and will ignore the nominal types.
TBF you probably don’t have to use any native JS libraries, so it’s kind of user error.
And 42 seconds in jython.
And a second in julia
It’s about writing the code, not execution time. Otherwise Assembly wouldn’t take 7 years…
Some languages are just worse to work with. like JavaScript. Console.log is like sure I’ll log your object but I’ll tell you what it is now, not what it was when you logged it.
Fwiw, Javascript’s object logging is a feature I often miss in other languages. If you just want to log the string, use formatted strings or just log obj+“” like you would need to do in every other language. Or even better, log a copy, like you probably wanted to do, with {…obj}.
I have many gripes with Javascript, but the logging API is pretty solid.
I’d just like to highlight what you mention below: Logging it as an object allows you to inspect it in the browser console, presumably with some JSON tree representation, rather than just a dumb string.
It’s described in the “Outputting a single object” example here: https://developer.mozilla.org/en-US/docs/Web/API/console#examples
I’ve never had a complaint about logging stuff in python. It generally does what I expect.
“Create a copy of your object and print that” is what I ended up doing, but I don’t think most people would say that’s intuitive. I expect if i print something at a particular time, I get what it is at that point in time.
Javascript passes objects by reference in most cases. Passing logging objects by copy would actually be an anomaly within the language. The only unexpected part is that the browser console doesn’t toString your objects instantly (for performance reasons mostly), but the same happens in other frameworks for other languages (though often with less latency, milliseconds most of the time).
As I’ve personally experienced, this can make debugging concurrency issues real fun! Pre-composing your log messages as a string (within the same critical section) will prevent quite a few weird edge cases.
The Python console doesn’t allow you to expand and dig deep into the object hirerachy of the thing you’re dumping. You either implement a string conversion handler or manually convert the object to a string as well, whereas Javascript doesn’t need the extra string pass and doesn’t flatten the log hierarchy. There are a few JSON logging frameworks you can combine with log aggregators that provide the same functionality, but that’s quite heavy and complicated to set up.
I can see it going both ways. Talking about execution times, this would be an exaggeration, but then, these memes always are.
And
in brainfuck
Good old brainfuck 👌
Check out my whitespace:
Thanks, I hate it
Java feels like McDonald’s and python feels like a grocery store.
Rust feels like a femboi hooters where they offer IVs you don’t think they’re qualified to administer.
Oddly specific
I don’t understand any of these analogies at all
Me neither but now I’m interested in Femboi-Hooters 👀
C is a makeshift kitchen deep in the Lacandon Jungle. If you burn your food, you start a forest fire and die.
But one compiling error is Java is 7 run time errors in python.
There is a type error and you couldn’t have known it beforehand? Thanks for nothing
I will confess that I get a sense of psychological comfort from strict typing, even though everyone agrees Python is faster for a quick hack.
I wrote my bachelor’s thesis in Haskell and have never touched it again.
A lot of people feel that way. If I need to generate a set of numbers or a certain string, though, it’s pretty easy to punch out a one-liner in GHCi, and that’s usually my use case.
When did baccalaureate theses become a thing?
I don’t know if you’re trying to be funny or your autocorrect is, but in Germany, when they switched from diploma to the bachelor/master system, both bachelor and master come with a theses. Many people leave with a bachelor, especially in computer science, so that might be why. Don’t know about other countries
Ah, I see. They aren’t standard at US Universities, though I did have to complete capstone projects for each of my BS degrees.
It’s half a semester worth of credit points while the master theses is a whole semester here so it might be similar to your system
I find Python is quick for the first 30 minutes. If you need any kind of libraries, or assistance from an IDE, or a distribution build, or you’re more familiar with another language, then it isn’t quicker.
PyPI has a huge selection of libraries
PyCharm a super powerful IDE, VSCode has tons of Python extensions that L rival PyCharm’s functionality, lots of other IDEs have decent python support
Not sure exactly what you mean by this
Yeah this can be said about any language. “You’re quickest in the language you’re most familiar with”. That’s basically a tautology.
Oh boy, you really wanna talk about it?
It does, but the lack of static typing means it is more difficult to interact with foreign code (correctly).
When I pull in a library in a JVM language or Rust etc., I quickly glance at the documentation to get a rough idea of the entrypoint for the library.
Like, let’s say I want to create a .tar file, then the short “Writing an archive” example tells me all I need to know to get started: https://crates.io/crates/tar
If I need to find out more, like how to add a directory, then having the tar
Builder
initialized is enough for me to just ask my code completion. It will tell me the other available functions + their documentation + what parameters they accept.If I make a mistake, the compiler will immediately tell me.
In Python, my experience was completely different. Pulling in a library often meant genuinely reading through its documentation to figure out how to call it, because the auto-completion was always unreliable at best.
Some libraries’ functions wouldn’t even tell you what types you’re allowed to feed into them, nor what type they return, and not even even diving into their code would help, because they just never had to actually specify it.
Yes, PyCharm is a super powerful IDE when compared to Nodepad++. But it’s a trashcan fire compared to IntelliJ or even the much younger RustRover.
Half the time it can’t assist you, because no one knows what types your code even has at that point.
The other half of the time, it can’t assist you, because, for whatever reason, the Python interpreter configured in it can’t resolve the imports.
And the third half of the time, it can’t assist you, because of what I already mentioned above, that the libraries you use just don’t specify types.
These are problems I’ve encountered when working on a larger project with multiple sub-components. It cost us so much time and eventually seemed to just be impossible to fix, so I ended up coding in a plain text editor, because at least that wouldn’t constantly color everything red despite there being no errors.
These problems are lessened for smaller projects, but in that case, you also don’t need assistance from an IDE.
What I mean by that is that Python tooling is terrible. There’s five different ways to do everything, which you have to decide between, and in the end, they all have weird limitations (which is probably why four others exist).
Yes. That is all I wanted to say by that. People just often claim that Python is a great prototyping language, to the point where the guy I was responding to, felt they’re doing the wrong thing by using the familiar tool instead. I’m telling them, they’re not.
There’s actually at least 15 different ways (the fifteenth one is called rye and it’s where I got that article from). And yes your entire post is super accurate. The pycharm thing is ridiculous too because RubyMine is excellent in comparison. You just pull in a library with Ruby’s excellent (singular) package manager, and then RubyMine is able to autocomplete it pretty much perfectly. PyCharm can’t even manage to figure out that you added a new dependency to whatever flavor of the week package manager you’re using this time.
Oh man, this isn’t meant to shit talk Rye (from what I’ve heard of it, it actually is a decent effort), but it’s literally this comic then:
![](https://imgs.xkcd.com/comics/standards_2x.png)
Yup
Look, it’s fine if you prefer other languages to python, I won’t besmirch anyone’s preferences. But literally everything in your post exists in nearly every programming language (minus some of the typing stuff, I’ll give you that, but it’s getting a lot better). Like, every language has some learning curve to setting up tooling, or configuring your IDE the way you like it, or learning how to navigate documentation so that it’s useful, or trying to decide on one of the multiple ways of doing things. I guarantee, as someone with limited experience with Java, I’d have a difficult time setting up and using IntelliJ, and figuring out which build/packaging system I need to use, and figuring out how to use whatever libraries I need, simply because I’m unfamiliar with the ecosystem. That’s all you’re describing - the initial learning curve in getting familiar with a new language. Which is why I pointed out all the things I pointed out. It’s where I start when I’m introducing developers to python.
No, it really is unique to python. Most other languages have one or two package managers, not 15 (15 is not an exaggeration). Ruby has one. Rust has one. Java has two (maven and gradle). Elixir has one. Swift has one.
Python programmers think it’s normal when it most definitely is not. Even your IntelliJ example isn’t correct because IntelliJ will literally install and set up the jdk for you, but pycharm is completely unable to do that and it’s not because JetBrains hasn’t tried. Python tooling is just really really really bad.
I won’t feel bad about it then, lol. At least not until I’m collabing on something and they want to use Python.
And then the quick hack gets a permanent solution and the next employee has to fight trough the spagetti.
Such is life.
sounds like not my problem
You will find yourself being that next person when you haven’t touched the code for a week and come back to add something and are like wtf.
The circle of 1!f€
This may be true, but it’s equally true in any programming language, so not really relevant.
I’d guess it’s less true for something statically typed, just because that reduces the ways it can be unintuitive.
I firmly believe that every language has an equal proportion of spaghetti code to clean code. The only factor that might screw with this is how much a language is used in industry, which I’d expect raises the ratio. However, there’s plenty of hobbyists writing spaghetti code too so I don’t think even that factor has much effect.
Really? Doesn’t that imply non-spaghetti brainfuck or assembly?
Okay, I’ll grant you brainfuck… As for assembly, I don’t think it’s inherently spaghetti. You can split it up into functions just like you can with an actual programming language. It’s not impossible to make structured code.
That said, I never coded assembly outside of a mandatory university course, so I don’t feel super confident in saying that. But I don’t think of it as a programming language anyway - it’s a 1:1 translation to/from machine code, and machine code isn’t meant to make programming easy or scalable.
The IDE can assist you before it even becomes a problem, so even more time saved.
Did everyone become stupid in the last 10 or so years? We used to write huge apps in Python without any type checkers or static analysis tools and never had any problems we wouldn’t have had in statically typed languages.
no, we didn’t, we made a bunch of small programs
With type annotations, this problem is mostly alleviated in practice, while still keeping the productivity gains of duck typing.
In my experience, Python’s type annotations are annoying as hell, because there’s no inference.
You can use mypy and/or Pydantic.
Neither of those provide type inference? Type inference is when you give the compiler only occasional type hints and it can still figure out what the types are behind the scenes.
For example:
In a type-inferred language, the compiler would automatically know that:
Mypy on the other hand can only tell these things, if you give the first two lines an explicit type hint:
Having to do this on every line of code is extremely noisy and makes refactoring annoying. I can absolutely understand that Python folks think you get productivity gains from duck typing, if this is the version of static typing they’re presented.
And we did excessively use mypy + type hints + pydantic on my most recent Python project. These are not the silver bullet you think they are…
If you’re going to post a code example, at least check that it works. Here’s your example, with no type hints, giving me errors both from the LSP, and when trying to run via mypy: https://imgur.com/a/Hq5Y5Gt.
I find it’s possible to operate Python as a statically typed language if you wanted, though it takes some setup with external tooling. It wasn’t hard, but had to set up pyright, editor integration, configuration to type check strictly and along with tests, and CI.
I even find the type system to be far more powerful than how I remembered Java’s to be (though I’m not familiar with the newest Java versions).
Ime anyone who is experienced enough knows how to avoid these Types of issues anyway (through tooling and good convention etc)
In Java you get a bunch of unexpected NullPointerExceptions instead…
usually this means you made a booboo, try catching these exceptions if it’s a possibility.
This little hack is gonna cost us 51 CPU cycles.
Yeah but due to the extra indentation in the second image, the python part doesn’t work.
Sorry, are we talking about spaces or tabs? I want to comment on same indentation to not break the thread
I don’t understand why people complain about their Python code breaking because it relies on indentation instead of explicit {} syntax. I’ve never had an issue with it and it’s not just because I’m used to it because Python is the only language I use that relies on whitespace like that. I think the complainers just don’t know how to indent properly, which makes me really glad they’re writing in a language that forces them to instead of pushing unreadable garbage in other languages.
Try finding a bug related to indentation in a 15 year old python codebase by the worst programmers on the planet. You won’t think that there’s no issues with it after that point. In any other language you literally just reformat and you’ll see the bug. That’s not the case in Python.
I’ve been coding around 25 years and got my start in perl. I absolutely hated python when I first used it. I use it all the time now. I still prefer my curly braces but I don’t have any trouble with python or mind the whitespace anymore. I just run it through ruff every save. I do the same with go everything goes through gofumpt. I really think a lot of it is a generational thing. Older people are just used to curly brackets.
I do get peoples complaints about the packaging. Unless you’re a dev already it’s a bit extra to deal with shuffling virtual environments because the system python environments almost never work out of the box, at least in the last few distros I’ve used. Once I adjusted though it’s no problem. I run half my dev stuff in toolboxes with their own environment anyway.
I have never had any problems with it either but don’t get me started on YAML.
I mainly found it annoying while writing code, because the lack of braces makes it difficult to tell when a scope ends. Plenty times, I’ve wanted to add something to the end of a for-loop, but had too little indentation.
Usually this means I get a runtime error, because it can’t access some variable from the loop-scope. But worst case, it only executes once after the loop and I don’t notice the problem.
Another big thing I miss when not having explicit braces, is opening up new/anonymous scopes to isolate variables, which helps prevent mistakes down the line + reduces code complexity.
For example, this is a thing I do quite regularly:
It allows me to visually group the initialization code for the client and I don’t need to have the
timeout
variable in scope afterwards. Depending on the language, you can also have theclient
variable mutable inside the scope and then immutable outside.Yes, this could be pulled out as a function to achieve something similar, but in my experience people (including me) will often just not do that, because it’s only the
timeout
variable or whatever.I can see why you’d prefer braces in that case. I actually personally prefer {} over indentation as a matter of opinion, I just see them both as working fine 99% of the time. I’d also definitely take indentation over some shenanigans like
start
/end
to define scopes.To address this, I prefer reducing length & depth of nested code, so the
for
/while
is rarely ever not visible along with everything inside it. Others have success with editors that draw indentation lines.I occasionally use Python nested functions for this purpose
its just not as clear especially when u are indenting stuff inside stuff with a bunch of conditions everywhere its hard to read just from indentation, and with the () or {} u can just click on it and most text editors will show u from where to where its going.
That’s an anti pattern in basically every language though. The fix is to simplify those conditionals, not use a curly-bracketed language.
I once wrote a bot in python tdownloaded a ical file, looked for chances and informed me if found. The space indentation made it hell to follow the code in my opinion.
I don’t get it because my phyton code is indented exactly the same as all my other code. Each block of code one tab in/out, how else would you do it?
It’s because there is no clear indication of where a block ends.
Here is some sample code. I find it difficult to tell how many indentations I have or where I need to write if I want to continue at a certain level.
Just curious, what about spaces made it hard? What language would have been easier? In curly brace languages, 99% of the time, a curly brace is followed by a line break and an indent. Python is similar except it’s typically a colon, line break, then indent.
What I have learned is: If the code is indented too deeply, it’s a code problem, not the language.
Torvalds infamously wrote:
Too much nested code was likely part of the problem, but not being able to easily tell where a block of coded ended without seeing the top of the block made it difficult to work with.
That’s fair! Takes time to get used to. Modern editors make this easier by highlighting the current indent level, or can even make the top X lines of the current closure “stick” to the top of the editor for those really long blocks.
Having those features would really have made it easier. I have only ever written my python code in Sublime Text. While it is a sublime text editor, at is not ideal (compared to how it is to write Java in IntelliJ) for Python. (Maybe with addons but I never delved into that more than a few.)
Torvalds wrote this about C. There’s plenty languages where it’s much more common and less of a complexity indicator to open up scopes.
Correct, I linked the source of the quote. My implication is the general idea is applicable here. Is python one of these languages where it is idiomatic to nest code deeply?
The Zen of Python:
From the python I have seen and written, deep nesting is avoided.