[issue10144] Buffering bug after calling curses function
Fernando Perez fdo.pe...@gmail.com added the comment: No problem for us (IPython) if you mark it as won't fix. I've just applied the environment workaround you guys suggested: http://github.com/ipython/ipython/commit/147b245d2ead0e15d2c17b7bb760a03126660fb7 Thanks a lot for that tip! That leaves us in good shape. -- nosy: +fperez ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10144 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1170] shlex have problems with parsing unicode
Fernando Perez fdo.pe...@gmail.com added the comment: Yes, sorry that I failed to mention the example I gave applies only to 2.x, not to 3.x. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue1170 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1170] shlex have problems with parsing unicode
Fernando Perez fdo.pe...@gmail.com added the comment: On Tue, Jul 27, 2010 at 11:52, Alexander Belopolsky rep...@bugs.python.org wrote: Why do you expect shlex to work with unicode in 2.x? =A0The documentation clearly says that the argument should be a string. Supporting unicode is not an unreasonable RFE, but won't be considered for 2.x anymore. Well, I didn't make the original report, just provided a short, illustrative example :) It's easy enough to work around the issue for 2.x that I don't care too much about it, so I have no problem with 2.x staying as it is. What's your take on accepting bytes in 3.x? Mmh... Not too sure. I'd think about it from the perspective of what possible sources of input could produce raw bytes, that would be reasonable use cases for shlex. Is it common in 3.x to read a file in bytes mode? If so, then it might be a good reason to have shlex parse bytes as well, since I can imagine reading inputs from files to be parsed via shlex. But take my opinion on 3.x with a big grain of salt, I have very little experience with it as of yet. Cheers, f -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue1170 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1170] shlex have problems with parsing unicode
Fernando Perez fdo.pe...@gmail.com added the comment:
Here is an illustration of the problem with a simple test case (the value of
the posix flag doesn't make any difference):
Python 2.6.5 (r265:79063, Apr 16 2010, 13:09:56)
[GCC 4.4.3] on linux2
Type help, copyright, credits or license for more information.
import shlex
list(shlex.shlex('ab'))
['ab']
list(shlex.shlex(u'ab', posix=True))
['a', '\x00', '\x00', '\x00', 'b', '\x00', '\x00', '\x00']
list(shlex.shlex(u'ab', posix=False))
['a', '\x00', '\x00', '\x00', 'b', '\x00', '\x00', '\x00']
--
nosy: +fperez
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue1170
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7897] Support parametrized tests in unittest
Fernando Perez fdo.pe...@gmail.com added the comment: Hey Yarick, On Thu, Apr 8, 2010 at 18:53, Yaroslav Halchenko rep...@bugs.python.org w= rote: In PyMVPA we have our little decorator as an alternative to Fernando's ge= nerators, =A0and which is closer, I think, to what Michael was wishing for: @sweepargs http://github.com/yarikoptic/PyMVPA/blob/master/mvpa/testing/sweepargs.py NB it has some minor PyMVPA specificity which could be easily wiped out, = and since it was at most 4 eyes looking at it and it bears evolutionary c= hanges, it is far from being the cleanest/best piece of code, BUT: * it is very easy to use, just decorate a test method/function and give a= n argument which to vary within the function call, e.g smth like @sweepargs(arg=3Drange(5)) def test_sweepargs_demo(arg): =A0 =A0ok_(arg 5) =A0 =A0ok_(arg 3) =A0 =A0ok_(arg 2) For nose/unittest it would still look like a single test Thanks for the post; I obviously defer to Michael on the final decision, but I *really* would like a solution that reports an 'argument sweep' as multiple tests, not as one. They are truly multiple tests (since they can pass/fail independently), so I think they should be treated as such. On the other hand, your code does have nifty features that could be used as well, so perhaps the best of both can be used in the end. Cheers, f -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue7897 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7897] Support parametrized tests in unittest
Fernando Perez fdo.pe...@gmail.com added the comment: Yarick: Yes, I do actually see the value of the summary view. When I have a parametric test that fails, I tend to just run nose with -x so it stops at the first error and with the --pdb options to study it, so I simply ignore all the other failures. To me, test failures are quite often like compiler error messages: if there's a lot of them, it's best to look only at the first few, fix those and try again, because the rest could be coming from the same cause. I don't know if Michael has plans/bandwidth to add the summary support as well, but I agree it would be very nice to have, just not at the expense of individual reporting. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue7897 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7897] Support parametrized tests in unittest
Fernando Perez fdo.pe...@gmail.com added the comment: I should probably have clarified better our reasons for using this type of code. The first is the one Michael pointed out, where such parametric tests all execute; it's very common in scientific computing to have algorithms that only fail for certain values, so it's important to identify these points of failure easily while still running the entire test suite. The second is that the approach nose uses produces on failure the nose stack, not the stack of the test. Nose consumes the test generators at test discovery time, and then simply calls the stored assertions at test execution time. If a test fails, you see a nose traceback which is effectively useless for debugging and with which using --pdb for interactive debugging doesn't help much (all you can do is print the values, as your own stack is gone). This code, in contrast, evaluates the full test at execution time, so a failure can be inspected 'live'. In practice this makes an enormous difference in a test suite being actively useful for ongoing development where changes may send you into debugging often. I hope this helps clarify the intent of the code better, I'd be happy to provide further details. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue7897 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7897] Support parametrized tests in unittest
New submission from Fernando Perez fdo.pe...@gmail.com: IPython has unittest-based parametric testing (something nose has but which produces effectively undebuggable tests, while this approach gives perfectly debuggable ones). The code lives here for 2.x and 3.x: http://bazaar.launchpad.net/~ipython-dev/ipython/trunk/annotate/head%3A/IPython/testing/_paramtestpy2.py http://bazaar.launchpad.net/~ipython-dev/ipython/trunk/annotate/head%3A/IPython/testing/_paramtestpy3.py we import them into our public decorators module for actual use: http://bazaar.launchpad.net/~ipython-dev/ipython/trunk/annotate/head%3A/IPython/testing/decorators.py Simple tests showing them in action are here: http://bazaar.launchpad.net/%7Eipython-dev/ipython/trunk/annotate/head%3A/IPython/testing/tests/test_decorators.py#L45 The code is all BSD and we'd be more than happy to see it used upstream; the less we have to carry the better. If there is interest in this code, I'm happy to sign a PSF contributor agreement, the code is mostly my authorship. I received help for the 3.x version on the Testing in Python mailing list, I would handle asking for permission on-list if there is interest in including this. -- messages: 99149 nosy: fperez severity: normal status: open title: Support parametrized tests in unittest type: feature request versions: Python 2.7, Python 3.2 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue7897 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
