It seems to have kept a lot of good things from python, but fixes many quirks:
- slicing with index or with index+length ? Well, both apparently!
- len() is a method
- ranges and slices have the same syntax
- you can use | to avoid the indentation hell that comes with '''
- true, false and none don't have an upper case first letter
- the lambda design allow for multi lines, despite the language being heavily biased toward statements. And it's using "=>".
- circular imports do not cause errors
- explicit export, although i'd prefer it to be opt in
- lua style ffi
- mapping on dict key/values is the simple case
- CYON is quite interesting
- and of course concurrency and perf from the start
But some of them will cause big troubles:
"errors are values and do not propogate up the call stack by default. Users are not forced to handle errors unless the error value is passed to a typed destination."
Yeah, silent errors in bash scripting taught me I really don't want that.
"The shorthand method for calling functions omits parentheses and commas"
The reason I still can't parse Ruby after 15 years.
No OP but similar situation. It's easy to make the difference: I've been in terribly stressfull situations before. I went to live in Mali, started business, got Malaria, lost everything to the war and had to start all over, going back to my country.
It's not the same. Covid got me bad.
But strangely, only after the third dose of vaccine. Right after it in fact, and ever since.
But it's possible we will learn we are coupounding effects on a lot of fronts: stress from the situation, covid itself, unexpected side effects from the vaccine, and maybe something else.
Hard to tell.
But yeah, this is not regular run of off the mill, stress response.
- "-m" was introduced.
- Wheel replaced eggs.
- Manylinux target now exists.
- pypi was scaled uo, a new api
introduced and 2fa added.
- setup.py got replaced by
setup.cfg and now
pyproject.toml is gaining speed.
- the py launcher is a thing.
- Import priority changed.
- Import lib changed.
- Zipapps were added.
- Venv ships with python.
- Pip replaced easy_install,
then ensurepip was created.
- The new dependancy solver
was funded.
- Distutils has been sunsetted.
Setuptools is on its way.
This doesn't include the dozens of third party projects that target improving package that came out in the last 2 decades. Pip-tools by itself has changed the game.
A lot has been done, and the situation is 10 times better than it used to be. It is still bad, but not because nothing was done, simply because there is still a lot to do.
People dont realize the sheer scale of the task, and the inertia that comes with a language as successful and old as python.
You have a language that is 4 years older than java, highly dynamic, yet uses fortran/c/assembly code in very popular lib (scipy/numpy) accross all popular OS, and webassembly and arm, in 32 and 64 bits. People routinely install multiple versions of python on their machine, linux repos freeze the upgrades and split the packages, mac and windows stores ship broken versions, and half the python userbase is composed of people that are not professional coders that can't use a terminal. Of course companies will complain if you change anything that breaks their 5 years old server, and devs will complain if they don't get the last new great feature.
It's a really, really hard problem, dealt by a FOSS community that 10 years ago was still running on mostly volunteers and the budget of a small start up. Of course, just to get heat by comments on social media and no thanks for all the effort, as if you own total strangers your free work, with no flaws on top of that.
Not to mention you can imagine packaging is not the only things the core devs have to work on.
> This doesn't include the dozens of third party projects that target improving package that came out in the last 2 decades.
One would think that two decades of package improvement initiatives should have been a strong enough signal to PSF to prioritize building an official standard solution.
A third party can ignore legacy. It can break stuff. It can avoid supporting platform. It can have a big bug and push a fix the day later. It can skip red tapes. It can document after the fact. It can drop features the next year. It can requires pypi dependancies when the stdlib is not sufficient. It can be by a single author that don't have to ask anybody what they think about before creating something. It can skip security issues and focus on practicality.
CPython cannot.
So any change to the packaging story will always take years for the smalles thing.
That's the same for removing the GIL: touching the c api is a huge deal for the scientific and machine learning stack.
That's why requests has never been included in python despite being vendored with pip: you can never update it fast enough once it's in the stdlib.
That's why we don't have node_modules equivalent yet: autoloading code in the current directory would be a big security risk for a language that is included in many os by default so we need a good design.
Don't assume the team is incompetent or deaf. Given what has already been achieved, that would be a total mismatch.
> Don't assume the team is incompetent or deaf. Given what has already been achieved, that would be a total mismatch.
I am not making any such assumptions (and I don't think most sane people are either); people are just unhappy with lack of an officially standard solution given that it was clear quite a while ago that it was needed. I also don't understand the comparison with GIL or C API - changes to them could be a breaking change whereas a fresh officially recommended solution would by definition be a new solution i.e. not a breaking change. It can be introduced and it can go through iterations while people can take their time to migrate from the myriad of third-party packages (or not, if they are happy with what they are using).
What people, who don't want to deal with deciding between or putting their faith in longevity of third-party tools, are looking for is a solution that is official, part of the standard library and is managed by PSF. That way the decision is basically made for them e.g. like it is done in Rust via cargo.
Fresh now solutions is what put us in this situation: distutis2 was fresh, setuptools was fresh, pip was fresh, wheels were fresh... So now you have a lot of complexity that come from having a lot of solutions in parallel that are slow to sunset.
But the dirty secret of python packaging is that most of the problem don't come from packaging, but from boostrapping python. And this is a huge can of worms I didn't even mentioned.
Also, plenty of things require the participations of other communities like debian splitting pip out of the main package or anaconda not being compatible with pip.
All in all, the way you hand wave the problem is typical from the critics that have a very narrow view of the situation.
>Don't assume the team is incompetent or deaf. Given what has already been achieved, that would be a total mismatch
To be perfectly clear, I don't think that. I just think its a missed opportunity over the years to better ways of environment and package management. For instance, on the folder auto loading code: make it a feature of only virtual environments. I know python can detect that its in one. Or engage with distros not to build Python to allow this. They already do custom builds with it (its always missing something from a standard Python installation after all).
Node also has madness that Python does not, like support for circular dependencies. I would definitely not point to Node as a positive example like Cargo.
Cargo is the golden standard, but reaching that level is going to take 10 years at least. I'm not kidding, this is what will be needed to solve all the road blocks.
The first thing we need is a whole ne way of installing python, because half of the problems stems from that. That's just a huge endeavor.
Unlike netflix, Disney+ has a good incentive to never become profitable. It pays enormous licensing fees to its parent company. This means the profits flows to there, and they don't pay a cent of taxes.
Now you are going to say, but doesn't "The Walt Disney Company", the parent of Disney+, then pay all the taxes?
No, because this company is located in Delaware, which means it's virtually exempt of taxes as long as it makes only money from activities outside of Delaware. Which is does, since it's only selling IP to other companies, like the entity managing Disney+ which has it's headquarters in California.
Well, most people in math and science majors can pass an arts and humanities major. The opposite is not necessarily true.
Anecdotally, I can easily engage in talks about literature, politics and art with my friends coming from a biology or physics background. I can hardly do so with my friends with a major in French or Sociology. When we mix them together, the debate is always animated when we talk about philosophy, a specific author or book, and even painting. If we speak about GPT3 or the CERN, suddenly the table is divided in two.
You can have some seriously in-depth discussions in sociology or philosophy as well, that would be hard to follow for someone with just a STEM background. The kind of sociology or philosophy one would discuss without preparation or reading with friends is not really comparable with the academic disciplines. It is just armchair philosophy/sociology.
I have a feeling many technically minded people would struggle to read and write an essay about Heidegger or Habermas. In fact, I doubt most people are even aware of that type of philosophy due to not having actually delved into it very deeply, and yet as outsiders to such fields they feel confident in making claims that those fields are "easier." (And usually there is also an implication that this being "easier" is an indication of those fields being less serious or worthwhile.)
If my non stem sample would be able to engage with armchair science in the same way that the stem sample can engage with armchair philosophy, I would agree with you.
However, it's not the case.
I also find more stem people reading entry level materials in philosophy around me (like Moral letters to Lucilius), that I will find non stem people ready entry level materials in science (like A brief history of time).
The ratio is hugely disproportionate, and while I understand this is all anecdotal, I have a large and very diverse social circle to observe, spanning on wide areas of age, social backgrounds, political preferences, sexual orientation and jobs.
The one that shared an era with pokemon version 1, on the original black and white gameboy.
Because it was so clear from the beginning, even if emoji didn't exist, cpu had no core, ruby hasn't been invented yet, and people were sharing the source code on floppy disk.
The walrus got heat. F-string got heat. match/case got heat.
Unicode in python 3 got 15 years of trolling.
Every single time you make a proposal, you have to make a compromise between:
- what the infrastructure and style of the language allows
- the resources you have
- the desire for staying compat
- the desire for staying modern
- the pressure of people wanting a new toy
- the pressure of people hating any kinda change
You cannot flip a switch and "make the language better".
Seriously, python was born in 1991, 4 years BEFORE Java existed. And it barely had any funding until 2010.
Insight is 20/20 but this is not how tech works. You are limited by knowledge, resources, politics, legacy, compatibility commitment and so on.
Not to mention you can simply get it wrong.
Would have been funny if the whole world moved out of unicode and we got stuck with it forever. Usually, you know something is a standard only when people complain you adopted it too late because everyone else did.
Like Java that used XML for all serialization and got suck with it for 15 years while we all moved to JSON. Or utf-7 that is still used by IMAP because they did the wrong call.
Yes, utf-7. What, you though utf8 was the only unicode standard? No, no, no. There are utf-7, utf-8, utf-16 (JS uses that) and utf-32 (C# uses that) in use. And more exist that abandoned.
People seems to be under the illusion that this stuff is easy, or obvious. Sure. In 2022.
Everything about text has been a fight for death to this day, for all programming languages. This includes formatting.
We have "%s" because... of printf() in C. Let that sinks in.
> People seems to be under the illusion that this stuff is easy, or obvious. Sure. In 2022.
I mentioned that Ruby had this for "upwards of 20 years." I was vague on the timeline because I didn't know for sure how long it had been. After reading your message I looked into it and it looks like Ruby supported "#{expr}" since at least Ruby 0.95, in 1995: https://github.com/nobu/ruby-1.0/blob/master/sample/tkdialog...
This is not to mention Perl, awk, shell, and Tcl, which had syntax like $FOO for even longer.
Ruby's solution existed before all of the following PEPs, which added different varieties of string formatting to Python:
- PEP 215 – String Interpolation (2000) (superseded by PEP 292)
- PEP 292 – Simpler String Substitutions (2002), added string.Template()
- PEP 3101 – Advanced String Formatting (2006), added str.format()
- PEP 498 – Literal String Interpolation (2015), added f''
I get that language design is hard, and it's difficult to have the final answer right away. But it's not as if this idea was unknown or untested when Python introduced other home-grown solutions. When Python proposed f strings in 2015, it imitated a design that had been in Ruby for almost 20 years at that point.
> There are utf-7, utf-8, utf-16 (JS uses that) and utf-32 (C# uses that) in use. And more exist that abandoned.
Javascript is just UCS-2 that exposes UTF-16 internals (eg. surrogates) for your application logic to process if you want to do anything correct with the string (other than pass it around unmodified). Maybe it's "abandoned" in the sense that UTF-16 nominally supersedes it, but yea, it's actually just UCS-2. Lots of the stuff in early 1990s used UCS-2 (eg NTFS).
This also goes to your point about living with "wrong" decisions from the past due to compatibility and inertia. Nobody knew we needed more than 2^16 code points (bet most of you don't know about the Kangxi Dictionary...)
- slicing with index or with index+length ? Well, both apparently!
- len() is a method
- ranges and slices have the same syntax
- you can use | to avoid the indentation hell that comes with '''
- true, false and none don't have an upper case first letter
- the lambda design allow for multi lines, despite the language being heavily biased toward statements. And it's using "=>".
- circular imports do not cause errors
- explicit export, although i'd prefer it to be opt in
- lua style ffi
- mapping on dict key/values is the simple case
- CYON is quite interesting
- and of course concurrency and perf from the start
But some of them will cause big troubles:
"errors are values and do not propogate up the call stack by default. Users are not forced to handle errors unless the error value is passed to a typed destination."
Yeah, silent errors in bash scripting taught me I really don't want that.
"The shorthand method for calling functions omits parentheses and commas"
The reason I still can't parse Ruby after 15 years.