An experienced Python developer writes practical advice on Python packaging and installation, plus posts on htmx, XML, and EU cookie rules.
HN commenters praise it as an excellent source of advice for Python users, especially its packaging and installation series.
> "React" has been around for 10 years but in practice its been 3.5 different frameworks
> the class version (still close enough to original)
React.createClass existed because React is so old that not every browser supported native classes, and it was ditched when browser support improved. It was a relatively seamless transition. The rest of your bullet points are basically restating what we've already discussed. There have been two major changes in the past decade: hooks and server components. Again, I'm fine with two changes over the course of more than a decade.
To give you an example of a Go project that is roughly the same age as React and has introduced major breaking changes take a look at InfluxDB. It went from using SQL and InfluxQL as a query language in v1, to Flux in v2 as the headlining feature, then back to SQL and InfluxQL in version 3 recently [0].
> You can't use more than one context in React classes
You can, it just requires render props which are verbose (as I've already stated). There's a whole section of the legacy docs on this. This was one of the many motivations for the creation of hooks.
> 10 different popular libraries for manipulating standard library collections
Not really. Lodash is obviously the standard choice, and at one point Underscore had a bit of a following too. We wouldn't need these libraries if TC39 didn't drag its feet implementing the standard library, but browser technology has many stakeholders so it's a slow process.
> In…
A little over a year ago I was struggling with python related to packaging and managing my own dependencies. I found a blog post called "Relieving your Python packaging pain"[0] that piqued my interest with its simplicity. A couple of days later, the author released another post called "Why not tell people to 'simply' use pyenv, poetry, pipx, or anaconda"[1], which included the how-to steps outlined in their first post, and generated a sizeable discussion[2] on HN. Being on a Mac, this really has made things so much easier for me. I'm not a professional developer by any means, but more like a hobbiest+ as I make things to help automate away some pain points within the small company I work for.
[0] https://www.bitecode.dev/p/relieving-your-python-packaging-pain [1] https://www.bitecode.dev/p/why-not-tell-people-to-simply-use [2] https://news.ycombinator.com/item?id=35379008
This pair of articles is excellent, both for good practical advice about installing Python packages, and for its general attitude about how to teach difficult things to large groups of people:
https://www.bitecode.dev/p/relieving-your-python-packaging-pain
https://www.bitecode.dev/p/why-not-tell-people-to-simply-use
Every single decision point or edge case represents permanent failure for hudreds of people and intense frustration for thousands. Of course, none of this is really to do with Python the language. It's more about the wide userbase, large set of packages and use cases, and overlapping generations of legacy tools. But most of it isn't C/C++/Fortran's fault either.
1. Not sure what you mean? "is irrelevant to OPs problem" -> op advises to not use conda as a solution for Python packaging
2. This is easier than what you propose, because conda will install the python version for the env on the fly (including the patch version):
conda create -n myproject python=3.9.4
conda activate myproject
NB. if we're being pedantic, conda and anaconda are different
Yep, should be minor, but I chose to use the same language as the article [1]
[1] https://www.bitecode.dev/i/110377053/dont-install-the-latest-major-version-of-python
Just go to read: https://www.bitecode.dev/p/relieving-your-python-packaging-pain
TL; DR
The reason why we need virtual this and that in python is that some work in one and some work in the others. This is particularly problematic in macOS where sometimes the system fall back to the default (somewhat default) python compiler. I even have script to check version and lots of environment for running different program.
It is a mess.
After this magic, is there a new packaging environment, procedure, ... for the rest of us?
99% of everything ever written is crap, so you need filtering the huge quantity of brain manure the humanity keeps producing.
And hand written blogs by somebody for several years is very high in my filter list to check out something.
So I care very much about your blog.
Besides, the best way to make sure there is more quality content in the world is to produce it. And that's why I write https://bitecode.dev. Because I want others to have what I wish I had when I needed it.