Repository navigation
Add CSV and 🍌SV output formats to asyncio ps #134861
Description
Feature or enhancement
Proposal:
Hello 👋
I'm in the very serious business of displaying awaited-by tasks, and the table output format is not machine-readable!
We absolutely need this feature!
$ ./python.exe -m asyncio ps 92294 --format bsv
tid🍌task id🍌task name🍌coroutine chain🍌awaiter name🍌awaiter id
4876371🍌0x101c4bdf0🍌Task-4🍌🍌🍌0x0
Has this already been discussed elsewhere?
This is a minor feature, which does not need previous discussion elsewhere
Links to previous discussion of this feature:
No response
Activity
Eclips4 commentedon May 28, 2025
I guess we could consider adding the
CSVformat, butBSVis new to me. Is that a joke?dpdani commentedon May 28, 2025
https://www.youtube.com/watch?v=RrsVi1P6n0w
ZeroIntensity commentedon May 28, 2025
If only GitHub had a 🍌 reaction.
johnzhou721 commentedon May 29, 2025
GitHub should solve the general problem of allowing any emojis in reactions.
GiwbyAlbatross commentedon May 29, 2025
I think 🍌SV should be added to the
csvmodule. I suppose you could just passdelimiter="🍌"to thecsv.readerconstructor however…johnzhou721 commentedon May 29, 2025
The Python joke thread of 2025...
dpdani commentedon May 29, 2025
What do you mean? This is no joke, it's very serious business!
At $work we have a 🍌sv parser written in assembly (because Rust would be too slow).
But it can only parse 🍌sv (because it's more performant) and we need to parse 2^(24^2) tasks/s!
Our clients need this!
1st1 commentedon May 29, 2025
Everyone, @pablogsal and I are thrilled by the hype around
asyncio ps. 🚀That said, CSV is not future-proof enough for the greatness of
asyncio ps. I propose we adopt PDF with embedded XFA, which is Fortune 500 approved and roomy enough to accommodate the worst data structure in the universe...and anything even worse that we invent tomorrow!pablogsal commentedon May 29, 2025
As the asyncio 🍌SV spec lead (yes, that's a thing now), I must clarify:
🍌SV is not just a format. It’s a lifestyle. A philosophy. A commitment to peeling back the layers of complexity in async debugging.
Next step: 🍌ML for multiline support and 🍌SON for structured async state.
Let’s keep it fruitful, folks. 🧃
johnzhou721 commentedon May 29, 2025
1st1 commentedon May 29, 2025
That's the 🍌 spirit.
pythongh-134861: Add 🍌SV output format to `asyncio ps`
gh-134861: Add CSV output format to ``python -m asyncio ps`` (#134862)
9 remaining items
ZeroIntensity commentedon Aug 26, 2025
No opinion from me on whether to keep CSV, but I think if we do end up keeping it, it's fine to keep BSV. Looking at the diff, it'd be very little extra maintenance and it should be fine to have fun easter eggs where we can -- the language is named after Monty Python, after all.
If there's no support for keeping CSV, let's remove both.
Revert "pythongh-134861: Add 🍌SV output format to ``python -m asyncio…
Revert "pythongh-134861: Add CSV output format to ``python -m asyncio…
kumaraditya303 commentedon Aug 27, 2025
asyncio isn't maintained very well, I am the only active maintainer left on the team as such I don't want to add more code without any use case.
Revert PR #138187
AA-Turner commentedon Aug 27, 2025
cc @dpdani as original author. Do you have a use-case for CSV? Kumar would like to revert this as CSV might not be needed.
picnixz commentedon Aug 28, 2025
My rationale for accepting the CSV is to make it possible for external formatters to render it as they see fit which is why I considered having a simple machine-readable format. Alternatively, we could have written it in JSON for an easier-to-parse machine format.
kumaraditya303 commentedon Aug 28, 2025
Rather than adding a machine readable format which would require parsing, it is better to get #134342 which would allow users to format/use the info in any form as needed.
ZeroIntensity commentedon Aug 28, 2025
I'm inclined to side with Kumar as the primary asyncio maintainer. If he strongly believes that something will be a burden or that there's a better approach, I think we should respect that. I'm going to put my approval on the revert.
picnixz commentedon Aug 28, 2025
Oh right. Well, my main motivation was to make it available for external formatters outside the Python environment, that is, formatters that could do
python -m asyncio ps <PID> | tool, but I'm perfectly fine with having it as a public API instead. That would eliminate the needs to maintain formats and would offer a more flexible interface.gh-134861: revert "Add CSV and BSV output formats to asyncio ps" (#13…
dpdani commentedon Aug 29, 2025
Hello everyone 👋
I just got back yesterday from my holidays and I've only been skimming at this issue on my phone this past week. I didn't want to send an unthoughtful message.
I'm sorry that this has caused issues for anybody.
To me, it always looked like a harmless easter egg.
Otherwise, I wouldn't have done this.
I thought that CSV may be helpful in the way that @picnixz was just saying, but my main motivation for it was just to conceal the bananas format.
So, all in all, I just wanted to say thank you for all the work you core devs are doing for us with this easter egg, and I'm sorry if I ended up wasting your time.
Daniele
pythongh-134861: revert "Add CSV and BSV output formats to asyncio ps" (