Repository navigation
Add CSV and 🍌SV output formats to asyncio ps #134861
Description
Activity
- addedtype-featureA feature request or enhancementA feature request or enhancement
on May 28, 2025 I guess we could consider adding the
CSVformat, butBSVis new to me. Is that a joke?Reacted by Łukasz LangaReacted by Daniele Parmeggiani- Reacted by Kirill Podoprigora
If only GitHub had a 🍌 reaction.
Reacted by Kirill Podoprigora, Daniele Parmeggiani, Emma Smith, John, Łukasz Langa, Gregory P. Smith and Stan UlbrychIf only GitHub had a 🍌 reaction.
GitHub should solve the general problem of allowing any emojis in reactions.
Reacted by Giwby AlbatrossI think 🍌SV should be added to the
csvmodule. I suppose you could just passdelimiter="🍌"to thecsv.readerconstructor however…Reacted by Daniele Parmeggiani and Łukasz LangaThe Python joke thread of 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!Reacted by Łukasz LangaEveryone, @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!Reacted by Daniele Parmeggiani and Emma SmithAs 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. 🧃
Reacted by Gregory P. Smith, Brett Cannon, Emma Smith and JohnReacted by Yury Selivanov and Daniele Parmeggiani- Outputting LaTeX tables in all formats used with all table packages possible is mandatory.Reacted by Daniele Parmeggiani and Kirill Podoprigora
possible is mandatory
That's the 🍌 spirit.
Reacted by Daniele Parmeggiani, John and Gregory P. Smith- addedstdlibStandard Library Python modules in the Lib/ directoryStandard Library Python modules in the Lib/ directory
on May 30, 2025 - added a commit that references this issue
on Aug 6, 2025 9 remaining items
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.
Reacted by Adam Turner, Daniele Parmeggiani, John and Kirill PodoprigoraLooking 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.
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
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.
- pinned this issue
on Aug 27, 2025 - unpinned this issue
on Aug 27, 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.
Reacted by Kirill PodoprigoraRather 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.
Reacted by John and Yury SelivanovReacted by JohnI'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.
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.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
Reacted by Adam Turner, Peter Bierma, Pablo Galindo Salgado, Cody Maloney, John and Yury Selivanov
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!
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
Linked PRs
asyncio ps#134862asyncio ps#137486