3 ms·

Python has a standard interface just like Go's `io.{Read,Writ}er`: the `send` and `recv` methods as defined by `socket.socket`. The appeal of "sans I/O" protoco

Python has a standard interface just like Go's `io.{Read,Writ}er`: the `send` and `recv` methods as defined by `socket.socket`. The appeal of "sans I/O" protocol implementations is primarily for asynchronous I/O, which requires a completely different style of interface. The clever thing about Go is not the standardization of a reader/writer interface, but the fact that the goroutine I/O scheduler makes these synchronous interfaces nearly as efficient as asynchronous ones, so there is no need to introduce a separate family of asynchronous interfaces.

jerf 10y ago
"Python has a standard interface just like Go's `io.{Read,Writ}er`: the `send` and `recv` methods as defined by `socket.socket`." But a File has no "send" and "recv". io.Reader and Writer apply to files, sockets, byte slices, strings, compositions of other Readers or Writers, HTTP request and response bodies, and anything else that strikes my fancy to implement the correct methods. Sockets appear to deliberately not have those methods, as there's this line in the docs: "Note that there are no methods read() or write(); use recv() and send() without flags argument instead." There's nothing preventing Python from having the equivalent of Reader and Writer. It just doesn't, at least not with the standard library. In fact that's true of a lot of languages; there's nothing preventing that interface from existing, it just doesn't. This is a point in favor of getting the standard library right earlier rather than a point in favor of Go-the-language.
- solidsnack9000 10y ago
  How would a standard interface like this support async IO?
  - infinite8s 10y ago
    Callbacks would be one way.
  - jerf 10y ago
    It's easy enough to shim an async version to become sync, but impossible to go the other way (modulo gevent). So again let me underline what I said before, that this is more a "standard library" problem than a language problem. Conceivably, Python could adopt Readers/Writers into the standard library, but it's late now. Python 2.0 didn't have the requisite stuff in the library to make the idea work, so modern-day penetration would be low. Go and other recent languages benefit from experience, and by putting these things in correctly from day one, can move on to the next problems we'll discover in standard libraries. :) Sometimes people ask why we need new languages, and I think "get a fresh start on a standard library" is at least halfway to a valid answer. Imagine if Java the language stayed exactly the same, but we could reach into an alternate universe where a brand new batteries-included standard library was written based on the language as it is now. It would still be Java, but it would be a much better Java, with better interoperability between many currently-separate worlds through standardized, sensible interfaces and extension points, taking full advantage of lambdas, probably dropping the stupid synchronization stuff even if it is nominally in the language, etc. I think the end result is still something I wouldn't love, but it would be much better. But one can only dream about that.
    - solidsnack9000 10y ago
      Are Reader/Writer async?
- Animats 10y ago
  "send" and "recv" for sockets are a Berkeleyism from BSD, where networking was an add-on alongside the existing UNIX kernel. The distinction is historical, not functional. "select" works on both file-like objects and socket-like objects on Linux. Under QNX, "write" and "read" work on sockets, and "send" and "recv" are just alternate functions for "write" and "read". Whether Python should hide that distinction is not clear, but it could.

jerf 10y ago

"Python has a standard interface just like Go's `io.{Read,Writ}er`: the `send` and `recv` methods as defined by `socket.socket`." But a File has no "send" and "recv". io.Reader and Writer apply to files, sockets, byte slices, strings, compositions of other Readers or Writers, HTTP request and response bodies, and anything else that strikes my fancy to implement the correct methods. Sockets appear to deliberately not have those methods, as there's this line in the docs: "Note that there are no methods read() or write(); use recv() and send() without flags argument instead." There's nothing preventing Python from having the equivalent of Reader and Writer. It just doesn't, at least not with the standard library. In fact that's true of a lot of languages; there's nothing preventing that interface from existing, it just doesn't. This is a point in favor of getting the standard library right earlier rather than a point in favor of Go-the-language.

solidsnack9000 10y ago
How would a standard interface like this support async IO?
- infinite8s 10y ago
  Callbacks would be one way.
- jerf 10y ago
  It's easy enough to shim an async version to become sync, but impossible to go the other way (modulo gevent). So again let me underline what I said before, that this is more a "standard library" problem than a language problem. Conceivably, Python could adopt Readers/Writers into the standard library, but it's late now. Python 2.0 didn't have the requisite stuff in the library to make the idea work, so modern-day penetration would be low. Go and other recent languages benefit from experience, and by putting these things in correctly from day one, can move on to the next problems we'll discover in standard libraries. :) Sometimes people ask why we need new languages, and I think "get a fresh start on a standard library" is at least halfway to a valid answer. Imagine if Java the language stayed exactly the same, but we could reach into an alternate universe where a brand new batteries-included standard library was written based on the language as it is now. It would still be Java, but it would be a much better Java, with better interoperability between many currently-separate worlds through standardized, sensible interfaces and extension points, taking full advantage of lambdas, probably dropping the stupid synchronization stuff even if it is nominally in the language, etc. I think the end result is still something I wouldn't love, but it would be much better. But one can only dream about that.
  - solidsnack9000 10y ago
    Are Reader/Writer async?
Animats 10y ago
"send" and "recv" for sockets are a Berkeleyism from BSD, where networking was an add-on alongside the existing UNIX kernel. The distinction is historical, not functional. "select" works on both file-like objects and socket-like objects on Linux. Under QNX, "write" and "read" work on sockets, and "send" and "recv" are just alternate functions for "write" and "read". Whether Python should hide that distinction is not clear, but it could.