Python’s new t-strings

its not easy to learn. its a challenge even getting it installed and running. what even is a venv? how do you explain that to a beginner?

python is popular because its what teachers teach.

You don’t need to teach it to a beginner. The first of learning doesn’t need more than the standard library and when you need more than that you’re either giving them the single command necessary to run or, more likely, having them use a template project where a tool like Poetry is doing that automatically.

What this usually hits isn’t that managing Python packages is hard in 2025 but that many people do not learn how their operating system works conceptually until the first time they learn to program and it’s easy to conflate that with the first language you learn.

On modern Linux you can type `python` at the command prompt and get a REPL. On Windows you download an installer from the official website (just like one usually does to install anything on Windows), then use `py` at the command prompt.

You don't need to `import` anything to start teaching Python. Even then you can do quite a lot with the standard library. Even then, unless you're using 3.11 or later on Linux you can let Pip install with `--user` until you actually need to isolate things between projects. (And even with new Python on Linux, the instructor can typically avert this by just installing a separate Python in `/usr/local/bin` for example. Yes, that's "cheating", depending on the classroom environment. But that's part of the point: installation hurdles are hurdles for self-learners, not for students.)

You only need to learn about virtual environments once you have projects with mutually conflicting dependencies, and/or once you're at a point where you're ready to publish your own software and should be learning proper testing and development practices. (Which will be largely orthogonal to programming, and not trivial, in any language.)

And when your students do get to that point, you can give them a link such as https://chriswarrick.com/blog/2018/09/04/python-virtual-envi... .

Teachers teach Python because it's easy to teach while still being relevant to the real world, in particular because boilerplate is minimized. You don't have to explain jargon-y keywords like "public" or "static" up front. You don't have to use classes for quite some time (if ever, really). You can express iteration naturally. Types are naturally thought of in terms of capabilities.

In my mind, Python has all the pedagogical advantages of Lisp, plus enough syntactic cues to prevent getting "lost in a sea of parentheses". (Of course, it lacks plenty of other nice Lisp-family features.)

someone learning python as their first language knows so little its perfectly fine to let them pollute their global environment. Someone who knows other languages can understand what venv is for.

Instead they can type python to open a shell and use python to immediately run their file.

It has become successful largely because it has always had really good foreign function interface. If you have a scientific or mathematical library laying around in C, then you could wire it up to Python, and then suddenly you have all the flexibility of a (fairly clean) scripting language to orchestrate your high speed C.

Good examples of this are numpy and tensorflow.

If someone is challenged figuring out a venv and they're not an absolute beginner, perhaps they aren't cut out to work in technology. There are countless subjects in the field more challenging and complicated to wrap one's brain around.

Also, in 2025, just use uv.

> In my mind, Python has all the pedagogical advantages of Lisp, plus enough syntactic cues to prevent getting "lost in a sea of parentheses". (Of course, it lacks plenty of other nice Lisp-family features.)

What you say here reminds me of something Peter Norvig said 15 years ago on this site: https://news.ycombinator.com/item?id=1803815

> Peter Norvig here. I came to Python not because I thought it was a better/acceptable/pragmatic Lisp, but because it was better pseudocode. Several students claimed that they had a hard time mapping from the pseudocode in my AI textbook to the Lisp code that Russell and I had online. So I looked for the language that was most like our pseudocode, and found that Python was the best match. Then I had to teach myself enough Python to implement the examples from the textbook. I found that Python was very nice for certain types of small problems, and had the libraries I needed to integrate with lots of other stuff, at Google and elsewhere on the net.

Basically, that it's better pedagogically because it looks like pseudo-code and it's easy to get up and running quickly.

Let me introduce you to uv[0]. And yes it does say something that this tool isn't written in Python, but I'd say there's even more to be said that so many are trying to support Python.

[0] https://docs.astral.sh/uv/

yeah the reason why that's not an answer is because another half of users will say use poetry. if you want to do bioinformatics, people will insist on conda. then your team will say "use rye" and these strategies are somewhat compatible but ultimately mutually incompatible in ways that will drive you mad every time you hit a tiny snag that nonetheless grinds your attempt to just fucking run code to a halt.

> You don’t need to teach it to a beginner.

gp's claim was:

> Python is better because it's easy for people to learn,

i believe then we agree: it is not.

tensorflow is atrocious, which is why it's basically dead in favor of (py)torch.

Which is valid, but frustrating to see it lead to actual adoption outside of pedagogy. That property is entirely orthogonal to, almost at odds with, what makes a good programming language for medium to large production quality applications.

If we used that logic elsewhere in life we’d all be playing the flute and cycling around on tricycles and balance bikes. But for some reason in tech it’s all about Hello World.

> You don't have to explain jargon-y keywords like "public" or "static" up front.

patently not true. you dont get too far into python -- especially if you are reading (or copypastaing) other People's code -- before you see if __name__ == "__main__" and any potential future programmer will rightfully ask "what the absolute fuck is this"

even "def" is kind of a weird fucking keyword.

Don't get me started about teaching beginners which datatypes are pass by reference and which are pass by value.

try explaining to an elementary school student why

    def foo(a):
       a = a + 1

doesn't change the caller's variable but

    def bar(a):
       a.append(1)

does.

The story of the winner being scrapy market entrants that are lower-cost (...of learning, in the case of python) and good-enough-quality (...than OCaml, Lisps, Haskel, definitely not JS or Java) is not a new one. I don't subscribe to your analogies.

In my experience people have to first figure out what the hell numpy is and how to get it (venv, conda, pip, uv, uvx, …) because python arrays are shit, and so people fix that wart with an external C library. Then they notice that some other dependency requires a previous python version, but their python is installed globally and other dependencies were installed for that. These are uniquely python-specific problems. Lisp doesn’t have those problems

> they're not an absolute beginner

gp's claim is not "its easy to learn". It's not just the concept -- it's the ergonomics, absolutely terrible footguns (especially when dealing with global wheels that can screw up your running system), and the hidden state.

> perfectly fine

It's not, because you can fuck up system/unrelated app python dependencies and in extreme cases have to reinstall OS. Thankfully as developers migrate away from python/adopt strategies like flatpak this is less of a problem.

Other PLs do not have this problem.

> Don't get me started about teaching beginners which datatypes are pass by reference and which are pass by value.

If they are beginners to programming, you wouldn't teach them those terms in the context of Python, because neither of those terms map to Python argument passing; Python has one form of argument passing, and it doesn't map closely to the intuition that experienced programmers in languages that have pass by reference and pass by value have about those things. Likewise, the only thing you'd teach someone new to Python that is experienced in languages where those terms are useful is that that distinction is irrelevant in Python, which is pass by assignment (sometimes also called pass by object reference, but pass by assignment is a much more useful description IMO, because argument passing works exactly like assignment to a new variable name.)

> try explaining to an elementary school student why

    def foo(a):
       a = a + 1

> doesn't change the caller's variable but

    def bar(a):
       a.append(1)

> does.

But, that's easy, if you've first taught them how variables, assignment, and mutation work in Python without getting function calls in the way, because it is exactly the same as this

  a = 1
  b = a
  b = a + 1
  print(f"{a=}, {b=}")

vs.

  a = [1]
  b = a
  b.append[1]
  print(f"{a=}, {b=}")

Argument passing is just assignment to a new variable that exists in the scope of the function. Methods which mutate an object affect the object no matter what variable you access it from, assignment operations affect only the variable they assign to. That's exactly the same behavior in one scope as it is between the function and caller scopes.

And this distinction has nothing to do with data types, but only with the operations performed (the only connection to data types is that immutable types have no mutation operations in the first place.) You can tell its not about data types because you can use the same types as the second excerpt, and the operations of the first, and get the same results as the first (which shares operations) and not the second (which shares datatypes):

  a = [1]
  b = a
  b = b + [1]
  print(f"{a=}, {b=}")

If you understand how assignment and mutation works in one scope, you understand how argument passing works. Trying to teach a distinction that exists between how different operations affect variables that initially reference the same object as a distinction about how datatypes are passed as arguments is confusing, because you as a teacher are presenting the source of the difference in behavior as originating in a completely different place than where it actually comes from. That's not a problem with Python being complex, it is a problem with you taking a very simple thing and making it complex by ascribing it to a source that is completely irrelevant to what is actually going on.

When would you want to interface between a specific project and the global Python environment running your system? If there's ever a time when "lock the project into a venv and don't cross-contaminate its dependencies with the global Python environment" isn't the answer, that sounds like a corner case. Let each project be its thing by itself.

> you dont get too far into python -- especially if you are reading (or copypastaing) other People's code -- before you see if __name__ == "__main__"

First off, if you are teaching someone, you are showing that person the code, and not allowing copy-and-paste.

Second, no, that comes up much less often than you'd expect.

Third, it's the same as `if value == 'example':`. Underscores are not jargon.

Fourth, it's trivially searchable. That's the part where you can copy and paste - into a search engine, which will immediately find you several competent explanations such as https://stackoverflow.com/questions/419163 .

> even "def" is kind of a weird fucking keyword.

Admittedly a poor choice, but not a deal breaker. You need the concept of functions to do programming. But you don't need the concept of data hiding, nor do you need any of the multiple, barely-related concepts described by the term "static".

> Don't get me started about teaching beginners which datatypes are pass by reference and which are pass by value.

There's nothing to explain. They are all pass by value, per the strict meaning of those terms.

Those terms have been widely seen as less than ideal for decades, however, because they fail to account for variables with reference semantics (i.e., what Python uses - which are sometimes called "names"). A more modern term is "pass by assignment", which correctly describes all variable passing in Python: passing an argument to a parameter is a form of assignment, and works the same way as assigning a value to a name.

This is far less complex than C#, in which user-defined types may have either value semantics or reference semantics, and which supports both pass by assignment and two separate, true forms of pass by reference (for initialization and for modifying an existing object). And certainly it's less complex than whatever C++ is doing (see e.g. https://langdev.stackexchange.com/questions/3798 ).

> try explaining to an elementary school student why

First: if someone gives you a bag with three apples in it, you can put another apple in the bag and give it back, and the other person will have a bag with four apples in it. But if you add 3 + 1, that doesn't change the meaning of 3. These are simple ideas that an elementary school student already understands.

Second: from extensive experience teaching beginners (never mind that you are moving the goalposts now), it makes no sense to get into the theory. It's not helpful. A student who can ask about this has already lost the plot, because the two examples use completely different syntax (a method call versus an assignment) so they shouldn't be expected to work similarly. You avoid this problem by using more precise language early on. "Change" is not an appropriate word here.

Third: you give this example because you think that `bar` (and you imply by your naming that a list is being passed) demonstrates pass by reference. This is simply incorrect. Please read https://nedbatchelder.com/text/names1.html.

Fourth: your use of profanity and the overall tone of your writing suggests that you simply don't like the fact that Python works the way that it does. This is not a good look IMO.

Just for the record, I've been in variations of this discussion countless times. I know what I'm talking about. All links above are in my bookmarks.

> what the hell numpy is

Did they try using a search engine? But more to the point, if they don't understand what it is, how did they find out it exists?

> how to get it (venv, conda, pip, uv, uvx, …)

uvx is a command from the same program as uv; venv is not a way to obtain packages; and the choice here isn't a real stumbling block.

> because python arrays are shit

I can't say I've seen many people complain about the standard library `array` module; indeed it doesn't seem like many people are aware it exists in the first place.

If you're talking about lists then they serve a completely different purpose. But your use of profanity suggests to me that you don't have any actual concrete criticism here.

> Then they notice that some other dependency requires a previous python version

Where did this other dependency come from in the first place? How did they get here from a starting point of dissatisfaction with the Python standard library?

> but their python is installed globally and other dependencies were installed for that.

... and that's where actual environment management comes in, yes. Sometimes you have to do that. But this has nothing to do with teaching Python. You have necessarily learned quite a bit by the time this is a real concern, and if you were taught properly then you can self-study everything else you need.

> These are uniquely python-specific problems.

No other languages ever require environment management?

> Lisp doesn’t have those problems

Please tell me about your experience using Qi.