A Welcome Syntax

Posted Apr 23, 2025 9:02 UTC (Wed) by farnz (subscriber, #17727)
In reply to: A Welcome Syntax by mb
Parent article: Template strings accepted for Python 3.14

I've been trying to get it through to people for over two years now - the trouble is that they don't write code very often, and after 6 months of not coding, they forget most of the details.

It is getting better now that we have access to LLMs trained on FOSS code - they tend to ask an LLM for a starting point, and the LLM writes better code than they do.

to post comments

A Welcome Syntax

Posted Apr 23, 2025 12:24 UTC (Wed) by kleptog (subscriber, #1183) [Link] (8 responses)

> I've been trying to get it through to people for over two years now - the trouble is that they don't write code very often, and after 6 months of not coding, they forget most of the details.

In that case I wonder why they're even using async/await at all? It's not exactly a trivial feature. Is there some company library that requires its use?

I'm also struggling to think of a situation where it's unclear where to put the await. It's almost always applied to a function call and I don't see the benefit of writing:

res = await(func(foo, ...))

over

res = await func(foo, ...)

Just seems like excessive parentheses. If you're calling an async function, stick the await right before the function name. That's all that's required. I can't believe that's hard to remember if you know the rest of Python. If you're using something like VSCode it will show you where you went wrong.

A Welcome Syntax

Posted Apr 23, 2025 12:44 UTC (Wed) by farnz (subscriber, #17727) [Link] (7 responses)

They use await because they're working with a whole pile of external libraries (since virtually all they write is glue code for hardware test harnesses) that require them to use await. And the trouble is that they don't know Python - or tcl, or bash, or VBA, or any other programming language - which means that they're coming up with ad-hoc theories of how programming works.

For example, they expect that res = func(foo) + func2(bar); res = await res will work, as will res = await func(foo) + func2(bar), as shorthand for res = await func(foo) + await func2(bar), because that fits their ad-hoc theories, and it doesn't work (for reasons that are very obvious to any programmer). I had some success getting them to write this as res = (await func(foo)) + (await func2(bar)), but that's fallen by the wayside over time as people remove the outer parentheses, and then get confused again when they come to copy-and-paste this into a new test harness.

If they were programming regularly, they'd learn that "await func" is indivisible. But they're not - they're usually working in the lab with physical hardware, writing equations and things to convince themselves that their measurements are telling them what they expect to see, and then eventually coming back to automate this. And we're not big enough to afford someone employed full time to turn their test harnesses into code based on written descriptions, so we suffer instead.

A Welcome Syntax

Posted Apr 24, 2025 10:29 UTC (Thu) by taladar (subscriber, #68407) [Link] (6 responses)

Maybe a language that is stricter would be better suited for people who are not very familiar with programming? Python expects the programmer to do a lot of the work in keeping the program correct that is done by the compiler in a strict language like Rust.

A Welcome Syntax

Posted Apr 24, 2025 10:42 UTC (Thu) by farnz (subscriber, #17727) [Link] (5 responses)

We're kinda stuck here, because we don't have the resources to support our own bindings to the vendor-supplied hardware libraries. The vendor supports C89 using callback hell, or async Python; we've asked them to support a "simple" interface using non-async Python (which is plenty for our use case), but they don't want to, citing a belief that "big" customers won't take them seriously if they offer a simple interface as well as a complicated one.

And it's simpler for us to keep retraining the hardware people on Python every 6 months than to maintain a wrapper around the (constantly changing) vendor libraries to make it easy for them. The annoyance is that this is purely syntactical - they see await foo() as two separate things, when they should see it as one for their purposes, and they get confused because in their mental model of "how this works", keyword function() implies returning from this function to the caller, (as return and yield do), and that's not what they want to do here. Changing it to "look" like a function call (even though it isn't) would fit their mental model, since that's what they want to do - run the thing until it returns an answer.

A Welcome Syntax

Posted Apr 24, 2025 11:13 UTC (Thu) by mb (subscriber, #50428) [Link] (4 responses)

I really don't understand what the problem is that you are talking about.
If you want parenthesis after await, then just add them. You can do that today.

$ cat t.py
import asyncio

async def x():
    print('A')
    await asyncio.sleep(1)
    print('B')
    await(asyncio.sleep(1))
    print('C')

asyncio.run(x())

$ python3 t.py
A
B
C

A Welcome Syntax

Posted Apr 24, 2025 11:28 UTC (Thu) by farnz (subscriber, #17727) [Link]

Ideally, I would get a syntax error if I wrote await asyncio.sleep(5), because the mental model my Python-using colleagues have is that keyword expression means "return the value of expression to the caller of this function somehow", whereas keyword(expression) means "have keyword call expression and give me back a value".

And because they don't want to return from this function (they want to wait for expression to evaluate, which involves hardware accesses), they try to put the minimum number of awaits in that seems to work for them, scoping them as broadly as possible and dragging other people in when they can't guess their way to working code.

A Welcome Syntax

Posted Apr 24, 2025 18:28 UTC (Thu) by Wol (subscriber, #4433) [Link] (2 responses)

> I really don't understand what the problem is that you are talking about.
> If you want parenthesis after await, then just add them. You can do that today.

The problem is you ass-u-me-ing that the people doing the program know to do it.

And training is not the answer when (as seems to be the case here) they are doing it maybe twice in a blue moon.

I think you need a spell doing 1st-line support for people who either (a) don't program as part of their work, or (b) for whom it is a necessary evil. Most of them are unteachable ...

Cheers,
Wol

A Welcome Syntax

Posted Apr 24, 2025 18:37 UTC (Thu) by mb (subscriber, #50428) [Link] (1 responses)

>The problem is you ass-u-me-ing that the people doing the program know to do it.

No.
The complaint was that the people want to use parenthesis, because that better fits to how they think.
Well, I'm fine with that.
And that Python should allow that.

But that's actually possible with current Python.
Therefore, I really don't know where the problem is.

If you want to use parenthesis, use them.
If you don't want to use parenthesis, don't use them.

And if you don't know the language, learn it.
This is orthogonal to whether async is spelled with or without parenthesis.

A Welcome Syntax

Posted Apr 25, 2025 8:53 UTC (Fri) by farnz (subscriber, #17727) [Link]

No.
The complaint is that Python permits you to use a space instead, which results in people getting confused by the code they copy-and-paste from elsewhere, since they don't understand why they're "returning" something here, and come up with all sorts of weird mental models for how await changes the context after it - e.g. that await foo() + bar() is semantically the same as await foo() + await bar().

Python should not use the same syntactic convention for "things that return a value from this function to its caller (such as yield and return)" and "things that evaluate something into a different type of value (such as await)".

Adopting a Rust-like "postfix await" would also work for this - because it means that it's a different syntax for a different behaviour - but I would expect that to be a much bigger sell to Python people than parens.