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):
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.
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.
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.
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.
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.
Another example is Angular.js It used Javascript's toString() method to get the names of the arguments and then did dependency injection magic based on it.
Does anyone know if that is still the case for recent versions of Angular?
The name of method parameters in obj-c is not significant. The argument label and argument name are different things. In `- (void)frobulateThing:(id)firstThing andAlso:(id)secondThing;`, `firstThing` and `secondThing` are the argument names and can be changed with no impact on the callers, while `frobulateThing:andAlso:` is the part relevant to callers.
In Swift the argument labels are the same as the argument names by default, but you can also supply different values for them.
Java (sometimes) where reflection allows you to inspect the parameter names, and you can optionally retain the names in the compiled bytecode.
E.g. these days the Spring framework defaults to using the parameter name as the qualifying name to discriminate between otherwise identical types during autowiring.
Since it hasn't been mentioned yet, C#/.NET also has this dumb feature - the name of the parameter is compiled into the dll, and can be used for 'named arguments', where the caller can write `a: 20` in the argument list to assign the parameter called `a` to 20. If the library developer renames the parameter to something other than `a`, than that old code won't compile anymore (Though AFAIK the old compiled code is still ABI compatible with the new version, since the method arguments are resolved at compile time).
Named arguments in much of the Rails API are received by the method via a single hash parameter, not as individual lexically bound variables.
In most cases, Ruby handles this capture via a double-splat operator in the parameter list.
However, Ruby itself does have both positional and named method parameters. The former contribute to arity and may be overridden and renamed in subclasses, and this remains true for Rails methods accepting positional arguments.
It is also the case that a hash is implicitly congruent to named arguments, although this is controversial and may change in future. I’m sorry to report that no-one has ever described this as “arg hash” or “argh” for short.
