4 ms·

Reading this is like reading early Renaissance alchemist arguing about how much mercury they need to combine with how much silver to create gold... This is so

Reading this is like reading early Renaissance alchemist arguing about how much mercury they need to combine with how much silver to create gold... This is so far gone I don't even know where to begin... > It may be IO that gives AsyncIO its name, but Textual doesn't do any IO of its own. So why on Earth are you using AsyncIO? You don't need it, if that's true... > Those tasks are used to power message queues How are your message queues not doing I/O? What on Earth are they doing then? Needless to say that the whole benchmark is worthless because it never even initiates anything that would be involved when creating actual asynchronous I/O tasks... ---- I mean, I know, in Pythonland this is just your average Wednesday, but dear lord, if you don't visit that land all that often it shocks you more every time you do.

vore 4y ago
asyncio is really not all about I/O though, despite the name. You can just as easily use it for concurrency by interleaving tasks with each other. You can imagine multiple UI elements that all need to make progress, and using coroutines to have them cooperatively yield to each other and not just have one element block progress everywhere else. It's just using asyncio as a task scheduler, nothing more, nothing less. Maybe when you visit Pythonland you might instead be shocked in a more positive way :-)
- crabbone 4y ago
  [flagged]
  - vore 4y ago
    I can't help but feel this is a low-effort troll, but I'll bite anyway. > Where does this nonsense come from? Seriously? Who told you that? Where is the I/O in this? async def task1(): while True: print("a") await asyncio.sleep(0) async def task2(): while True: print("b") await asyncio.sleep(0) async def main(): t1 = asyncio.create_task(task1()) t2 = asyncio.create_task(task2()) await asyncio.gather(t1, t2) asyncio.run(main()) Fundamentally it's an event loop that allows you to register interest in I/O events. You can, of course, also just register no interest in any I/O events, where you still get scheduler features like timers and cooperative scheduling. > This is wishful thinking. No. It doesn't work. Will not work, unless Python is purged of like 99% of it's current stuff and replaced with something else entirely. It's ridiculous to even consider this possibility applied to the concrete runtime you'd have to work with. Where is the wishful thinking in the same code example I posted? You are free to control cooperation between your tasks as required. > Come on man... you just put "cooperatively" and "will not block" in the same sentence. Of course it doesn't work like that. Will not work, especially in Python where you have to yield control explicitly. It's all toys. None of it works. So? Just yield control explicitly? Just because the multitasking isn't preemptive doesn't mean you can't cooperatively make progress on multiple tasks. > Well, that's stupid. Why would anyone want to do that? It simply won't work. It works fine? The post is literally talking about how it works? Maybe you don't like the ergonomics but that's not a reason to be so dismissive of it. In any case, just because you don't like it doesn't mean there is zero value in this, or that you can be such a massive piece of shit and respond like this.
Uptrenda 4y ago
This reply strongly reads of 'im smarter than eveyone' and 'know everything.' Is it possible that the author is doing something that you don't know about? Such as writing and reading text to sockets (which would be I/O.) And is it possible they may have a reason to be using asyncio in Python (which uses a single main thread and hence needs something like asyncio for concurrency.) >Needless to say that the whole benchmark is worthless Overhead startup isn't worthless. 'I mean, I know, in Pythonland this is just your average Wednesday' and here we go. The whole post was really just you trying to make out that you're superior to everyone else. In this case looking down on an entire ecosystem. Why? Python is one of the most popular languages. It has an elegant syntax and it's capable of solving most problems. Go jerk yourself off in private.
- crabbone 4y ago
  > This reply strongly reads of 'im smarter than eveyone' Dude, where's everyone, where? I'm smarter than the guy who posted this nonsense about asyncio, that's for sure, but that's a very low bar... Now, when it comes to Python, then, it's an environment that is flooded with the programmers with the lowest skill level imaginable. This is where all those month-long bootcamps pump their graduates, this is where all the people who took a month-long intro to CS with Python class go, this is where a lot of people who only use Python accidentally, to compliment some other programming activity (or just general computer-related activity) go. It's a swamp, and there's no reason to pretend it isn't. On the other hand, anyone who had any serious aspirations for Python left the scene ten or so years ago. Today, Python is the worst parts of Java and PHP combined. So, again, it's a very low bar to be better than most Python programmers. Without even trying, when I searched for a job and had to do a bunch of automated assessment tests, I was consistently placed in the "best" decile, often in the "best 5%" of all applicants, and I hate the language. I'm honestly not good at it and don't want to be good at it. You don't need to try hard to be "as good" as I am, because I'm not good... but, yeah, in this particular area everyone is hands down awful. I also had to interview about two dozens of applicants in my last job. I had people who couldn't explain the difference between expression and statement. I had people who couldn't tell what __str__() method is for. I had extremely low expectations, and yet I was consistently disappointed by the knowledge level of applicants. It's surreal what's going on there. --- > Overhead startup isn't worthless. Yeah, maybe... OP never measured it anyways. OP never created any asynchronous I/O tasks. OP measured how long does it take to run couple functions in Python. Admittedly, it takes a long time, but it's irrelevant to async I/O. Especially in the context of comparing whatever OP's doing to threads. Which was their goal stated in the opening statement.
traverseda 4y ago
Python asyncio is actually a co-operative multitasking system, think real-time operating system type stuff. It doesn't do real concurrency but it gives you a nice interface for reasoning about tasks (think thread) while being able to explicitly control when/where they yield control of the event loop, how often they run, etc. >How are your message queues not doing I/O? We generally wouldn't consider in-process moving data around to be "I/O", now if you started interacting with an external database/file/pipe/MMAP-ed-file/etc than that would be "I/O". >What on Earth are they doing then? Tasks. Kind of like processes but lighter weight. Running an event loop, dispatching signals, that sort of thing. You can do all that by manually writing your own event loop but python's asyncio (IMO) makes it easier to reason about exactly when your yielding the event loop to some other task, and makes it easier to write code that can yield control of the event loop at arbitrary places. So like if you want to update a widget every 10 seconds you can write something like while True: await asyncio.sleep(10) #Other tasks can run during this 10 seconds sleep #Update widget contents Useful for stuff that needs to periodically poll data, like a process monitor, or even for just simple clock widgets. --- As an aside that cooperative multitasking can be really nice in micropython, where you can write tight loops in straight assembly if you need to and still get a pleasant task interface for managing higher level tasks/threads. Combined with some interrupt handlers it makes a pretty elegant real-time-ish operating system. (You probably need to manually deal with garbage collections though)
philote 4y ago
Message queues can be implemented in memory, so no network or disk I/O. In fact, it seems this project does use the built-in "queue" library: https://docs.python.org/3/library/queue.html https://docs.python.org/3/library/queue.html
- crabbone 4y ago
  Lol. Waht I/O to disk? What are you talking about? Asyncio was never about disk I/O. It's about Internet socket I/O exclusively. But, what do you think happens when you write (input) data to memory and then read (output) it from memory? I'll help you: it starts with "I" and ends with "O"!
  - biorach 4y ago
    > Asyncio was never about disk I/O. It's about Internet socket I/O exclusively. Game over. You have no clue what you're talking about.
  - greenshackle2 4y ago
    > But, what do you think happens when you write (input) data to memory and then read (output) it from memory? I'll help you: it starts with "I" and ends with "O"! That's.. that's not what people mean when they talk about I/O in this context. But I think you know that, you're just grasping at straws to win an argument.
greenshackle2 4y ago
Asyncio is for cooperative multitasking. I/O is the most common use case but it's not the only one. They're using the event loop to schedule their GUI tasks. Textual is a framework for building desktop apps. I assume the message queues are in-memory structures used to pass messages between tasks, hence no I/O. This is really fairly standard stuff. I understand you may not be familiar with GUI software and/or the Python ecosystem but jumping straight to condescension when you don't understand something is not really a good attitude.
louwrentius 4y ago
I knew you would be here in the comments. Crabbone won't leave any chance he gets to shit and dump on Python any HN post he can. Must be so frustrating, knowing that this silly language is one of the most populair programming languages in the world, despite its short comings, one of which is slower performance. This isn't about python or any language. The extreme negative tone and sense of superiority seems to point to something else. What is it?
- crabbone 4y ago
  I don't care about Python performance. But, yes, I'm very frustrated this trash is so popular. I never made this a secret :| Python deserves negative tone, and if you think that popularity somehow makes it exempt from criticism, then you deserve the same.
  - louwrentius 4y ago
    But this isn't about "something being popular makes it exempt from criticism". You don't really criticise. You just exaggerate and emo-dump all over python and the people who use it. Your stance seems to be that python needs to be destroyed and dumped and replaced by some other language. Your stance is that people who use python are idiots. That kind of 'criticism' is so totally useless it's kind of seriously pathological. Your 'critisism' says more about you (due to the extremely antagonising tone) and not much about Python really. Quite sad when you think about it.

vore 4y ago

asyncio is really not all about I/O though, despite the name. You can just as easily use it for concurrency by interleaving tasks with each other. You can imagine multiple UI elements that all need to make progress, and using coroutines to have them cooperatively yield to each other and not just have one element block progress everywhere else. It's just using asyncio as a task scheduler, nothing more, nothing less. Maybe when you visit Pythonland you might instead be shocked in a more positive way :-)

crabbone 4y ago
[flagged]
- vore 4y ago
  I can't help but feel this is a low-effort troll, but I'll bite anyway. > Where does this nonsense come from? Seriously? Who told you that? Where is the I/O in this? async def task1(): while True: print("a") await asyncio.sleep(0) async def task2(): while True: print("b") await asyncio.sleep(0) async def main(): t1 = asyncio.create_task(task1()) t2 = asyncio.create_task(task2()) await asyncio.gather(t1, t2) asyncio.run(main()) Fundamentally it's an event loop that allows you to register interest in I/O events. You can, of course, also just register no interest in any I/O events, where you still get scheduler features like timers and cooperative scheduling. > This is wishful thinking. No. It doesn't work. Will not work, unless Python is purged of like 99% of it's current stuff and replaced with something else entirely. It's ridiculous to even consider this possibility applied to the concrete runtime you'd have to work with. Where is the wishful thinking in the same code example I posted? You are free to control cooperation between your tasks as required. > Come on man... you just put "cooperatively" and "will not block" in the same sentence. Of course it doesn't work like that. Will not work, especially in Python where you have to yield control explicitly. It's all toys. None of it works. So? Just yield control explicitly? Just because the multitasking isn't preemptive doesn't mean you can't cooperatively make progress on multiple tasks. > Well, that's stupid. Why would anyone want to do that? It simply won't work. It works fine? The post is literally talking about how it works? Maybe you don't like the ergonomics but that's not a reason to be so dismissive of it. In any case, just because you don't like it doesn't mean there is zero value in this, or that you can be such a massive piece of shit and respond like this.

Uptrenda 4y ago

This reply strongly reads of 'im smarter than eveyone' and 'know everything.' Is it possible that the author is doing something that you don't know about? Such as writing and reading text to sockets (which would be I/O.) And is it possible they may have a reason to be using asyncio in Python (which uses a single main thread and hence needs something like asyncio for concurrency.) >Needless to say that the whole benchmark is worthless Overhead startup isn't worthless. 'I mean, I know, in Pythonland this is just your average Wednesday' and here we go. The whole post was really just you trying to make out that you're superior to everyone else. In this case looking down on an entire ecosystem. Why? Python is one of the most popular languages. It has an elegant syntax and it's capable of solving most problems. Go jerk yourself off in private.

crabbone 4y ago
> This reply strongly reads of 'im smarter than eveyone' Dude, where's everyone, where? I'm smarter than the guy who posted this nonsense about asyncio, that's for sure, but that's a very low bar... Now, when it comes to Python, then, it's an environment that is flooded with the programmers with the lowest skill level imaginable. This is where all those month-long bootcamps pump their graduates, this is where all the people who took a month-long intro to CS with Python class go, this is where a lot of people who only use Python accidentally, to compliment some other programming activity (or just general computer-related activity) go. It's a swamp, and there's no reason to pretend it isn't. On the other hand, anyone who had any serious aspirations for Python left the scene ten or so years ago. Today, Python is the worst parts of Java and PHP combined. So, again, it's a very low bar to be better than most Python programmers. Without even trying, when I searched for a job and had to do a bunch of automated assessment tests, I was consistently placed in the "best" decile, often in the "best 5%" of all applicants, and I hate the language. I'm honestly not good at it and don't want to be good at it. You don't need to try hard to be "as good" as I am, because I'm not good... but, yeah, in this particular area everyone is hands down awful. I also had to interview about two dozens of applicants in my last job. I had people who couldn't explain the difference between expression and statement. I had people who couldn't tell what __str__() method is for. I had extremely low expectations, and yet I was consistently disappointed by the knowledge level of applicants. It's surreal what's going on there. --- > Overhead startup isn't worthless. Yeah, maybe... OP never measured it anyways. OP never created any asynchronous I/O tasks. OP measured how long does it take to run couple functions in Python. Admittedly, it takes a long time, but it's irrelevant to async I/O. Especially in the context of comparing whatever OP's doing to threads. Which was their goal stated in the opening statement.

traverseda 4y ago

Python asyncio is actually a co-operative multitasking system, think real-time operating system type stuff. It doesn't do real concurrency but it gives you a nice interface for reasoning about tasks (think thread) while being able to explicitly control when/where they yield control of the event loop, how often they run, etc. >How are your message queues not doing I/O? We generally wouldn't consider in-process moving data around to be "I/O", now if you started interacting with an external database/file/pipe/MMAP-ed-file/etc than that would be "I/O". >What on Earth are they doing then? Tasks. Kind of like processes but lighter weight. Running an event loop, dispatching signals, that sort of thing. You can do all that by manually writing your own event loop but python's asyncio (IMO) makes it easier to reason about exactly when your yielding the event loop to some other task, and makes it easier to write code that can yield control of the event loop at arbitrary places. So like if you want to update a widget every 10 seconds you can write something like while True: await asyncio.sleep(10) #Other tasks can run during this 10 seconds sleep #Update widget contents Useful for stuff that needs to periodically poll data, like a process monitor, or even for just simple clock widgets. --- As an aside that cooperative multitasking can be really nice in micropython, where you can write tight loops in straight assembly if you need to and still get a pleasant task interface for managing higher level tasks/threads. Combined with some interrupt handlers it makes a pretty elegant real-time-ish operating system. (You probably need to manually deal with garbage collections though)

philote 4y ago

Message queues can be implemented in memory, so no network or disk I/O. In fact, it seems this project does use the built-in "queue" library: https://docs.python.org/3/library/queue.html https://docs.python.org/3/library/queue.html

crabbone 4y ago
Lol. Waht I/O to disk? What are you talking about? Asyncio was never about disk I/O. It's about Internet socket I/O exclusively. But, what do you think happens when you write (input) data to memory and then read (output) it from memory? I'll help you: it starts with "I" and ends with "O"!
- biorach 4y ago
  > Asyncio was never about disk I/O. It's about Internet socket I/O exclusively. Game over. You have no clue what you're talking about.
- greenshackle2 4y ago
  > But, what do you think happens when you write (input) data to memory and then read (output) it from memory? I'll help you: it starts with "I" and ends with "O"! That's.. that's not what people mean when they talk about I/O in this context. But I think you know that, you're just grasping at straws to win an argument.

greenshackle2 4y ago

Asyncio is for cooperative multitasking. I/O is the most common use case but it's not the only one. They're using the event loop to schedule their GUI tasks. Textual is a framework for building desktop apps. I assume the message queues are in-memory structures used to pass messages between tasks, hence no I/O. This is really fairly standard stuff. I understand you may not be familiar with GUI software and/or the Python ecosystem but jumping straight to condescension when you don't understand something is not really a good attitude.

louwrentius 4y ago

I knew you would be here in the comments. Crabbone won't leave any chance he gets to shit and dump on Python any HN post he can. Must be so frustrating, knowing that this silly language is one of the most populair programming languages in the world, despite its short comings, one of which is slower performance. This isn't about python or any language. The extreme negative tone and sense of superiority seems to point to something else. What is it?

crabbone 4y ago
I don't care about Python performance. But, yes, I'm very frustrated this trash is so popular. I never made this a secret :| Python deserves negative tone, and if you think that popularity somehow makes it exempt from criticism, then you deserve the same.
- louwrentius 4y ago
  But this isn't about "something being popular makes it exempt from criticism". You don't really criticise. You just exaggerate and emo-dump all over python and the people who use it. Your stance seems to be that python needs to be destroyed and dumped and replaced by some other language. Your stance is that people who use python are idiots. That kind of 'criticism' is so totally useless it's kind of seriously pathological. Your 'critisism' says more about you (due to the extremely antagonising tone) and not much about Python really. Quite sad when you think about it.