[issue1646] Make socket support TIPC.
Christian Heimes added the comment: I've chatted with albertito a few days ago and adviced him to post the patch here. I'll take it. From the first review the patch looks good. The code is written cleanly and it uses the appropriate API. The new code is surrounded by ifdefs and it has a patch for configure.in. I'll do the autoreconf to update the other files locally. The patch is missing documentation updates, Misc/NEWS update and some unit tests. The docs should list the new constants and explain TIPC briefly in a few sentences. You don't need to write a novell ;) -- assignee: - tiran nosy: +tiran __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1646 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1657] [patch] epoll and kqueue wrappers for the select module
Christian Heimes added the comment: I attached a patch with a more complete test of kqueue. It's not that great, but it's a thing. I've only tested on OS X, but it works. A small unit test is better than no unit test :) Regarding the ability of building an epoll object from a fd, it might be usefull in some corner cases, but that's not a priority. It should be trivial to add an epoll.fromfd() classmethod. exarkun looked at the patch and told me that there may be some threadsafety issues: for example, when calling epoll_wait, you use self-evs unprotected. It's not very important, but you may want to tell it in the documentation. I found an interesting article about epoll. It states that epoll_wait() is thread safe. Ready lists of two parallel threds never contain the same fd. http://lwn.net/Articles/224240/ It's easier to remove the buffer and allocate memory inside the wait() method than to add semaphores. It makes the code. As you started the rich comparison for kevent objects, it may be interesting to have full comparison (to sort list of events). It's not a high priority though. What do you suggest as sort criteria? __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1657 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1657] [patch] epoll and kqueue wrappers for the select module
Thomas Herve added the comment: What do you suggest as sort criteria? The natural sort of the tuple you used for equality, I'd say. __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1657 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1687] plistlib.py restricts integer to Python int when writing
New submission from lafcadio: In PlistWriter.writeValue() the line elif isinstance(value, int): should be changed to elif isinstance(value, int) or isinstance(value, long): since in http://www.apple.com/DTDs/PropertyList-1.0.dtd is no limitation to signed 32-bit integer. It occured an error when I tried to write an iTunes Music Library.xml for the line keyPlay Date/keyinteger3221924209/integer. -- components: Demos and Tools, Macintosh, XML messages: 58963 nosy: lafcadio severity: normal status: open title: plistlib.py restricts integer to Python int when writing type: behavior versions: Python 2.3, Python 2.4, Python 2.5 __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1687 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1580] Use shorter float repr when possible
Tim Peters added the comment: If someone has a more recent version of MS's compiler, I'd be interested to know what this does: inc = 2.0**-43 base = 1024.0 xs = ([base + i*inc for i in range(-4, 0)] + [base] + [base + 2*i*inc for i in (1, 2)]) print xs print [%.16g % x for x in xs] That creates 7 distinct doubles all of which map to 1024 when correctly rounded to 16 significant digits. And that's what the Cygwin Python 2.5.1 (which presumably uses David Gay's correct-rounding conversion routines from glibc) displays for the last line: ['1024', '1024', '1024', '1024', '1024', '1024', '1024'] The released Windows Python 2.5.1 displays this instead: ['1024', '1024', '1024', '1024', '1024', '1024', '1024.0001'] That's a pretty gross rounding error, since the exact value of the last element is 1024.45474735088646411895751953125 and so the 16'th digit should indeed not round up to 1. It's a pretty gross error because the rounded-off part isn't particularly close to a half unit in the last (16'th) place. __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1580 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
