> "why did you close my question as a duplicate of how to do X with a list? I clearly asked how to do it with a tuple!" (for values of X where you do it the same way.)
This is a great example of a question that should not be closed as a duplicate. Lists are not tuples in Python, regardless of how similar potential answers may be.
I'm talking here about cases (which is basically all of them) where the first person to ask was simply needlessly specific. Or where the canonical has the list as an incidental detail and the next person insists that the answers won't work because this code has a tuple, you see, and doesn't see the merit in trying them.
If you imagine that the answer should be re-written from scratch to explain that the approach will be the same, you have fundamentally misunderstood the purpose of the site. Abstraction of contextually unimportant details is supposed to be an essential skill for programmers.
It's less meaningful than you think. Widespread prejudice does give you signal on public sentiment, but it doesn't give you much signal on whether the prejudice happens to coincide with reality or not, compared to other methods. People should be open to having their prejudices corrected by more relevant information.
Google doesn't allow you to recover a Google account using only your recovery email address. Despite its name, the recovery email address is not used to recover Google accounts AFAICT, it's only used to receive notifications about security-related events.
I guess we just have to wait a little while, until that method using Calibre also does no longer work, because either Kobo or Adobe or someone else wants to make sure it does not work.
I strongly disagree. Python 2 had no bytes type to get rid of. It had a string type that could not handle code points above U+00FF at all, and could not handle code points above U+007F very well. In addition, Python 2 had a Unicode type, and the types would get automatically converted to each other and/or encoded/decoded, often incorrectly, and sometimes throwing runtime exceptions.
Python 3 introduced the bytes type that you like so much. It sounds like you would enjoy a Python 4 with only a bytes type and no string type, and presumably with a strong convention to only use UTF-8 or with required encoding arguments everywhere.
In both Python 2 and Python 3, you still have to learn how to handle grapheme clusters carefully.
If you're talking about free-as-in-freedom software, promoted by Richard Stallman and the FSF, then they have always been clear that Free software must not forbid commercial usage or require payment. Vendors are perfectly free to sell copies of Free software if they wish, but the license cannot forbid making copies and derivatives, even for commercial usage. See:
The principles predate modern SaaS by decades. You can see it in the wording of the FAQ you linked. It keeps using the word "distribute" - meaning giving people a copy of the software to put on their own computer - as if that were the only way of commercializing software. Which it pretty much was in the 1980s.
There has been some revision over time, but there's an argument to be made that small revisions are inadequate to keep up with the sea change in how computing works that's happened since the turn of the century. The elephant in the room here is that SaaS, and especially cloud computing, has pretty well undermined the practical foundation for how the Free Software model was supposed to work for people who are trying to make a living selling Free Software.
Doesn't the AGPL from nearly 20 years ago address SaaS? Given that basically every big tech company bans AGPL licensed software, it seems like it provides adequate protection.
Because everyone was always a user in the definition of free software! Because it's free as in free speech.. In the first bulletin where the definition was made, Stallman envisioned no restrictions on distribution and a user being a business was entirely unrelated to how compensation were to occur: https://www.gnu.org/bulletins/bull1.txt
In the very early days they were always the same, but differences between use and distribution emerged quickly.
For example, there are zero restrictions, duties, or obligations on using the software. But once you distribute changes (or in the AGPL case allow other people to use your changes), duties and obligations attach.
>In the very early days they were always the same, but differences between use and distribution emerged quickly.
I think those concerns existed at the time of the writing of the first bulletin, if you read how they were expecting to be compensated. See the part titled "So, how could programmers make a living?".
>For example, there are zero restrictions, duties, or obligations on using the software. But once you distribute changes (or in the AGPL case allow other people to use your changes), duties and obligations attach.
Yep, the duty and obligation to redistribute, as mentioned in the bulletin above - but without a single company being the sole arbiter or commercializer of the source, as defined in the Free Software Definition you mention elsewhere. Freely, as in free speech.. A quote from the original bulletin:
```
This means much more than just saving everyone the price of a license.
It means that much wasteful duplication of system programming effort
will be avoided. This effort can go instead into advancing the state
of the art.
Complete system sources will be available to everyone. As a result, a
user who needs changes in the system will always be free to make them
himself, or hire any available programmer or company to make them for
him. Users will no longer be at the mercy of one programmer or
company which owns the sources and is in sole position to make
changes.
```
In the SaaS era, freedom is impinged not because hyperscalers make money off of free software. That was always the intended goal, because it isn't freedom like free beer or simply 'non-commercial uses'. Freedom is impinged because modifications of the software aren't redistributed if distribution is only done over generated artifacts on a network. AGPL is specifically for networked software like this.
Unless you're implying that the GNU foundation, Richard Stallman, or the free software movement generally ever viewed even narrowly commercially restrictive licenses as free software. Which you can tell from the source documents and all others in this comment thread, that is obviously not the case.
The world changes, everything changes. Already 20 years ago Stallman saw that his original idea was abused (tivoization etc.), hence GPLv3. In the web era we have a completely different set of issues to deal with, and one of them is the killing of incentive by the big three public cloud providers.
Back in RMS days, he advocated, for example, a RedHat-style business model where you sell Free Software with services. But when AWS takes your project and releases it as their service, good luck competing with them. This is a very real problem.
I didn’t think the idea of creating free software was to monetize it. If you create a software as “free”, then anyone including hyper scalers can use it.
Put out a restricted license if you don’t want hyperscalers to offer it as a service. Although they have enough software engineering talent to use the old version to create and maintain a fork (e.g. valkey, opensearch, etc.).
If you have uv installed, trying out Python 3.14 is as simple as running this command:
$ uvx python@3.14
Python 3.14.0 (main, Oct 7 2025, 15:35:21) [Clang 20.1.4 ] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>>
That was beautifully easy! (Make sure you're on the latest version of uv first (v0.9.0))
It works well. I didn’t know what language it was written in, nor did I care, until months after starting to use uv. I still don’t care.
Sure, it’s a bit silly (I don’t think I’d go as far as “pathetic”, just silly) that the implementation language is above the fold in the description/readme. That’s a cosmetic gripe; it’s still a good tool.
Rust or not, writing a tool to manage installation of a language platform in something other than the language it manages is a good idea, it avoids bootstrap problems. Using something statically-ish linked is also good; it avoids problems caused by the bootstrap dependencies. Tools like pyenv have taught us that shell is a poor choice of bootstrap language. Rust seems as good a choice as any given that.
The humorous thing to me is how keenly aware of performance issues w/ Python the community is, but they continue to trudge along with it and develop tooling to support their Python efforts in other languages (C, Rust, Java, etc.) instead of just writing the entire program in another language.
Nothing in my post is about performance (of Python, Rust, or anything else).
While e.g. numpy might support your claim that Python being slow is reason to abandon it, I don’t think uv does.
My understanding is that the poor performance of pip is due to two things: a combination of slow-in-any-language solver and query/probe behavior that they’re stuck with for backwards compatibility reasons, and very poorly parallelized network and disk IO.
Parallel IO and better disk cache behavior are options because uv is a new system not tied to pip’s behavior and expectations, not because uv is a new system in rust.
Again, I think Rust is a fine choice here with some strengths in the dev-tools area, but those strengths are not (opinion, based on poking through a fair amount of uv’s code and reading Astral blog posts) the reason for uv’s success. The behavior choices that make it good are well supported in most languages.
This is a great example of a question that should not be closed as a duplicate. Lists are not tuples in Python, regardless of how similar potential answers may be.
reply