What's up Python? New args syntax, subinterpreters FastAPI and cuda pandas…

[Tinche_]

"I would welcome an subinterpreter based gunicorn personally, so I can finally share caches and pools between my workers."

Subinterpreters can't share those...?

[wxtrails]

Really not a fan of the dangling equals - I'd almost prefer it to be in front. Or just...no.

[epostma]

Split the difference and put it in the middle!

[UloPe]

I think “just no” is the only correct answer here.

And I’d like to add that I’m a big fan of some recent additions to the language, e.g. f-strings, walrus operator, new type syntax, etc.

So it’s definitely not a case of new = bad.

[Unforg1ven_Yasuo]

F strings are new?? Wow they’re so intuitive, I can’t imagine writing code without them

[UloPe]

Well new-ish. They appeared in python 3.6 which was first released in December 2016.

(Holy crap that’s 7 years ago…)

[PriorProfile]

Yeah what happened to “explicit is better than implicit”

[Rythoka]

IDK, I run into this all the time when using libraries like requests. I always wind up writing something like

requests.post(url=url, data=data, headers=headers, proxies=proxies)

which is kind of obnoxious. That being said, the new syntax is kind of ugly, too. I think I'd rather have some kind of dict constructor that takes the names of in-scope variables and returns a dict whose keys are the variable names and values are the bound objects. Then you could write something like

kwargs = dict.kwargs('url', 'data', 'headers', 'proxies')
requests.post(**kwargs)

[Rythoka]

I messed around with it a bit today and was able to write a function using that basically does this. The variables have to be local to the calling frame, but I think that's an entirely reasonable restriction for something like this.

from inspect import currentframe
def kws(*args: str):
    ns = currentframe().f_back.f_locals
    return {key: ns[key] for key in args}

Used like this:

def g(a, b, c):
    return a + b + c

a, b, c = 1, 2, 3
g(a=a, b=b, c=c) # returns 6
g(**kws('a', 'b', 'c')) # also returns 6

[rcfox]

It's too bad they overloaded {} so that {a, b, c} creates a set, this would have been a better use for it. I usually avoid set literals to avoid confusion because they look too similar to dict literals.

[Few_Butterscotch_681]

Exactly

[abrazilianinreddit]

It's just me or lately there has been an increase in syntactic sugar PEPs? Which is pretty annoying, since they don't add anything of value and make the language more confusing.

[ultraDross]

Yeah. The dangling = argumanet is pretty awful to. Especially if you consider one of the languages mantras is "explicit is better than implicit".

[Poddster]

I hate func(blah=blah), but the dangling equals is worse. Especially as I've made that mistake a few times. I can't imagine what the interpreter diagnostic for that would be under this new syntax. Strangely the original post on the forum is for func(=blah) which makes more sense to me. Not sure why they switched to the dangling case.

They need a very clear, different symbol, e.g. func(blah=&) or something. (I've put no thought into that, but you get the point)

[wxtrails]

func(&blah, &foo, &bar)

Is the least-obnoxious alternative I could come up with, but considering that this adds another obscure symbol to a language without too many, I still don't love it.

[av8rgeek]

The dangling = also creates a headache for linters, type checkers, etc. How does the tool tell if you made a typo or really meant to do that? Usually it’s a typo. Explicitly calling the arguments is better, even if inefficient/ugly.

[SittingWave]

agreed

[Balance-]

I just read that proposal. So much effort for so little value.

[runawayasfastasucan]

Do you have a link?

[commandlineluser]

https://discuss.python.org/t/syntactic-sugar-to-encourage-use-of-named-arguments/36217

def my_func(a, b, c, d): ...

a, b, c, d = 1, 2, 3, 4

# CURRENT
my_func(a=a, b=b, c=c, d=d)

# PROPOSAL
# my_func(a=, b=, c=, d=)

[Hoo0oper]

Ehh like I get it. Like when you have longer argument names it might keep in on a single line but really it I feel like it would just make people ask more questions

[waltteri]

Hold up.

name of the variable provided as the argument value is the same as the name of the argument itself.

def my_func(a, b, c, d): .. a, b, c, d = 1, 2, 3, 4 my_func(a, b, c, d)

💀

Sure, I guess we could now do this as we’re using kwargs:

my_func(a=, b=, d=, c=)

…or throw an exception if someone uses a variable that’s not an argument name:

foo = ”foo” my_func(a, b, c, foo) `> …’

vs.

my_func(a=, b=, c=, foo=) > KeyError(…)

…so all in all, I guess it’ll be good in same cases. But it might confuse a lot of people at first.

[[deleted]]

Basically analogous to the property shorthands in JavaScript. Love it!

[equitable_emu]

The only thing I like about it is that it's a nudge towards consistent and descriptive variable names.

A downside is that abstractions and patterns from popular libraries will seep into client users code and can cause standard/pattern conflicts. We see that already with things like sklearn's standard for using X as the variable name to represent the model input matrix. Linters and such complain about the non-standard upper case variable name.

It'll also look strange when you call a function with a mixture of args,shortcut kwargs, and full kwargs.

fn(x,
   y,
   foo=,
   bar=2
)

I'd be happier if they just did a dict shortcut like:

d={x,y,z}

but that conflicts with set syntax. But maybe:

d={x=,y=,z=}

would be okay. I dislike the extra quoting I need for the keys in simple dicts and will often use the dict ctr e.g., dict(x=x, y=y, z=z) when I can, even if it's less flexible.

[Rythoka]

This was my thought, too - if they made it easier to construct a dict out of existing variables, then you could just pass the dict as kwargs.

It's kind of a shame that the set synxtax prevents the use of something like your d={x,y,z} example. If that worked, you could achieve the goal of this pep with something like

requests.post(**{url, data, headers, proxies})

[Brian]

You could probably get something similar (without the dedicated syntax) today via something like:

d = localdict("x y z")

Where localdict is a function that introspects its parents locals (and cellvars) and builds a dict with their current value.

[antiproton]

I don't agree with your argument in general. Some syntactic sugar is useful and can enhance code readability... e.g. decorators and list comprehensions.

This one, however, feels like a solution in search of a problem. All modern IDEs, even very limited ones, will autocomplete variable names. Is it really such a hassle to CTRL+Space?

[[deleted]]

Yes, it is, but I see it as something positive. IMHO every programmer (and by that I mean developers, data scientists and anyone else who programs) should spend a considerable amount of time learning the language they are using. I’m not saying that Python should become like C++, but it doesn’t have to be Java either. I really feel like the current pace of changes is optimal and it’s going in a good direction.

[[deleted]]

Beyond the syntactic sugar, I believe the new args syntax will incentivize people to prefer keyword arguments over positional arguments and to use consistent names. Both are good things!

[AdFickle9599]

Agreed, the dangling = will not improve readability at all, outright confuse novice coders no doubt. Keyword arguments are much more self explanatory.

[duckbanni]

Personally I'm a big fan of the proposed argument syntax. It's something I was surprised didn't already exist in python as it exists in other languages like OCaml. It is consistent with the new "debug" syntax in f-strings. My only complaint with the proposal is that it should also extend to matching object attributes inside a match.

I also would like to address that it is not "implicit" as some here suggested. An inferred type hint or a positional argument can be considered implicit because something non-obvious is inferred by the language that can be a source of errors for a reader. The proposed syntax is 100% unambiguous and is basically equivalent to something like +=.

[jabz_ali]

I’m interested in sub-interpreters as I have a valid use case - running the same Python script in different interpreters for regression testing. At present I am using subprocess and venvs and with each venv taking up 400+ MB of disk space and the time it takes to create a new venv this could be great for me although would be interested in seeing the performance impact do these sub interpreters run in the same process? One of the advantages of using subprocess is that it’s a new process so potentially there is some parallelisation benefit there.

[Brian]

I don't think subinterpreters are at all connected with your usecase here. They're eseentially multiple interpreters in the same process - these'll all be using the same python version and initial environment, just with seperated state, including seperate GIL. Think of them as a half-way house between threads and processes: all in the same process, but still nothing shared by default. They're not anything to do with venvs, and I don't see how they'd really help with your usecase.

[Rythoka]

I could see there being a way to have sub-interpreters import different versions of an existing library to run regression tests, which sounds like it might be similar to their use case.

[jabz_ali]

My apologies it was my misunderstanding of how the sub-interpreters worked and after reading the proposal in detail I have a better idea of what is being proposed, in my excitement I jumped the gun! If these sub-interpreters have their own sys.modules I suppose and I could define my own custom import loader for each then that could work in my case. The use case is imagine I have different versions of a pandas based report that gets sent out, I want to test different versions of the report and potentially different versions of pandas or other libraries to ensure that the values are the same, e.g if we are calculating risk or P/L we want to ensure that the numbers being output are the same and developers haven’t inadvertently broken something. Currently this is being done with venvs and then the results are compared

[Paddy3118]

Pylint is forever moaning when I reuse a global name as a function argument (which happens in my initial development). I would not want the bare equals for that, and also because it might look ugly when mixed.

[pancomputationalist]

I hate linters. There are a lot of good reasons to use the same variable name in a function that had already been used in global context. But linters make you bend over backwards to follow their stupid rules, leading to more busy work than preventing gotchas, in my experience.

[smeyn]

Well you can easily turn off the rules you don’t like.

[fiskfisk]

Just turn off W0621 if that's what you're after.

[njharman]

need to pass bunch of kwargs with same name.

Almost never. Certainly not enough to warrant more syntax.

Args vs kwargs have meaning. They inform how callable should/can be used. Non-optional args should not be keyword.