Modern Python lets you explicitly opt out of this by putting “/“ in your argument list iirc correctly:

    def only_positional(a, b, /):
        Pass

Similarly, you can prevent keyword args from being called as positional (which has the inverse problem of breaking client code by changing the order of keyword arguments):

    def only_keyword(*, foo, bar):
        pass

The first feature pretty much only exists to make interop with C apis less error prone. It's not really something that should be used in idiomatic Python

> The first feature pretty much only exists to make interop with C apis less error prone.

It makes it so that certain built-ins and native APIs can be properly typed, sure, but positional/keyword interchangeability is arguably a violation of the Zen, too.

I disagree for the exact reason the thread here started: it’s part of your public API. If you don’t want keyword arguments in your public API contract, you absolutely should omit them from the contract.

To be fair, "Python" is the answer to at least three other questions in the form of "In what language is ___ ever significant?"

That said, I love Python and it's the language that I taught to my daughters first.

I wonder if Python should still be the go to language for teaching programming. It's pretty simple and reads like English but I feel like if you can get over a few syntax bumps, Go is a lot easier to understand and is much more straightforward compared to Python which has a lot of quirks (like why can't spaces/tabs be mixed if they look the same on the editor, why are there so many different ways to write a loop)...

The only thing that might trip up beginners in Go is error handling but if they haven't learned any other way of doing it before then they might just accept it for what it is.

Go has a lot of quirks on things that matter far more. Like, arrays and slices, and how to use them as collections, is very much non-trivial compared to Python lists.

On the other hand, stuff like tabs vs spaces - when you would expect this to even come up? Whatever editor they'd use to start coding with, it'll be configured to use one or the other. In fact, these days, unless you get something exotic, it'll be spaces for sure.

And Python has exactly two ways to write a loop: one for conditional looping, and another when you want to iterate over a collection or a range. Is that really too many?

With tabs vs spaces stuff, the problem is that it's not exactly something that you can teach (like you said the editor will handle it for you). Then later if a beginner tries doing something on their own and runs into that error, it's not exactly intuitive how to fix it and they run into a brick wall that can't be solved no matter how much they look at their code.

Maybe as introduction, sure. But IMO Python does not encourage exploratory reasoning about how programs work.

For example, the question "how does `x.y()` get evaluated?" has a very complex answer. `x += y` is even more complex.

What languages would you recommend for exploratory reasoning?

C++11 is probably as close as you can get to something that's simple enough and widely used but also supports diving into how computers work because you will eventually have to manage your own memory (although I'm not sure if memory management is an important skill for someone just starting to learn how to code).

For a real deep understanding, you'd probably have to jump into the actual computer microchip architecture to learn how computers store memory and do things like pipelining, branch prediction, and caching. Then a primer on Operating Systems (I like "Three Easy Pieces") should fill in the gaps.

I would choose Asm or perhaps even raw machine code.

Whitespace or indentation is one, what else?

For compiled languages, it's neat to get compiler error instead of a nasty bug.

A bug is a problem that affects your users. If you're a library author then your users are developers of applications (and higher-level libraries), so an unintentional breaking change to your API is definitely a bug.

In python without explicit analysis using something like pylint you won’t find out until function call time.

No compiler in Python. In combination with features like varargs, kwargs, unpacking dictionary into args, argument forwarding Python allows you to turn this into bugs.

Well, Python does get compiled to bytecode before it is run. And the compiler does tell you about some errors, like inconsistent indentation, even if that code is never executed.