Breaking up with Python
cedwards.xyz
cedwards.xyz
I can't agree with this. I have always had a very good experience with python documentation. One can use the built-in "help" function which works seamlessly with the docstring feature of the language. The complaint in the blog post seems to refer to the UI of the website missing a table of contents for functions. Yeah sure they could add that but I don't see it as a big point.
> Python’s package management sucks
Hmm, it has some weaknesses but I wouldn't really say it sucks. Going deeper ->
> Every project seems to use a different tool and it’s a massive headache. Off the top of my head there’s ...
Don't all of these use pip under the hood? I personally use the lower-level pip and virtualenv tools, but some others enjoy the convenience of poetry. That's a bit of personal preference. It's a bit more akin to an IDE choice than a feature of the language. None of conda, poetry, etc. are core Python features.
> Python’s standard library sucks
I have to disagree again, I think it is pretty well designed and minimal on purpose. The community additions of numpy, etc. are by design not part of the core language to reduce bloat.
> Python is slow
OK sure, it is slower than compiled languages like C++, that is a concession we make when opting for the ease of readability, writability, usability, etc.
> Python is huge, the python:3.9-slim Docker image is 118MB
Hmmm. 118MB isn't really that big anymore. The docker image would presumably be cached and reused in a deployment pipeline.
> Python syntax sucks.
This one I can't even understand the reasoning for. The python syntax is what people love about it. I personally dislike the walrus operator, f-strings, and some of the other newer features (did they add the switch statement yet?) but those are my only gripes. And they are more pet-peeves / personal preferences than complaints.
…I really like python, but man it’s warts are annoying.
I hate redundancy and the dunder and explicit self parameters completely stupid. With time I just got used to them .. (thanks partly to editor templates). The private field shenaningans weren't sexy either..
Other than that I agree.. it would be worth a python4
class Foo(Bar):
new(*a, **kw):
"keyword: new"
super(*a, **kw)
print('v4')
bar(a,b,adjust=1):
"no self, shorthand super.parent_method()"
return super.bar(a, b) + adjust
Agree with the rest of your points, though, except not liking newer syntax. Newer syntax, in my experience, makes writing code less of a chore and mirrors the developer conveniences in other modern languages.
> I have to disagree again, I think it is pretty well designed and minimal on purpose
Oh come on. That’s like saying “this buffet has no food selection but that’s good cause I’m on a diet”. Meaning that you like that it sucks (that’s fine).
Numpy is not the kind of thing you would include in the std lib anyway.
> OK sure, it is slower than compiled languages like C++, that is a concession we make when opting for the ease of readability, writability, usability, etc.
Fair, but I’ve spent enough time python environment/dependency hell that a lot of those gains (which are mostly cognitive) weren’t worth it for me.
I ported a golang (non concurrent) program that was 3 files and lots of intermediate procedures over custom types (synchronized maps)
it thing fit beautifully in a one page python script, very readable. bonus: concurrency (threadpool over queues). the only libs were click and rich but not relevant to the design
and the fact that it's repl-able you can quickly navigate in the stdlib.
ps: python docs are not amazing but they have a low signal/noise/confusion ratio. if one wants to suffer go "read" the javadoc, with it's empty package descriptions, extreme redudancy of autogenerated get/set * polymorphic methods. Or to stay in the python world, django docs. They're abysmally non technical.. it's full on guess fest to infer the relationships between classes and dataflow. Superb.
If I could add one thing to the python standard library it would be unify the python std lib array and the numpy array and make many of the most common and useful numpy array methods available in the std lib.
The author favors Javascript while deriding Python for its syntax, type-hints, and standard library, and favors Go while deriding a Python Docker image's size and documentation. I feel like the author must use Python in a very different way than I do for Javascript and Go to be the winners in these categories.
I do agree without reservation that package management and dependencies are horrible with Python.
It depends what you're comparing them against. Python's style of documentation - for the language itself and for many of the popular libraries that follow the same style - is mostly reference material and often incomplete. It's very lacking in examples of usage. It almost completely ignores types. It often doesn't appear in search engine results for relevant keywords leading to spending several minutes brute force searching the official docs site to find something that should have been a 10 second search. Perhaps the most obvious comparison is with the JavaScript/TypeScript world, which has embraced both types and different kinds of documentation and as a result gives a much better developer experience in those areas today.
The standard library in Python is strange because it has a lot of content but much of that content just isn't very good. Entire packages in the standard library are largely ignored in favour of some de facto standard package from PyPI that does the same job much better. Some of the packages for working with different protocols and file formats are useful in the right circumstances but they're so slow that they're not suitable for many applications and again you end up pulling in a better alternative. Meanwhile common data structures and algorithms that you might look for in any modern language's toolbox are scarce to non-existent and the ones that do exist don't always compose easily.
I also agree with you on typing, searchability, and the problem of standards vs defacto standards. (The page for `urllib.request` points you to `requests`, which is good! But the page for `array` has a link to `numpy` only at the very bottom.) I also don't have the JS/TS experience to compare against, but I believe you there. (The MDN alone is excellent.)
I think my experience is biased from spending a lot of time in deep learning. (Keras and Pytorch have a bit of a competition for having good docs). The adjacent libraries, like Numpy or Pandas or stdlib like `socket`, have also been good in my experience. (Perhaps these benefit from having relatively 'obvious' types for most functions. One might infer the types and dimensions of `numpy.matmul(x1, x2)` easily, whereas I have no idea what the types of the args in `Request.set_proxy(host, type)` are.)
It's a shame this post was flagged, because I've had a lot of blind spots uncovered in this thread!
> Hmmm. 118MB isn't really that big anymore. The docker image would presumably be cached and reused in a deployment pipeline.
Caching aside, it seems that the Python slim image is built on Debian, which will usually have slightly bigger container sizes than something like Alpine, which is comparatively more lightweight/barebones:
> docker pull python:3.9-slim && docker image ls
REPOSITORY TAG IMAGE ID CREATED SIZE
python 3.9-slim e2f464551004 8 days ago 125MB
> docker run --rm python:3.9-slim sh -c "cat /etc/*-release"
PRETTY_NAME="Debian GNU/Linux 11 (bullseye)"
NAME="Debian GNU/Linux"
> docker pull python:3.9-alpine3.17 && docker image ls
REPOSITORY TAG IMAGE ID CREATED SIZE
python 3.9-slim e2f464551004 8 days ago 125MB
python 3.9-alpine3.17 d6d1ed462b20 3 weeks ago 48.8MB
> docker run --rm python:3.9-alpine3.17 sh -c "cat /etc/*-release"
3.17.0
NAME="Alpine Linux"
Of course, caching and any additional tools that you may or may not want to include also plays a part. Personally, I just went for maximum predictability and usability, and now build most of my personal container images basing them on Ubuntu LTS, with some common CLI tools included for debugging: https://blog.kronis.dev/articles/using-ubuntu-as-the-base-fo...
Just use whatever works for you, but rest assured that JDK and other stacks will typically also have some overhead to them. Python might not be the worst offender here. Something like Go with compiled binaries is still very nice, granted.
Does not being compiled really help with readability? How? After all, one can compile python to machine code, and there are C++ interpreters [1] (I have not heard any claims that using it makes C++ more readable). Then there are very readable/usable languages such as Haskell that come out of the box with both a compiler and interpreter.
To be more specific: which features does the absence of the possibility of compilation [2] enable?
[2] Since interpretation and compilation are not mutually-exclusive for a language.
There is also tools such as Cython and numba (JIT) which use various techniques to compile Python code btw. But I am generally in favour of switching to a high performance language or writing in C++ and then importing in Python at that point, personal preference again...
Interesting to read about cling, will have to play around with that.
That's how I understood your post. Sorry if my post came off as a correction - it was not meant as such, but as a question (not specifically about Python or C++):
How does a language benefit from not having the option to compile it? What restrictions does the requirement to be able to produce a machine-code executable place on it?
Because naively, I would say it should have no effect - one could package the interpreter and source-code into a single file, and think of that as a (very unoptimized) "compiled executable".
For example say I have a script:
data = slow_computation()
metrics = produce_metrics(data)
When I am happy with my experimentation results, say, I have found something interesting about the data and written a new function cool_metric(metrics) I can commit it to the script at the end
data = slow_computation()
metrics = produce_metrics(data)
cool_metric = cool_metric(metrics)
so if I have
def some_buggy_function(args):
data = analyse(args)
breakpoint()
new_data = further_analyse(data)
“Compiled” is being used as a short-hand for “compiled with optimisations”, so yes, an unoptimised build wouldn’t count here.
The design decision is around when (between the code being written and being run) is the final decision made about what exact code will run. If that is known really early (static types, no dynamic dispatch) then optimisations can be made early too. If it is really late (polymorphic methods, support for redefining types etc) then optimisation needs to run very quickly (“just in time”) or not at all.
If you want to go deeper on this, look at performance optimisation in Julia. It has the same LLVM backend as C/Rust, so can use all the same optimisations, but it is arguably a more dynamic and easier to use language than Python, so when and how optimisations apply really depends on how the code itself is written. As a bonus, it has some great tooling to see how changes to the code impact performance.
While I generally do like the python documentation, I often find that it likes to explain exactly how and why a library works in detail. This is great if you want to really learn the library and often I miss this level of detail in for example JavaScript, but if you just quickly want to find the most obvious way to do the most common thing, it can be quite annoying.
It takes me half a day to figure out a reliable way to cross compile rust binaries for Raspberry Pis, withput ever having done this before.
There are a lot of good things about python but the dev environment sucks a lot and it is so engrained in the very substance of the language/tooling that I don't really see a path out of that other than going all Python 4.0 on it and repeating the python2/python3 schism all over again.
Python is still my goto language but it is my goto language despite the tooling, not because of it.
The point is that every extra tool you need to work on a project is another thing you need to get installed and working. It's another thing that will rot over time. In 5 years it might be totally unusable and broken.
When I clone a project, I want to be productive with it as quickly as possible.
But JavaScript is in no way different in this regard: Bit, Yarn, PNPM, Turbo, NX, Rush. If anything, JS has more tooling chaos than Python. And don't get me started on webpack and all its alternatives. And then there is the repository chaos, umpteen abandoned packages, repeated instances of malware injection (which has also happened in the cheeseshop, I know, but not nearly as often).
In the end, you choose a tool, and use it until you decide there is a better tool, and you get to work. I used to use only pip and venv. For a while I used virtualenvwrapper. Now I use Poetry with asdf, and it is a very pleasant experience.
The better JavaScript performance doesn't matter in 90% of use cases. In nearly every real-world bottleneck, the answer is not to switch ecosystems, but to optimize. How much traction has JS gotten in workloads where numpy and tensorflow rule the roost?
And you don't like Python's syntax. That's your prerogative. I love it, and so do millions of other python devs.
I think there's something deeply path dependent about how software people go through languages and fall in and out of love with them. Python was the first language I ever used professionally. It was amazing at the time compared to Java. But I haven't touched it in years now and don't especially want to. It's not that I "broke up" with it -- I just went elsewhere and it wasn't used there. You usually have to speak the local language wherever you go...
At a certain point, I think a lot of us give up on the idea of "loving" or "not loving" the language we use. They are all just tools. Some professional software people still have love affairs with their tools. That's cool I guess, but I have to say, I've written useful software in horrible languages (PHP) and I feel good about that too, and about not caring about the lovability factor (so to speak) of my professional toolkit.
It's really a shame that data science, ML, and notebooks are so wrapped up in it. Otherwise we could jettison the whole thing into space
Although I personally feel Python has its place, I contribute to a project that hopes to diversify the ML/scientific computing space with a TypeScript tensor lib called Shumai: https://github.com/facebookresearch/shumai
> Documentation
JavaScript wins here thanks to MDN, but it's not the official documentation.
> Package Management
I agree that Python's package management has its issues, but JS is insane in this regard
> Standard Library
JavaScript's standard library is definitely smaller than Python's
> Slow
This is clearly a win for JS
> Size
When comparing the slim official Python docker image with the equivalent NodeJS image, Python wins in size
> Syntax
This is the most subjective point. I prefer Python's syntax because it's less noisy, but JavaScript's syntax is more consistent.
Regarding type annotations they don't do anything at runtime, but they are extremely useful for IDEs.
There are a lot of reasons to like or not like Python that will become evident after using it in a significant fashion. I was hoping for some of that insight, both to commiserate and celebrate the horrors and joys that I've experienced using the language and its ecosystem for some time. This article was not that.
Easy examples I use every day: ML and Quantum Computing libraries.
There is a depth to the Python ecosystem that can't be matched anywhere else.
Honestly, I'm sure I will get a ton of flack for this, but I really dislike Python. I use it every day and have for years and not only has it failed to grow on me (like most languages do), I've learned to dislike it more with each year. That said, I'm locked in. Outside of Python the libraries available are abandoned research projects or hobby tools, at least when it comes to my areas of focus.
I'd really like to see machine learning stuff in languages other than Python so that there's less friction in experimenting. I know that would require prying it from researchers' cold dead hands though.
I agree, though, the urllib module that he links to it's not the best thing ever when it comes to Python, and I say that as a guy who has written Python code for a living for 17 years now. But other than that I find the standard library more than ok.
The only thing that I can agree on is the slowness, but even that is relative, as we're not all writing speed-critical code. The type annotations never took off because they were, and are, basically un-pythonic, trying to force types on Python's throat, so to speak, is definitely un-pythonic. Unfortunately the "types are a silver bullet"-hype is all too real, so there's also that.
He should have also learned to love dir()-ing stuff.
My personal recommendation is to use typing and mypy in all new code, coming from somebody who was celebrating new-style classes in 2.2.
Typing with mypy during development never quite cut it because it's optional (unlike e.g. Typescript), and the editor support just didn't quite make it effortless the way VSCode/Pylance did. (I'm talking about development, not CI.)
I think the reason it (and the http modules in general) has never been improved is that even when Python was young, there were better third party packages out there, but no single one of them ever got to the point where the Python devs would consider making it part of the standard library. Particularly when it comes to servers, there have always been multiple third party frameworks with significant market share. For clients, we might be getting to the point where the requests library is common enough to be a candidate for the standard library.
https://jeremyhylton.blogspot.com/2008/06/
I think there's quite a lot of use of requests that would be fine with 'urllib.request.urlopen(...)'.
I don’t think that’s true; I think that type annotations have been seeing significant gains in usage in Python in recent years.
[0] https://peps.python.org/pep-0594/ that
python3
import some_module
dir(some_module)
ipython3
import some_module
some_module?
# or
some_module??
you can read the docs in the standard REPL with help(object).
And, of course, IDEs (or editors with decent Python support plugins) will do it on hover.
I've always found the Python standard library to have tons of useful stuff, and when I'm doing something in JS I often feel like I'm missing my toolbelt or something. Then I install a single npm package to do something simple and it winds up having 350 dependencies.
- Python is too big
- Python's standard library is too small
- therefore, you should use JavaScript
It made me wonder if I was hallucinating, so I went and checked... my `node` execurtable is 78MB. Thanks to its robust standard library, my node_modules folder is only 884 MB.
Throughout my studies and career I've written c, c++, java, javascript, perl, bash, python and a little bit of go. Python for me is by far my favorite and most productive language. Expressive syntax, an unmatched wealth of useful libraries and most importantly: when I come back to code I wrote months ago I can easily read and understand it! Which can't be said of my old perl code.
I also love how python has been picking up steam lately, 3.6 - 3.11 have been splendid releases with plenty of goodies in each one.
I wouldn't make assumptions like that. I've worked with production Python codebases. In fact, until recently I was working as a DevOps Engineer in a hedge fund building much bigger, more complex systems than a typical CRUD backend. I worked hands on with some of the Python repositories and it was extremely painful simply because of the nature of Python.
Still smaller than most Go binaries.
Had to play with compiler flags to reduce trivy to a proper size (it was 300MB with default flags), and that was only the binary, without any containers.
And the dependency story is hardly any better than Python.
Python has plenty of issues, but it's still great for a huge pile of use-cases.
I've built a career on Python and Django. Even as my frontend work migrates into thick assemblies of javascript, I can't imagine using anything else for the backend for complex systems, but who knows what the next 20 years holds.
If you've spent years, or even decades, building a portfolio with Python then the breakup is going to be much harder, just like in human relationships. Some things will make sense to leave in Python until end-of-life. Other things will be worthwhile to migrate to Go. Of course your new greenfield projects can start off using Go.
Just know this - you're going to go through this again in another 10-15 years, if not sooner. I've been writing software now for 40 years, that's just the way it goes.
> my go-to language for a quick bit of scripting where another language might feel too heavy duty
So this article is not from someone who has used Python full time professionally...
Maybe for production ready microservices, but I've always thought Python's std lib was pretty expansive.
Having a big standard library can be great, especially for things and designs that have been settled years ago, but inclusion into the standard library means iterating upon those modules will receive pushback from maintainers looking out for consumers of the standard library who need it to remain stable for potentially decades.
I can see why that’s nice, but I find it odd to be described as a peak. While the details of the standard library it documents have evolved, I don’t see how the current version (linked from the main docs site with the same “keep this under your pillow” line) of the same portion of the docs is any worse:
It just gave you exactly what you needed to know and otherwise stayed out of the way. Remember l, this was from an age when online doc didn’t really exist… I certainly never used the html version.
When you’re on dialup a local, quickly searchable version was very valuable.
edit: to be clear, I hope this won't devolve into a language flamewar. I'm sincerely interested in other devs' opinions, and hoping that either Python is still a good recommendation (which seems to be the consensus so far) or that there's a better alternative.
Java, PHP or JavaScript for 'widespread use and longevity'. None of these are going anywhere, and I think you'd find more resources for beginners to advanced users for those 3. Yes, of course there's others - everyone has their faves. And Python will continue to kick around as well, but I've just never understood the 'beginner friendly' bit.
PHP was not designed at all. It took a decade to make it more than a template processor. The biggest, by far, selling point was ease of deployment: ftp and done. Good if you want to display something in a browser. Learning programming, not so much.
Javascript is starting to become a sane language with ES6. It’s an accident of history that became an industry standard due to sheer power of will of browser companies. Tooling complexity in its ecosystem rivals, if not exceeds, that of C++. Recommending js s as a language to learn programming on has been until last couple of years irresponsible.
Python was designed to be beginner friendly, it was the next iteration of other beginner-friendly languages that had some academic research done about, you guessed it, beginner friendliness. It is not an accident it’s recommended for newbies! Due to that and a decade of 1) numpy for biological computing 2) django/flask for web services it’s ubiquitous in two very loosely connected domains, giving birth to jupyter and tensor libraries, and here we are. Turns out a batteries-included standard library makes packaging not a priority for too long.
Also, being interpreted, you don't need much (or really any other than the interpreter itself) tooling to start playing around with it. This is true, of course, for lots of other languages.
I think also the fact that people do use it for real solutions makes it more appealing to recommend than a "toy" language like Logo or BASIC. (Mentally, I see BASIC as separate than VB. And yes, I am sure some people will comment that real solutions are built in BASIC, but I am sure these days Python dwarfs those in count by a factor of 100, at least.)
It allows to solve the menial tasks someone with no programmng experience usually needs to solve, can interact with HTTP/REST-like APIs, sometimes has the modules for a popular solutions, is object oriented, lax on the indentation *smirk*.
Ugh. Sorry, I've not really got anything constructive (destructive?) to say in support of that other than (a) in practical terms it isn't a transferrable skill beyond Windows, (b) the Naming-Conventions-OfThings is both awful and verbose, and (c) I've never had a use case where more than a handful (at most) of my fellow devs would be happy to work with it in the future.
YMMV and I appreciate this is very much a personal opinion.
Basics works everywhere. In my personal experience I often found myself in a situation where I'm spending a lot of time wrestling with *nix shell (especially finding workarounds for the differences between Debian/Ubuntu and RH/CentOS/Rocky) instead of spending 5 minutes on PS script which would would everywhere, just supply the distro specific paths.
b) not a problem in the real life. Come on, you don't sprn you time writing the paths, you just TAB them - same thing with PS, except it works on cmdlet names AND their parameters, out of the box, on any platform. Ubuntu has it now by default (for some supported things), RH-like - not.
c) well they probably had a more familiar to them tool on their hands already
YMMV, of course, but the thing is what you are being constructive here, with explicitly stating things you don't kno2 or understand.
[0] and there are Py modules for that too, but they are not the part of the default install too
> explicitly stating things you don't kno2 or understand
I've done Windows development since 3.1 (and .Net since 2001) so in that time I've written a lot of PowerShell. I'm not offering uninformed second-hand opinions.
For (a) I'd argue that the lack of adoption outside Windows makes it de-facto not really a transferrable skill, even though it does run elsewhere. For (b) so what if it is easy to autocomplete? It doesn't make it any less ugly/verbose. For (c) yes, that was exactly my point. Stuff needs to be maintainable, and if fellow devs have other more familiar tooling then using that tooling is usually more appropriate.
If PowerShell is for you, great. I don't feel the need to convince you otherwise; in your situation maybe it is. But sometimes a difference of opinion is just that - a difference of opinion, and not ignorance of the subject matter.
If you want to only write/use PS - then probably, but... if this is yours environment - you chose the tools, if it's not - the overall concepts and workflow doesn't differs too much, especially for Python.
I had an unpleasant experience of rewriting a Python 2 script to Python 3. At some point I just said "fuck it" and rewrote it, from scratch, on Linux, with .NET SNMP library - and I got a working script in an hour, compared to 3 days of headache with a known good Py2 script which I only needed to adapt to Py3.
The difference was in the quirks of Python (especially on strong typing and indentation), not in the program flow.
Later I finished rewriting it in Py3 but the overall experience of writing in Python left a sour taste.
A person who would start with PS could easily adapt to Python (or honestly any other language) if he would understand how the things work - and PS allows, IMNSHO, that in a quick and easy way.
But if someone just copy-paste the code from SE - does it matters if that happens in Python or PS?
> so what if it is easy to autocomplete? It doesn't make it any less ugly/verbose
LOL, "I need a PL what is easy for a beginner, so I would NOT recommend an explicitly verbose language for that!"?
a) easiness of autocomplete allows the discoverability of the options. Just a simple Ctrl+Space offers all the options of a cmdlet (conveniently listing them with the precedence used by the author, leaving all the automatic shit added by cmdletbinding() at the end) and this alone helps tremendously with writing. I don't keep all the things, options and parameters in my head (and I don't want to) and a beginner doesn't know them in the first place.
Most of the time I just write something and see if the are means to do what I want through the autocompletion of parameters and cmdlets. If I don't see the appropriate things or they don't work as I expect them to work - only then I consult with manual. If in your opinion nobody should write a single LOC without a couple of hours in the docs...
b) I often hear about how the verboseness of PS as bad thing, but... honestly, IMO, it doesn't matter, it's not THAT verbose as Java, it's not full of obscure and senseless abbreviations and names (especially compared to Linux CLI) and if you compare the actual similar code.. it's not that big difference in LOC and line length. Oh, and you don't reinvent the wheel each time you need to have a working help and argument parsing *smirk*.
c) are we still on the "PL for a beginner" topic? For a carpenter microscope is just a very bad hammer.
> difference of opinion
Let's get back to "PL for a beginner". Between Python and PS the latter would win just because it has a better IDE/autocomplete and has automagik on a lot of things what would drive a beginner mad in Python (oh god, just calling an external binary and capturing it's output...)
PS, as an anecdata: I have a friend who can write some Java, for util level things. I've seen his PS code - he treats PS as a full fledged PL (which again - isn't a bad thing, just not the best way to spend your time writing PS scripts). I doubt he wrote anything in Python, but of what I saw in his PS code means he would have no problems (well, except strong typing and indentation, LOL) writing something in Python.
The only thing I'd note is that unfortunately by not mentioning it in my earlier reply I left you thinking I was suggesting Python over PowerShell, which makes sense given the way others were discussing the topic.
On this, however, I agree with you in that I too would not automatically suggest Python as the best learning language. I'd actually plump for Go scripting or C# (single file), but on the understanding that it's for learning business domain or web programming. For the true beginner I don't really have a strong opinion so maybe PS could work.
Anyway, thanks for the detailed response :)
And after they learn those and have few fights. They might be ready to research what to choose for next project.
https://docs.python.org/3/library/idle.html#automatic-indent...
So not even you are reading the documentation?
And if IDLE is not good enough for students, Komodo IDE exists for 20 years, VS and VSCode also do a quite good job, PyCharm, as do Emacs and vim.
It isn't as if the alternative JavaScript and Go code is being written without adequate tooling.
Python is used in so many places that’s it’s part of the lingua franca of programming. I’ve worked at multiple ruby shops over the last few years and pythons still been there in force for data applications.
I much prefer other languages (Ruby, Kotlin), but at the end of the day i need to be comfortable with the language that will be spoken for years to come.
I do think the packaging Story in python is nuts. Why does gem just work for Ruby but python's story is such a disaster? Though imo my modern advice is "just use poetry and ignore everything else".
Pythons main draw for me is some combination of:
Type hinting is good enough. It has a big escape hatch to be able to do C stuff if you need to. Numpy. The language is still straightforward enough that beginners can approach it and the experienced can wax reasonably eloquent with it. And it's pervasive.
So when I sit here and I'm like "ugh I need a thing to sit here and hit an api and dump it to a file every day in a cron job, and I don't want to spend a whole day writing this". I go for python. And while go and java and rust etc would be just fine, I still end up taking longer than I'd like.
Somehow python is just the shortest, sanest route to just getting a small to medium sized doodad out the door and running reliably in a small footprint of time without needing to remember boilerplate (java) or think way lower level than I'd like to (go/rust). Python just lets me do it with low cognitive overhead. Sometimes while I'm half-listening to a meeting I'm in!
Honestly my biggest gripe with python is it's really hard to tell early enough when your program is on a trajectory to be too big for python. And I don't mean from a perf perspective or anything, I just mean when it goes from being "easy python" to "oops it's spaghetti now." There's a tipping point and I think even seasoned people end up well past it by the time they pause and rub their eyes and think "ugh I wish this were in java."
That is one of my three big gripes with Python. The other two are the horrible way the 2 to 3 transition was managed and the GIL.
But none of those has driven me to switch to another language, nor do I expect it to. Go seems to be this author's alternative of choice; perhaps if my one goal in life was to write a production network backend without using any dependencies, I might agree, but it isn't, and having done some work with Go I find it gets in my way much more than Python does. I have the same problem with other languages.
In this regard, I find it interesting that the following is currently on the HN front page:
https://news.ycombinator.com/item?id=34179426
TL/DR: Go's network sockets set TCP_NODELAY by default, which is, the article argues, a very bad idea.
Ruby has been actively stripping the stdlib, moving libraries to default and bundled gems.
It might not be a big issue in a small script, but as soon as you get a biggish codebase, with mixins or magical utilities written a couple of years ago by a developer who in the meantime left, it takes hours just to track the control flow in the mess of patched methods, dunder stuff calling nested supers, etc.
To say nothing of big frameworks like DRF. There isn't even an agreed-on way to mark methods that are overridden from a base class.
Plus, simply changing the order of imports can violently change the semantics of the exact same code.
A fetish for hidden magic, state everywhere, and basically global coupling of code vastly override the supposedly simple syntax: it might be easy to read, but it is impossible to understand, locally.
But only those without any means of indirect calls via function pointers or reflection.
Seconded.
These are examples [1] of the scripts that I use on Linux, MacOS, and Windows for producing cross-platform builds. Run the one for the platform you're on, and it will produce stand-alone builds for all the targets (Linux, Windows, MacOS Intel, and MacOS ARM). And the builds are small enough that in many cases for simple tools I commit them straight into the repo for easier usage.
But where would I go? I clicked through hoping to find a good suggestion, and found none.
Python has become the lingua franca of programming, in many contexts, in many fields. You don't have a choice. You have to be able to read it, if you want to read what people are doing. You have to be able to write it, if you want people to read your stuff. It's where the libraries are. It's where stuff is happening. For better or for worse, Python won.
Even if I don't care about any of that, I really don't know where to go.
I really loved perl. I loved the powerful expression and conciseness. I miss it. But perl 5 is old, and it shows -- a lot of good ideas have come along in the last couple decades, and a lot of things that seemed like good ideas at the time really haven't worked out. A decade or so ago, I was excited about perl 6, but it doesn't seem to have worked out.
I don't like python. But I don't know what to replace it with. Javascript and Ruby seem like the serious options to me, and it's hard to take the one seriously, and the other is so niche that that itself feels like a serious drawback. I want a general purpose scripting language that can do small scripts well (Messes allowed! Shortcuts encouraged! Power in a small space!) and grow to large projects well (Thoughtful object system! Good package management! Good support for alternative paradigms!)
I just can't figure out what that would be.
I suppose I have been assuming that the best policy is to do as the Romans for a long time now. Windows apps are C++ (or is it C# now?) because that's how things are over there. Android is Java, or Scala if you must -- at any rate, you hardly get to pick. Iphone requires learning Objective C. Jquery for frontend, or whatever the cool kids are doing; PHP on the back is good enough for most of the web, and it's good enough for you. And as you say, in ML, Python is not optional.
And as I think about it, I've been using specialized languages in specialized contexts for a long time. It seems the knowing the underlying language is only ever part of the problem -- you have to learn the specialized language for what you're doing, whether it's GL for graphics or your web framework's way of doing things, or MFC or .NET, or . . .
Yeah. Small tools for specific purposes, and follow the local ecosystem. Things have been going that way, and it's probably a good answer.
When in Rome, then. I like that answer. Thanks.
It does excellent fuzzy search-as-you-type, and is typically a pinned tab in my browser most of the time.
If JavaScript is your goto language, then ok. But, otherwise, Python is the most used language for writing backend scripts, so it's pretty good at this, but also there's a lot of material online.
It encourages to set up project specific definitions which are saved in the local pyproject.toml file. Keeping everything local and project specific, including the env definition, turns out to be a fantastic boon to reproducibility and sanity of mind.
Everyone will tell you of the "best" (i.e. their favorite) way to handle packages and dependencies. Usually mixed with some sandbox framework. Everything will be broken in some way: nonstandard, convoluted, too slow, cannot handle corner cases, or just way too difficult to understand. Even those labeled "for humans". Everyone will agree the situation is a mess "except for this one way that works": never trust that way, it doesn't really work past trivial cases.
Of course this is just my experience. But I feel after years of battling with Python and trying different things, I've earned the right to say this.
- `conda env create|list|remove` commands to manage them
- `conda activate <env name>` to enter your environment
- `conda deactivate` to return to your base environment
If you want to use a conda environment in jupyter, you must install ipykernel and create a kernel definition for your environment:
conda activate <env name>
mamba install -c conda-forge ipykernel
ipython kernel install --user --name <env name>
---
1. Create a virtual environment named venv
cd $PROJECT_FOLDER
python -m venv venv
source ./venv/bin/activate3. Define and install dependencies
nano requirements.txt
pip install -r requirements.txthttps://docs.conda.io/projects/conda/en/latest/user-guide/ta...
(Lots of the other advice here—mamba excepted, and that might be a good choice—is good for python in general but potentially will cause problems if you are otherwise using anaconda.)
- reference counted objects with predictable scoped destruction. this keeps the maintenance of huge resources quite simple and memory usage steady
- operator overloading (infix, like +/*-)
I really wish other languages (like JS/Go) had this stuff.
However I’d rather not if you value your sanity and want to use typescript, because then you introduce packages and compilers and the whole npm ecosystem which makes building C++ look easy and sane.
Something went off the rails at some point.
So that's still my line of thought, but I'm already regretting typing this on HN.
The language server itself uses a typechecker, so you'd just be building a typechecker that uses another typechecker by a roundabout route.
Though in seriousness I'd presume it would be bad type checker uses language server which uses better type checker, which may help with the problem.
There are multiple python language servers, but if you mean the Microsoft one, well, that just incorporates one of the best of the Python static typecheckers (Microsoft’s pyright)
Personally, I’ve been pretty happy with python, I think it works wonderfully as a glue language (like bash); I.E: you shouldn’t write a lot of it, you should use it for plumbing. Its fantastic for that.
To be honest, this seems like even less of a balanced criticism than the article this overall discussion is based on. A more balanced summary of the valid points might be: "Python has issues that you will probably trip over in certain kinds of applications". Which is true of every language.
> I think it works wonderfully as a glue language
It also works very well as an application language, just not for all types of applications. Which, again, is true of every language.
Here is my take on what the OP is actually trying to say: "I don't want to code in Python any more (because there are newer cooler languages like Go?) and here is my list of reasons for rationalizing my rather irrational decision"
But my bigger reason for avoiding Python when I can is I just think the days of dynamic languages are behind us. Which is to say, we are past the tipping point where the ergonomics of adding typing are less costly than the benefits, and that applies even for short scripting use cases (in part because so many short scripts grow their way into real production code that needs to be maintained).
I went down the rabbit hole of adding type hints but at the end of the rabbit hole it was a lot of work and the value realised was still only 50% of that from having a real type system. Vast numbers of type errors still not getting caught in my editor, autocompletion stymied at shallow points where the type system gets lost, and as the weight of the project grows the tools like MyPy getting slower and slower as they have to process massive amounts of the dependency tree just to infer the type of the single line you are typing.
These days even for short scripts I am preferring to write them in languages like Groovy which get me all the benefits of Python from the dynamic language point of view but built on a foundation of a real type system which means I have a pathway to grow the code into full static typing using any of the JVM languages if I want / need to. And it also largely solves the problem with performance.
Go is the way to better backend, CPU and memory optimized.
I read an article that Dropbox save thousands just by change from Python to Go.
It's difficult, especially handling shared variables in go routines, but it's worth it.
Go was pretty expressly aimed at the spot where, at the time, Python was seen as too inefficient but C++ was seen as too much complexity.
Everyone loves to hate it, but you gotta use it.
I disagree about the documentation/syntax/std lib gripes, but everything else is a pretty reasonable issue.
> ...
> Python sucks. I mean the syntax itself.
So author notices that syntax sucks afters years of usage?
It would be swell if rationalizing the packaging story were a priority for 3.12.
> Python’s documentation sucks
Dead giveaway. Well, it doesn't suck. It's pretty great, pretty comprehensive. OH... Wait, ot isn't formatted with a index pane. that's why it sucks. The author probably has problems with the font-kerning too.
> Every project seems to use a different tool and it’s a massive headache
Um, no. Everything really uses pip. I don't even really like pip, but everyone uses it so I use it. You know why? Because it's never, ever a pain in anything at all. It just works.
> Python’s standard library sucks
What? is this satire?
> Python is huge
This has got to be satire. Author prefers "go". Nothing wrong with go, but nothing wrong with Python either.
> Python syntax sucks.
Nuts! this guys is legit insane. The only really controversial thing is the whitespace-indent vs. delimited thing. Guess what? I really dislike the indentation scheme. You could have a reasonable debate over that relatively unique syntax scheme. But the entire syntax as a whole is cleverly regular, predictable and tidy.
> Python is slow
Well, as the author said, "Python has been my go-to language for a quick bit of scripting". Slow is a perfectly acceptable trade-off there. And you could certainly come up with a different set of trades that also make sense. To say "SUCKS" implies it's just stupid and sub-optimal everywhere; a lose-lose-lose-lose. Which it isn't.
> It’s like everything under the kitchen sink has been jammed in.
I though you said that the standard library "sucked"; is there too much sink or too little? "let that sink in"
The author seems to be infatuated with javascript and go (at the moment), but neither is really in the same niche as python. That doesn't make any of those other choices "suck".
Larry Ellison and his company and products suck. Software patent trolls suck. Python does not "suck" because you like other things at the moment.
the packaging ecosystem alone is enough to make anyone mad. I maintained a production system in python for a few years a while back and code refactoring was extremely painful.
I hope I'll never touch python again.
Python remains the most popular programming language worldwide.
The only thing that keeps Python alive and well is the fact that many people don't know anything else -- and never will know anything else -- and that's one of the reasons it's widely taught in universities. The AI/ML stuff can be replaced with its underlying C/C++/Rust libraries in a week so that's not an argument in Python's favor at all.
I wish people stopped pretending Python is OK. It very much is not. It's a collective delusion kept alive by network effects.