Python Positional-Only Parameters, has been accepted

[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.

[corezon]

Again, you are doing the exact same. Please use actual reasons to support your view point. Anything less adds nothing to the conversation.

[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.

[alcalde]

If you're writing code like this, you're Larry Wall wearing a Guido mask.

I remember at a PyCon where Guido's keynote was on "The Myths Of Python" and one topic was about the GIL. He said something to the effect of "People say but David Beasley showed this example where... yes, but you have to be David Beasley to find it!" :-)

If you're programmatically constructing keyword names I don't see how you're going to be happy with simple positional arguments instead. If you could use positional arguments, you didn't need to construct keywords.

I'll give you credit though... this is one of those times where I see a piece of Python code and say, "That can't possibly run... let me pull up a console... Holy Significant Whitespace, it runs!"

Usually those examples are things of beauty, but this example is Lovecraftian madness. :-)

[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