New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add names to asyncio tasks #78451
Comments
Having names on tasks helps tremendously when something goes wrong in a complex asyncio application. Threads have names and even trio has the ability to name its tasks. This would also greatly benefit PyCharm's concurrency visualization: https://www.jetbrains.com/help/pycharm/thread-concurrency-visualization.html#asyncio |
Thank you for the contribution! |
FWIW, the C implementation of Task.__init__ is not exactly equivalent to the Python implementation (nor to both the C and Python implementation of Task.set_name). In the C impl of Task.__init__ the provided name is used as-is if it's an instance of str: (_asyncio_Task___init___impl() in Modules/_asynciomodule.c) if (name == Py_None) {
name = PyUnicode_FromFormat("Task-%" PRIu64, ++task_name_counter);
} else if (!PyUnicode_Check(name)) {
name = PyObject_Str(name);
} else {
Py_INCREF(name);
} One of the following should happen, right?
p.s. Sorry I did not notice this before it got committed. :/ |
I'd be OK with this, but why is this important? |
As a side note, Alex, what do you think about appending coroutine's name to Task's name if the latter is autogenerated? |
I also couldn't figure out yet why PyUnicode_Check() was necessary in the first place. Doesn't PyObject_Str() just increment the refcount if the argument is already a string? Eric, please explain why these changes should be done. |
Yury, I have no objections. Furthermore, it would be nice to expose the coroutine object publicly, like curio and trio do. It would make life simpler for me in some cases. |
>>> class mystr(str):
... pass
>>> a = mystr('aaa')
>>> str(a) is a
False So Eric is right, there's a small discrepancy between Python and C version. |
Ok, I understand. But is the conversion a bad thing then? |
It's not a bad thing, it's just that we don't do it in C Task and we do it in pure Python Task. Eric wants us to synchronize them so that in a very unlikely scenario where someone uses subclasses of str for names they will have exact same behaviour under both Tasks implementations. I'd say let's just fix the C version to use PyUnicode_CheckExact. Even though it's highly unlikely somebody ever hits this, there's no reason to keep Python and C implementations even slightly out of sync w.r.t. behaviour. |
Should a new issue be created for this so I can make a PR against it? |
Let's just reuse this issue, it's just a small fix. |
Which way do we want to change this? Do we want to convert to pure strings or retain the original object? In the latter case both the C and Python implementations (including set_name()) have to be changed. |
I'm not too invested in any changes happening at this point, actually. :) Mostly I happened to be reading through the commit and noticed the inconsistency. If I had reviewed the PR then I would have asked that it be fixed. So I figured I'd mention it. FWIW, I don't expect it would cause any problems. It could result in a different (between the two implementations) Task repr if the name's type (a str subclass) implements __repr__. There's also the possibility of side-effects (from the implementation of the name's type). Neither is a big deal (especially the latter since it's *not* a common use case). On the other had, the matter is made moot by using PyUnicode_CheckExact(). :) |
Then, in order to keep the pure Python implementation in sync, we'd have to change it to something like this: if name is None:
self._name = f'Task-{_task_name_counter()}'
elif isinstance(name, str):
self._name = name
else:
self._name = str(name) I don't know about you, but it looks pretty awkward to me. |
Please just change PyUnicode_Check to PyUnicode_CheckExact in C Task.__init__ and use the same if check in C Task.set_name. |
I'll do that if you say so, but I'm just saying that the C and Python implementations will still remain different in semantics then. |
Probably I'm missing something here. How would they be different? |
I'll do that if you say so, but I'm just saying that the C and Python implementations will still remain different in semantics then. Never mind, that was a brain fart. I keep ignoring the "!" in my mind. |
Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.
Show more details
GitHub fields:
bugs.python.org fields:
The text was updated successfully, but these errors were encountered: