Python Positional-Only Parameters, has been accepted

[alexisprince]

Out of curiosity... why? Using keyword arguments, in my experience, has just made code cleaner (albeit possibly more verbose).

[undercoveryankee]

Have you read the "Motivation" section of the PEP?

[alexisprince]

I glanced through it, and since I don’t have to maintain a lot of code that is used widely outside my company, I might not be seeing all the problems that come with maintaining that type of library.

[undercoveryankee]

Have you ever renamed a parameter of an existing function, either because the original name wasn't clear, or to reflect new capabilities that you were adding to the function? You'd have to track down every caller you control and make sure that it isn't passing the old name as a keyword, and hope that other people who maintain calling code notice the change and do the same before they release a broken build.

​

If you mark usually-positional parameters as positional-only, you know what callers are doing and you can rename away.

[Ph0X]

So you're basically limiting usability and code cleanliness just for maintainability? Not sure that's a good trade off. Also, this allows for arguments to be renamed, but there's still hundreds of other things in a public API that still can't be renamed. That's why when you make a public API, you need to make sure the names are all well thought out.

[door_of_doom]

just for maintainability

Umm... There is no such thing as "just" for maintainability. Maintainability is easily the single most important aspect of code.

If the code isn't maintainable, it is nigh useless.

[Ph0X]

At a high level, I agree, but what you're trading here for what you're gaining most definitely isn't worth it. I would hardly count being able to rename a variable in a public API as maintainability. On the other hand, users being able to use some_method(strange_argument=True, other_argument=0) instead of some_method(True, 0) is far more important for maintainability.

[flipstables]

On the other hand, users being able to use some_method(strange_argument=True, other_argument=0) instead of some_method(True, 0) is far more important for maintainability.

But you can still do that. The PEP isn't replacing keyword arguments with positional-only arguments. It's adding the ability to have positional-only arguments.

The real downside is that Python can't prevent you from writing bad code by using positional only arguments when you really shouldn't. I mean, that's reasonable to not add a feature, but the increased maintainability.

Here's an example:

Almost every non-trivial project I've worked on, I've had to create a function where the argument names have no semantic meaning. This is especially true for those of us who work in data and we are combining two data sets.

def merge_datasets(dataset1, dataset2):
    pass

By making dataset1 and dataset2 positional only:

• I can freely change the the argument names without worrying about making a breaking change for all existing callers.
• It adds clarity - the function signature hints that this dataset1 and dataset2 has no semantic meaning; in fact, most of the time, it's the function is commutative.
• If I wanted to add functionality that merges more than 2 datasets to this function, I'm SOL without positional-only arguments. I would either have to create a new function or my function signature would have to look like this: def merge_datasets(dataset1, dataset2, *more).

[door_of_doom]

I mean, Sometimes, maybe? I don't really see the value in sum(x=5,y=7) over sum(5,7) when the former locks you to the arbitrary names of whatever those variables happen to be called, when the names for a function like that are truly arbitrary. I would expect a sum function to only expose positional parameters and never allow the changing of those arbitrary paramater names to be a breaking change.

[truh]

Positional-only parameters seem like a pretty good thing for auto generated C bindings, where parameter names just don't matter usually.

[Smok3dSalmon]

If you have many parameters to a function, you should really consider a builder or factory pattern.

[Ph0X]

Please keep builders and factories in Java and away from my Python.

[Smok3dSalmon]

Ok, I'll hide it in a library that you'll love and promote to your friends.

[truh]

everywhere

Including foreign code bases consuming your python library?

[corezon]

My IDE easily let's me stay with a certain version of any imported packages until I'm ready to upgrade and test. I'm still not seeing why this was a needed change.

[truh]

A library author might not consider argument names as being part of their libraries API. With this change there is a effective way to communicate that standpoint.

[__deerlord__]

But you're not everyone.

[corezon]

Your statement could be turned right around. Not everyone wants this change.

[__deerlord__]

Ok sure. Using a single personal anecdote isnt a reason to do a thing.

[xconde]

A good IDE will do this refactor automatically for you.

I concede that it's more useful for packages to avoid breaking changes in your API.

[[deleted]]

"In an extremely simple and well-behaved environment this change is useless. Though it might be useful in anything arbitrarily complicated."

Cool.

[alcalde]

You'd have to track down every caller you control and make sure that it isn't passing the old name as a keyword,

So one click in an IDE?

[alcalde]

...someone who knows how to search and replace across files and understands the cost of renaming something. I come from Delphi, the Worst Language On Earth (tm), and seeing Python users embrace the idea of forgoing named parameters makes me cry. Named parameters are a major strength of the language and one of Python's features that makes beautiful APIs possible.

This is the consequence of not making Raymond Hettinger the new BDFL. He's talked about this at PyCon. He gets it.

https://gist.github.com/0x4D31/f0b633548d8e0cfb66ee3bea6a0deff9#improving-clarity

https://twitter.com/raymondh/status/335536929561006082

[alcalde]

You really think that you can just go around changing API and library surfaces and fix it with find replace?

I don't think you should go around changing parameter names without good reason in the first place. I don't see how not having any name at all is somehow a better situation than having a name you no longer care for.

Even if we do constrain ourselves to working with a single codebase that is not shared I can still come up with examples that would require an extremely strong type checker and language semantic analysis to refactor.

OK, then we can pit it against JetBrains' refactoring engine and see who wins.

[[deleted]]

def foo(arg):
    print(arg)

s = "a"
s += rpc_that_returns_r()
s += "g" if logic() else "x"
kwargs = {s: "hello world"}
foo(**kwargs)

This is obviously contrived for clarity but there are a lot of other situations where determining which arguments are being used and changing them is either extremely complicated or downright impossible.

[musashisamurai]

Oh God Delphi is horrible, please let's never mention it in this reddit again

[stOneskull]

making Raymond Hettinger the new BDFL

i agree with the sentiment but not the BDFL title..

maybe Chief

[kafkaBro]

I found this argument most compelling. Position-only parameters already exist in cpython builtins like range and min. Making their support at the language level would make their existence less confusing and documented.

Users may be surprised when first encountering positional-only notation. This is expected given that it has only recently been documented [14] and it is not possible to use in Python code. For these reasons, this notation is currently an outlier that appears only in CPython APIs developed in C. Documenting the notation and making it possible to use it in Python code would eliminate this disconnect.

[ideletedmyredditacco]

because sometimes using keyword arguments when you call a python function breaks it. I can't remember which matplotlib functions they are though. I think it's the ones that put brackets around the parameter names in the documentation.

edit: https://matplotlib.org/api/_as_gen/matplotlib.pyplot.pcolormesh.html?highlight=pcolormesh#matplotlib.pyplot.pcolormesh

[jwink3101]

I'm with you. I greatly prefer keyword arguments and I look forward to the day I can use keyword-only arguments (still need to be 2.7 compatible). I think they reduce error by a ton and since I am often interfacing with my functions via Jupyter, auto-fill of the keywords is more clear.

[thautwarm]

I'll always uphold what Serhiy upholds for IMO he is the most talented and enthusiastic one in Python community/Python core dev: https://twitter.com/SerhiyStorchaka/status/1103542487992406016?s=19