-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 20/10/10 00:58, Antoine Pitrou wrote:
It would be nice to know about the use case Jesus has in mind.
I am thinking about the cases where a request come, you do some disk
read in behalf of it and you reply.
If the read is slow (if not cached, you
On Oct 19, 2010, at 9:55 PM, exar...@twistedmatrix.com wrote:
Not only is the performance usually worse than expected, the behavior of
aio_* functions require all kinds of subtle and mysterious coordination with
signal handling, which I'm not entirely sure Python would even be able to
On Oct 20, 2010, at 12:31 AM, Jeffrey Yasskin wrote:
No comment on the rest of your claim, but this is a silly argument.
The standard says the same thing about at least fcntl.h, signal.h,
pthread.h, and ucontext.h, which clearly are useful.
It was meant to be tongue-in-cheek :). Perhaps I
On Wed, Oct 20, 2010 at 2:55 PM, Glyph Lefkowitz
gl...@twistedmatrix.com wrote:
On Oct 20, 2010, at 12:31 AM, Jeffrey Yasskin wrote:
No comment on the rest of your claim, but this is a silly argument.
The standard says the same thing about at least fcntl.h, signal.h,
pthread.h, and
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Current Python lacks support for aio_* syscalls to do async IO. I
think this could be a nice addition for python 3.3.
If you agree, I will create an issue in the tracker. If you think the
idea is of no value, please say so for me to move on. Maybe an
Yes, that would be a nice addition. -peter
On 10/19/10 12:50 PM, Jesus Cea j...@jcea.es wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Current Python lacks support for aio_* syscalls to do async IO. I
think this could be a nice addition for python 3.3.
If you agree, I will create
On 04:50 pm, j...@jcea.es wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Current Python lacks support for aio_* syscalls to do async IO. I
think this could be a nice addition for python 3.3.
Adding more platform wrappers is always nice. Keep in mind that the
quality of most (all?)
You should file a new issue on the bug tracker but unless you have a
patch to propose it's unlikely that someone else is gonna implement
it.
Regards
--- Giampaolo
http://code.google.com/p/pyftpdlib/
http://code.google.com/p/psutil/
2010/10/19 Jesus Cea j...@jcea.es:
-BEGIN PGP SIGNED
On Oct 19, 2010, at 1:47 PM, exar...@twistedmatrix.com wrote:
Adding more platform wrappers is always nice. Keep in mind that the quality
of most (all?) aio_* implementations is spotty at best, though. On Linux,
they will sometimes block (for example, if you fail to align buffers
Hello Jesus,
Current Python lacks support for aio_* syscalls to do async IO. I
think this could be a nice addition for python 3.3.
If you agree, I will create an issue in the tracker. If you think the
idea is of no value, please say so for me to move on. Maybe an 3th party
module, but I
Am 19.10.2010 19:47, schrieb exar...@twistedmatrix.com:
On 04:50 pm, j...@jcea.es wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Current Python lacks support for aio_* syscalls to do async IO. I
think this could be a nice addition for python 3.3.
Adding more platform wrappers is
So, in conclusion, I disagree that adding wrappers for these would be
nice. It wouldn't. It would cause some people to think they would be
useful things to call, and they would always be wrong.
We are all consenting adults. If people want to shoot themselves in
their feet, we let them. For
Also, the canonical way to do file I/O in Python 3 is the `io` lib,
therefore it would be a bit of a shame to have separate, non-integrated
`aio_*` functions.
I disagree. We also have posix.open, posix.dup, etc. We always expose
POSIX functions in the posix module (except for the socket
Le mercredi 20 octobre 2010 à 00:48 +0200, Martin v. Löwis a écrit :
Also, the canonical way to do file I/O in Python 3 is the `io` lib,
therefore it would be a bit of a shame to have separate, non-integrated
`aio_*` functions.
I disagree. We also have posix.open, posix.dup, etc. We
On Oct 19, 2010, at 6:44 PM, Martin v. Löwis wrote:
So, in conclusion, I disagree that adding wrappers for these would be
nice. It wouldn't. It would cause some people to think they would be
useful things to call, and they would always be wrong.
We are all consenting adults. If people want
On Oct 19, 2010, at 8:09 PM, James Y Knight wrote:
There's a difference.
os._exit is useful. os.open is useful. aio_* are *not* useful. For anything.
If there's anything you think you want to use them for, you're wrong. It
either won't work properly or it will worse performing than the
On 01:37 am, gl...@twistedmatrix.com wrote:
On Oct 19, 2010, at 8:09 PM, James Y Knight wrote:
There's a difference.
os._exit is useful. os.open is useful. aio_* are *not* useful. For
anything. If there's anything you think you want to use them for,
you're wrong. It either won't work
On Tue, Oct 19, 2010 at 8:37 PM, Glyph Lefkowitz
gl...@twistedmatrix.com wrote:
I'd like to echo this sentiment. This is not about providing a 'safe'
wrapper to hide some powerful feature of these APIs: the POSIX aio_*
functions are really completely useless.
To quote the relevant standard
18 matches
Mail list logo
