Re: [Python-Dev] test_sys failures
Guido van Rossum wrote: > When I build from scratch and run most tests (regrtest.py -uall) I get > some strange failures with test_sys.py: > > test test_sys failed -- Traceback (most recent call last): > File "/usr/local/google/home/guido/python/py3kd/Lib/test/test_sys.py", > line 302, in test_43581 > self.assertEqual(sys.__stdout__.encoding, sys.__stderr__.encoding) > AssertionError: 'ascii' != 'ISO-8859-1' > > The same test doesn't fail when run in isolation. > > Interestingly, I saw this with 2.5 as well as 3.0, but not with 2.6! > > Any ideas? It looks like the chunk of code in TextIOWrapper might be getting different answers when trying to work out the encoding for stdin and stderr (not that I can see how that would happen...). Or maybe there is some way that test_sys could be seeing the temporary '__stderr__' entry that is put in place until the io module is available? What do you get for stdin/stdout/stderr.encoding at the interactive prompt? On Ubuntu, I get UTF-8 for all of them in both 3.0a2 and 2.5.1, but I'm not seeing the problem, either. Other values of possible interest: os.device_encoding(1) os.device_encoding(2) locale.getpreferredencoding() Another possibility would be to throw some debugging code into io.py to print out the encoding name to stderr when file is 1 or 2. Cheers, Nick. -- Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia --- http://www.boredomandlaziness.org ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] epoll() and kqueue wrapper for the select module
Ross Cohen wrote: > Did you look at the python-epoll module which has been in the Cheese > Shop for quite some time? There is no messing with a low level control > file descriptor and it presents an identical interface to select.poll(). No, I didn't see the module. To be honest I didn't look at the Python Package Index but used Google to search for epoll wrappers. I found the wrapper in Twisted on my disk and two other wrappers. One was written in pure C and the other one used ctypes. Your wrapper is a good implementation. I even found an inconvenience in my implementation when I studied your code. My wrapper raised an exception when a closed fd was removed with EPOLL_CTL_DEL. > I would also claim that adding a new interface to accomplish the same > task is not more pythonic. But I did write the python-epoll module in > question, so I may be a bit biased. I agree with Gregory on that part of your answer. Christian ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Converting tests to unittest/doctest?
Hi all, a bit of grep'ping and personal examination discovered the following tests in trunk/ that could be converted to unittest or doctests. Any thoughts, pro or con? (I understand from Brett that the goal is to eradicate "old-style" tests, by which I think he means tests that do not use unittest or doctest. There are some good reasons to switch to using unittests, not least of which is that you can use a variety of frameworks (nose, py.test) to do value-added wrapping and management of such tests.) Suggestions for additional things to test or tests to modify, clean up, or extend and expand are welcome. thanks, --titus --- test_select test_contains test_crypt test_dbm test_dummy_threading test_errno test_getargs test_gdbm test_pep247 test_strftime test_thread test_queue test_fcntl test_format test_curses test_descr test_funcattrs test_gdbm test_socketserver ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] epoll() and kqueue wrapper for the select module
This makes me very happy. I could try to work on integrating this stuff in asyncore, if someone finds this of some interest. On 20 Dic, 18:08, Christian Heimes <[EMAIL PROTECTED]> wrote: > Linux Kernel 2.6+ and BSD (including Mac OS X) have two I/O event > notification systems similar but superior to select() and poll(). From > the manuals: > > kqueue, kevent -- kernel event notification mechanism > > The kqueue() system call provides a generic method of notifying the user > when an event happens or a condition holds, based on the results of > small pieces of kernel code termed filters. A kevent is identified by > the (ident, filter) pair; there may only be one unique kevent per kqueue. > > epoll - I/O event notification facility > > epoll is a variant of poll(2) that can be used either as an > edge-triggered or a level-triggered interface and scales well to large > numbers of watched file descriptors. > > I've written wrappers for both mechanisms. Both wrappers are inspired > from Twisted and select.poll()'s API. The interface is more Pythonic > than the available wrappers and it reduced the burden on the user. The > users don't have to deal with low level control file descriptors and the > fd is closed automatically when the object is collected. > > epoll interface > > >>> ep = select.epoll(1) > >>> ep.register(fd, select.EPOLL_IN | select.EPOLL_OUT) > >>> ep.modify(fd, select.EPOLL_OUT) > >>> events = ep.wait(1, 1000) > >>> ep.unregister(fd) > > kqueue interface > > The kqueue interface is more low level than the epoll interface. It has > too many options.>>> kq = select.kqueue() > >>> ev = [select.kevent(fd, select.KQ_FILTER_WRITE, > > select.KQ_EV_ONESHOT | select.KQ_EV_ADD)] > > >>> kq.control(ev, 0, 0) > >>> events = kq.control([], 1, None) > > I already talked to some Twisted guys and they really like it. A patch > is available athttp://bugs.python.org/issue1657. The code needs more > unit tests and documentation updates. > > Christian > > ___ > Python-Dev mailing list > [EMAIL PROTECTED]://mail.python.org/mailman/listinfo/python-dev > Unsubscribe:http://mail.python.org/mailman/options/python-dev/python-dev2-garchiv... ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Converting tests to unittest/doctest?
(oops, realized I didn't send it to the list, just to Titus) I remember that it was one of the tasks at the Python Sprint at Google last summer, so I guess this is a good idea (for GHOP, right ?) >From what remains of the spreadsheet used during the Sprint (http://spreadsheets.google.com/ccc?key=pBLWM8elhFAmKbrhhh0ApQA&pli=1), I believe you can add the following tests to your list: test_tokenize test_cProfile test_extcall test_logging test_profile test_thread (and maybe test_pep277 that seems to use both unittest and test.test_support ) HTH, Quentin On Dec 21, 2007 12:05 PM, Titus Brown <[EMAIL PROTECTED]> wrote: > Hi all, > > a bit of grep'ping and personal examination discovered the following > tests in trunk/ that could be converted to unittest or doctests. Any > thoughts, pro or con? > > (I understand from Brett that the goal is to eradicate "old-style" > tests, by which I think he means tests that do not use unittest or > doctest. There are some good reasons to switch to using unittests, not > least of which is that you can use a variety of frameworks (nose, > py.test) to do value-added wrapping and management of such tests.) > > Suggestions for additional things to test or tests to modify, clean up, > or extend and expand are welcome. > > thanks, > --titus > > --- > > test_select > test_contains > test_crypt > test_dbm > test_dummy_threading > test_errno > test_getargs > test_gdbm > test_pep247 > test_strftime > > test_thread > > test_queue > > test_fcntl > > test_format > > test_curses > > test_descr > > test_funcattrs > > test_gdbm > > test_socketserver > ___ > Python-Dev mailing list > [email protected] > http://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > http://mail.python.org/mailman/options/python-dev/qgallet%40gmail.com > ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Converting tests to unittest/doctest?
On Fri, Dec 21, 2007 at 04:02:21PM +0100, Quentin Gallet-Gilles wrote: -> (oops, realized I didn't send it to the list, just to Titus) -> -> I remember that it was one of the tasks at the Python Sprint at Google last -> summer, so I guess this is a good idea (for GHOP, right ?) Yep! -> >From what remains of the spreadsheet used during the Sprint -> (http://spreadsheets.google.com/ccc?key=pBLWM8elhFAmKbrhhh0ApQA&pli=1), -> I believe you can add the following tests to your list: -> -> test_tokenize -> test_cProfile -> test_extcall -> test_logging -> test_profile -> test_thread -> (and maybe test_pep277 that seems to use both unittest and test.test_support -> ) These were already done as part of GHOP, just not all checked in yet -- we're waiting for some contributor agreements. But thanks, that's exactly the sort of info I'm looking for! cheers, --titus ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Summary of Tracker Issues
ACTIVITY SUMMARY (12/14/07 - 12/21/07) Tracker at http://bugs.python.org/ To view or respond to any of the issues listed below, click on the issue number. Do NOT respond to this message. 1366 open (+27) / 11799 closed (+27) / 13165 total (+54) Open issues with patches: 426 Average duration of open issues: 689 days. Median duration of open issues: 926 days. Open Issues Breakdown open 1358 (+27) pending 8 ( +0) Issues Created Or Reopened (54) ___ Py_Size() should be named Py_SIZE() 12/14/07 CLOSED http://bugs.python.org/issue1629created rhettinger sys.maxint is documented but should not be 12/15/07 CLOSED http://bugs.python.org/issue1630created blair py3k Send output from subprocess.Popen objects to any object with a w 12/15/07 CLOSED http://bugs.python.org/issue1631created ngrover email cannot be imported 12/15/07 CLOSED http://bugs.python.org/issue1632created Wubbulous smtplib 12/15/07 CLOSED http://bugs.python.org/issue1633created Wubbulous with Statement SyntaxError generated while following Tutorial12/15/07 CLOSED http://bugs.python.org/issue1634created astral451 Float patch for inf and nan on Windows (and other platforms) 12/15/07 CLOSED http://bugs.python.org/issue1635created tiran py3k, patch Execfile unable to take arguments beyond 255!12/16/07 http://bugs.python.org/issue1636created jgatkinsn urlparse.urlparse misparses URLs with query but no path 12/16/07 http://bugs.python.org/issue1637created nagle %zd configure test fails on Linux12/16/07 CLOSED http://bugs.python.org/issue1638created hniksic Low ascii 12 characters found in source. 12/17/07 CLOSED http://bugs.python.org/issue1639created JosephArmbruster Enhancements for mathmodule 12/17/07 http://bugs.python.org/issue1640created tiran patch asyncore delayed calls feature 12/17/07 http://bugs.python.org/issue1641created giampaolo.rodola segfault when deleting value member in ctypes types 12/17/07 CLOSED http://bugs.python.org/issue1642created cfbolz Add group() to itertools 12/18/07 CLOSED http://bugs.python.org/issue1643created KirkMcDonald Patch submission guidelines outdated 12/18/07 CLOSED http://bugs.python.org/issue1644created albertito Fix socketmodule.c:sock_recvfrom_guts() comment. 12/18/07 CLOSED http://bugs.python.org/issue1645created albertito patch Make socket support TIPC.12/18/07 http://bugs.python.org/issue1646created albertito patch IDLE messes around with sys.exitfunc 12/18/07 http://bugs.python.org/issue1647created tiran py3k add new function, sys.gettrace 12/18/07
Re: [Python-Dev] Make socket support TIPC
On Tue, Dec 18, 2007 at 11:57:19AM -0300, Alberto Bertogli wrote: > I wrote a patch adding TIPC support to the socket module, you can find > it in http://bugs.python.org/issue1646. Well, I'm supposed to "tickle the interest of one of the many folks with commit privileges" about this, so here I am =) Is anyone interested in this patch? I have no idea what else is needed to get this in, so if anybody can give me some hints, I'd be great. Thanks a lot, Alberto ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] epoll() and kqueue wrapper for the select module
On Fri, Dec 21, 2007 at 11:28:55AM +0100, Christian Heimes wrote: > Your wrapper is a good implementation. I even found an inconvenience in > my implementation when I studied your code. My wrapper raised an > exception when a closed fd was removed with EPOLL_CTL_DEL. It should be a good reference, it's gotten a lot of testing. > > I would also claim that adding a new interface to accomplish the same > > task is not more pythonic. But I did write the python-epoll module in > > question, so I may be a bit biased. > > I agree with Gregory on that part of your answer. I think we can both be right. The select.poll() code does not really map to the low level poll() call. In fact, it maps much better to the epoll() call. It appears that your new API is really a superset of the the select.poll() interface. The only thing which keeps a user from just importing your module and using it with code which uses the existing interface is that you've changed names. Why not change the names so that it Just Works? Also, everything but the edge-triggered functionality could be incorporated back into the select.poll() interface (where "everything" means the modify() call.) Ross signature.asc Description: Digital signature ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Converting tests to unittest/doctest?
Hi Titus. Great work on GHOP! On Dec 21, 2007 3:05 AM, Titus Brown <[EMAIL PROTECTED]> wrote: > Hi all, > > a bit of grep'ping and personal examination discovered the following > tests in trunk/ that could be converted to unittest or doctests. Any > thoughts, pro or con? Yes, it would be great to get rid of the old style tests. I didn't verify your list, but it looked good. The most important ones to get rid of are the ones that compare output. It would also be great to fix the flaky tests. Nearly all are related to networking. I think Raymond started a thread about some of these issues. (Hopefully I'll catch up on some mail over the holidays.) The flaky tests are probably too large for GHOP, but feel free to try fix them. From memory the flakiest ones are: test_xmlrpc, test_urllib2, test_urllib2net n ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
