On Sep 25, 2:07 pm, Grant Edwards <inva...@invalid.invalid> wrote: > On 2009-09-25, Jason Tackaberry <t...@urandom.ca> wrote: > > > And I maintain that requiring yield doesn't make it any less a > > coroutine. > > > Maybe we can call this an aesthetic difference of opinion? > > Certainly. > > You've a very valid point that "transparent" can also mean > "invisible", and stuff happening "invisibly" can be a source of > bugs. All the invisible stuff going on in Perl and C++ has > always caused headaches for me.
There are some key advantages to this transparency, especially in the case of libraries built on libraries. For example, all the networking libraries that ship in the Python standard lib are based on the sockets library. They assume the blocking implementation, but then add HTTPS, cookie handling, SMTP, and all sorts of higher-level network protocols. I want to use non-blocking network I/O for (concurrency) performance. I don't want to re-write an SMTP lib - my language ships with one. However, it is not possible for someone to write a non-blocking socket that is a drop-in replacement for the blocking one in the std lib. Thus, it is not possible for me to use _any_ of the well-written libraries that are already part of Python's standard library. They don't have yields sprinkled throughout, so they can't work with a non- blocking, co-routine implemented socket. And they certainly aren't written against the non-blocking I/O APIs. Thus, the efforts by lots of people to write entire network libraries that, basically, re-implement the Python standard library, but change the implementation of 7 methods (bind, listen, accept, connect, send, recv, close). They end up having to duplicate tens of thousands of LoC, just to change 7 methods. That's where transparency would be nice - to enable that separation of concerns. -- http://mail.python.org/mailman/listinfo/python-list
