[Python-Dev] Proposal for new core module: UserFIle (original) (raw)
Keith Dart kdart at kdart.com
Sat Dec 13 19:34:46 EST 2003
- Previous message: [Python-Dev] Proposal for new core module: UserFIle
- Next message: [Python-Dev] New module proposal: timelib
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
On Sat, 2003-12-13 at 07:35, Oren Tirosh wrote:
Some people think that "threads suck" while others swear by them. The Python language supports both the threaded and event-driven I/O programming styles and generally avoids taking sides on programming style holy wars.
I guess it depends on what you are trying to do. I do a lot of "low-level" programming in Python (lots of system calls, signals, pipes, etc.) and sometimes I feel like Python is not well suited for that... But I suppose if one were writing some data processing or GUI-style application then threads would be more appropriate.
Some people think that "signals suck" while others use them happily. Our BDFL happens to be on the "signals suck" camp and is taking a side by refusing EINTR retry loops around Python's I/O calls.
It appears so. 8-)
The signal module has been reluctantly accepted into Python but if you want to actually use it you are on your own - don't use the builtin file object and implement all I/O calls yourself with the os module so you can retry on EINTR.
Yep, I have practically done that. I have a large number of "forked" modules that utilize the async I/O model. I was thinking it would be cool to get that part of the standard library. Now I see that might not be possible.
Personally, I can't see what harm could come from making Python I/O EINTR-safe but Guido made it clear that such patches will not be accepted. Good luck.
Yep, thanks.
-- -- ------------------------------------------------------------------------- Keith Dart <mailto:kdart at kdart.com> <http://www.kdart.com/>
Public key ID: B08B9D2C Public key: <http://www.kdart.com/~kdart/public.key>
-------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part Url : http://mail.python.org/pipermail/python-dev/attachments/20031213/9b7e966b/attachment.bin
- Previous message: [Python-Dev] Proposal for new core module: UserFIle
- Next message: [Python-Dev] New module proposal: timelib
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]