[issue5393] cmath.cos and cmath.cosh have "nResult" typo in help

New submission from Michael Newman : cmath.cos and cmath.cosh have "nResult" typo in their help text. """ Python 3.0.1 (r301:69561, Feb 13 2009, 20:04:18) [MSC v.1500 32 bit (Intel)] on win32 Type "help", "copyright", "credits" or &q

[issue5435] test_httpservers on Debian Testing

New submission from Michael Zamot : Hi, im trying to compile Python 3.0.1 under Debian Testing, and i get an error in the step make test. test_https fails with errno 13. The atach file has the full output. So, what is missing in my computer or what i need to do, to compile it, thanks and sorry

[issue5435] test_httpservers on Debian Testing

Michael Zamot added the comment: I tried too yesterday with the svn version, and i get the same error. Is there a solution or im doing something wrong? ___ Python tracker <http://bugs.python.org/issue5

[issue5435] test_httpservers on Debian Testing

Michael Zamot added the comment: I dont know, it weird, because im running the test as root. I tried in a Stable Lenny, and nothing too ___ Python tracker <http://bugs.python.org/issue5

[issue5435] test_httpservers on Debian Testing

Michael Zamot added the comment: I re-download again (maybe its the four time jaja) the python 3.0.1 from the svn and now, it pass all the tests. Thanks to all! ___ Python tracker <http://bugs.python.org/issue5

[issue5532] imap usage in itertools unique_justseen recipe

New submission from Michael Newman : The recipe for "unique_justseen" listed on: http://docs.python.org/3.0/library/itertools.html uses "imap", which is not available in Python 3.0. I fixed it by changing "imap" to just "map", and I also changing "

[issue5595] os.path.ismount (ntpath) gives UnboundLocalError for any input

New submission from Michael Newman : os.path.ismount gives UnboundLocalError for any input in Python 3.0: Python 3.0.1 (r301:69561, Feb 13 2009, 20:04:18) [MSC v.1500 32 bit (Intel)] on win32 Type "help", "copyright", "credits" or "license" for more inf

[issue2578] Figure out what to do with unittest's redundant APIs

Michael Foord added the comment: New patch with assertRaisesWithRegexMatch as a context manager. -- keywords: +patch nosy: +mfoord Added file: http://bugs.python.org/file13484/unittest-new-asserts.diff ___ Python tracker <http://bugs.python.

[issue2578] Figure out what to do with unittest's redundant APIs

Michael Foord added the comment: Updated patch with asserts in unittest changed to explicitly raising self.failureException, hardcoded AssertionError in tests changed to self.failureException and addition of assertRegexMatches. -- Added file: http://bugs.python.org/file13488/unittest

[issue2578] additional unittest type equality methods

Michael Foord added the comment: If the deprecation causes noise people can just turn off the deprecation warning surely? Especially as transforming a codebase really is as simple as a global search and replace. Personally I'd prefer earlier deprec

[issue5663] Better failure messages for unittest assertions

New submission from Michael Foord : Patch for unittest on trunk. It provides better default failure messages for assertTrue and assertFalse (current is "AssertionError: None"). It also provides a new class attribute for TestCase: longMessage This defaults to False. If set to True,

[issue5663] Better failure messages for unittest assertions

Michael Foord added the comment: Reviewers: , Description: Patch for unittest on trunk. It provides better default failure messages for assertTrue and assertFalse (current is "AssertionError: None"). It also provides a new class attribute for TestCase: longMessage This defaults to

[issue5663] Better failure messages for unittest assertions

Michael Foord added the comment: Updated patch with better docstring for _formatMessage and docs. Patch reviewed by Brett Cannon so will commit. -- Added file: http://bugs.python.org/file13568/unittest-messages.diff ___ Python tracker <h

[issue5663] Better failure messages for unittest assertions

Changes by Michael Foord : -- resolution: -> accepted status: open -> closed ___ Python tracker <http://bugs.python.org/issue5663> ___ ___ Python-bugs-list

[issue5660] Cannot deepcopy unittest.TestCase instances

Changes by Michael Foord : -- nosy: +michael.foord ___ Python tracker <http://bugs.python.org/issue5660> ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue5660] Cannot deepcopy unittest.TestCase instances

Michael Foord added the comment: This is a workaround: import copy copy._deepcopy_dispatch[types.MethodType] = copy._deepcopy_atomic -- ___ Python tracker <http://bugs.python.org/issue5

[issue5660] Cannot deepcopy unittest.TestCase instances

Michael Foord added the comment: We can fix this by wrapping the assert functions in our assert register as deep-copyable objects. (And then unwrapping when we fetch them.) -- ___ Python tracker <http://bugs.python.org/issue5

[issue5660] Cannot deepcopy unittest.TestCase instances

Michael Foord added the comment: Fixed in revision 71043. -- resolution: -> fixed status: open -> closed ___ Python tracker <http://bugs.python.org/

[issue2578] additional unittest type equality methods

Michael Foord added the comment: Why do you need the assert methods to go away in order to use assert statements? -- ___ Python tracker <http://bugs.python.org/issue2

[issue2578] additional unittest type equality methods

Michael Foord added the comment: No - you catch self.failureException rather than AssertionError directly. I use unittest precisely because of the rich failure information from the assert methods - particularly the new ones in this patch

[issue5435] test_httpservers on Debian Testing

Michael Zamot added the comment: yes it ran with normal user :-) thanks now im enjoying python 3k ;-) 2009/3/23 Facundo Batista > > Facundo Batista added the comment: > > CGI tests shouldn't be run as root, it seems, as it breaks the inherent > protection. &

[issue5538] tearDown in unittest should be executed regardless of result in setUp

Michael Foord added the comment: +1 on adding a cleanUp list where entries are executed unconditionally even on failure of setUp. If there is consensus that this is a good thing (looks like it to me from the discussion here) then I can apply the patch to head. I'll review it first and

[issue5538] tearDown in unittest should be executed regardless of result in setUp

Michael Foord added the comment: OK, so the patch as submitted *isn't* for the cleanUp suggestion (d'oh - I should have read it before posting the last comment). One possibility is that this bug is closed as won't fix (the patch as provided should definitely not be applied

[issue2578] additional unittest type equality methods

Michael Foord added the comment: Why is assertMultiLineEqual not the default assert method for basestring? Even for small strings the output is useful. -- ___ Python tracker <http://bugs.python.org/issue2

[issue5679] cleanUp stack for unittest

New submission from Michael Foord : Proposal to add a cleanUp stack to unittest.TestCase. This is a list of callables to be called (LIFO) to cleanup resources. If there are items on the stack it should be called even if setUp fails. Otherwise it should be called after tearDown. Similar

[issue5679] cleanUp stack for unittest

Michael Foord added the comment: This is a nice (simple to use and understand) pattern for resource allocation / deallocation. Supporting the cleaning up of resources when setUp fails (without duplicating clean up code) is just one use case. (I agree setUp failure is unusual.) It provides a

[issue5679] cleanUp stack for unittest

Michael Foord added the comment: >From your example this would completely remove the need for the conditional checking in the cleanup code. Only resources actually allocated would be in the stack. -- ___ Python tracker <http://bugs.pyth

[issue2578] additional unittest type equality methods

Michael Foord added the comment: Fair point. :-) -- ___ Python tracker <http://bugs.python.org/issue2578> ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue5538] tearDown in unittest should be executed regardless of result in setUp

Michael Foord added the comment: Closing. The patch as suggested should not be applied. Instead tearDown should be called in a finally block in the setUp for this specific use case. I've created a new issue (#5679) for the cleanUp idea which I think is

[issue5679] cleanUp stack for unittest

Changes by Michael Foord : -- type: behavior -> feature request ___ Python tracker <http://bugs.python.org/issue5679> ___ ___ Python-bugs-list mailing list Un

[issue5679] cleanUp stack for unittest

Michael Foord added the comment: And actually your conditionally_undo_setup() call in setUp is incorrect. It should in an except block that re-raises rather than a finally block (which will do the cleanup even in non-exceptional circumstances). Easy code to get wrong

[issue1745] Backport of PEP 3102 "keyword-only arguments" to 2.6

Michael Foord added the comment: Running out of time for 2.7 as well... -- nosy: +michael.foord ___ Python tracker <http://bugs.python.org/issue1745> ___ ___

[issue2578] additional unittest type equality methods

Michael Foord added the comment: I'd like to add assertIs and assertNotIs. We have these at work and I would find them useful whilst writing tests for another set of changes to unittest I'm currently working on! -- ___ Python trac

[issue2578] additional unittest type equality methods

Michael Foord added the comment: I would *mmuch* prefer assertIsNot but it is not symmetrical with the other asserts. -- ___ Python tracker <http://bugs.python.org/issue2

[issue5679] cleanUp stack for unittest

Michael Foord added the comment: Patch attached. No docs, if it is agreed I can apply I'll write docs. After a long discussion we arrived at some semblance of consensus on the Testing In Python mailing list that this was a good thing (tm). Only one -1 (thought that cleanUp should be a m

[issue5679] cleanUp stack for unittest

Michael Foord added the comment: I'm agnostic on before / after tearDown, so happy to make that change. -- ___ Python tracker <http://bugs.python.org/i

[issue2578] additional unittest type equality methods

Michael Foord added the comment: Patch with assertIs and assertIsNot. Docs but nothing in NEWS as already covered. Ok to apply? -- Added file: http://bugs.python.org/file13613/unittest-assertis.diff ___ Python tracker <http://bugs.python.

[issue2578] additional unittest type equality methods

Michael Foord added the comment: Patch for Py3k with fallback for comparing unsortable sequences in assertSameElements. Removed the expected failure and added another test case to confirm that this patch works for unsortable sequences that are the same (no fail) and different (fail

[issue5693] TestSuite.__iter__ is not hookable.

Michael Foord added the comment: +1 it's a minor change. -- nosy: +michael.foord ___ Python tracker <http://bugs.python.org/issue5693> ___ ___ Python-bugs-l

[issue5679] cleanUp stack for unittest

Michael Foord added the comment: Antoine, Robert suggests calling it after tearDown so that tearDown can also perform actions that need clean up. Not a common use case but at least a use case. What do you mean by: "so that test cases can also use it to initialize additional resource

[issue5679] cleanUp stack for unittest

Michael Foord added the comment: The main use case for addCleanup is resource allocation in tests. Why does this require clean ups to be executed before tearDown? -- ___ Python tracker <http://bugs.python.org/issue5

[issue5693] TestSuite.__iter__ is not hookable.

Changes by Michael Foord : -- resolution: -> accepted status: open -> closed ___ Python tracker <http://bugs.python.org/issue5693> ___ ___ Python-bugs-list

[issue2578] additional unittest type equality methods

Michael Foord added the comment: Committed in revision 71263. Closing as there is nothing outstanding on this issue. -- resolution: -> accepted status: open -> closed ___ Python tracker <http://bugs.python.org/

[issue2821] unittest.py sys.exit error

Michael Foord added the comment: IDLE catches the SystemExit function raised by TestProgram().runTests() and prints the traceback. Not a bug in unittest. -- nosy: +michael.foord resolution: -> works for me status: open -> closed ___ Python t

[issue5679] cleanUp stack for unittest

Michael Foord added the comment: I'm in favour of running clean ups afterwards on the basis that it makes things possible that would otherwise not be possible. > If your cleanup relies on something which has been set up during setUp > and will be dropped during tearDown (a database

[issue5679] cleanUp stack for unittest

Michael Foord added the comment: A use case for running clean ups before tearDown (in which case addCleanUp would need to raise an exception if called during tearDown). You have existing code which (for example) creates an SSH connection in setUp and removes it in tearDown. If clean ups are

[issue5679] cleanUp stack for unittest

Michael Foord added the comment: This is actually a minor point about the order things happen in. I don't think it will cause confusion in practise once we have made a decision and documented it. Particularly if we decide to call clean ups before tearDown then I will make adding new

[issue5679] cleanUp stack for unittest

Michael Foord added the comment: @Garrett / Virgil I don't think anything other than very short term confusion is possible. Whichever decision is made a developer who assumes the opposite will actually get an error. In both cases the downside is that in certain circumstances you could at

[issue5679] cleanUp stack for unittest

Michael Foord added the comment: My apologies - the jml code on launchpad runs clean ups before taerDown. http://bazaar.launchpad.net/~jml/testtools/trunk/annotate/head%3A/testtools/testcase.py -- ___ Python tracker <http://bugs.python.

[issue1774840] Not exiting when running tests

Changes by Michael Foord : -- nosy: +michael.foord -fuzzyman ___ Python tracker <http://bugs.python.org/issue1774840> ___ ___ Python-bugs-list mailing list Unsub

[issue1774840] Not exiting when running tests

Changes by Michael Foord : -- stage: test needed -> needs patch ___ Python tracker <http://bugs.python.org/issue1774840> ___ ___ Python-bugs-list mai

[issue1774840] Not exiting when running tests

Michael Foord added the comment: Seems like a straightforward request although TestProgram is pretty horrible in my opinion. I'll add an exit argument to TestProgram.__init__ - don't look forward to testing it though. -- ___ Python trac

[issue3379] Option to not-exit on test

Michael Foord added the comment: Not returning the results is not a problem - if you needed access to the results you would hardly be using this API in the first place. The obvious use case if for running tests from an interactive environment where you are using the visual output on stdout

[issue588825] unittest.py, better error message

Michael Foord added the comment: This feature request was recently implemented using the 'longMessage' class attribute on TestCase. -- resolution: -> out of date status: open -> closed ___ Python tracker <http://bugs.pyt

[issue5728] Support telling TestResult objects a test run has finished

Michael Foord added the comment: startTestRun and stopTestRun sound good to me. -- ___ Python tracker <http://bugs.python.org/issue5728> ___ ___ Python-bug

[issue5758] fileinput.hook_compressed returning bytes from gz file

New submission from Michael Newman : The attached ZIP file contains "test.bat" which runs "test.py" with Python 2.6 and Python 3.0. Python 2.6 behaves as expected (see "py26.out"), since it returns strings from both "mike.txt" and "mike.txt.gz&quo

[issue5817] Right-click behavior from Windows Explorer

New submission from Michael Kopinsky : When I right-click on a .py file in Windows Explorer and click Edit with IDLE, it currently opens a completely new instance of IDLE (with two windows, one for shell and one for editing the file). It would be better if it just opened the file as an

[issue5822] inconsistent behavior of range when used in combination with remove

New submission from Michael Gilbert : using range in combination with remove is inconsistent. for example in python 2.x: >>> x = range(0,3) >>> x.remove(1) >>> x [0, 2] >>> x = range(0,3).remove(1) >>> x >>> and in python 3.x: >&

[issue5822] inconsistent behavior of range when used in combination with remove

Michael Gilbert added the comment: ok, i see now. the list itself is changed in place, and the return value of the remove() method is always None. since i din't assign the list to a variable in the first place, there is hence no way now to access that modified list. thanks for your

[issue5823] feature request: a conditional "for" statement

New submission from Michael Gilbert : hello, i've recently been working on some code where i am processing a list, but excluding certain items. the solution is to use a list comprehension in the for statement, which for example looks like: for m in [n for n in range( 0 , 5 ) if n

[issue5823] feature request: a conditional "for" statement

Michael Gilbert added the comment: hello, i've recently been working on some code where i am processing a list, but excluding certain items. the solution is to use a list comprehension in the for statement, which for example looks like: for m in [n for n in range( 0 , 5 ) if n

[issue5826] new unittest function listed as assertIsNotNot() instead of assertIsNotNone()

Michael Foord added the comment: Oops... sorry about that, will fix. -- ___ Python tracker <http://bugs.python.org/issue5826> ___ ___ Python-bugs-list mailin

[issue5826] new unittest function listed as assertIsNotNot() instead of assertIsNotNone()

Michael Foord added the comment: Closed in revision 71930. -- resolution: -> fixed status: open -> closed ___ Python tracker <http://bugs.python.org/

[issue3379] Option to not-exit on test

Michael Foord added the comment: Patch that adds the same exit functionality, but also stores the result as an instance attribute on the return TestProgram instance. As this functionality has been requested several times my intention is to apply this patch. -- Added file: http

[issue5679] cleanUp stack for unittest

Michael Foord added the comment: Damn - proper patch without extraneous stuff this time. -- Added file: http://bugs.python.org/file13786/unittest-no-exit.patch ___ Python tracker <http://bugs.python.org/issue5

[issue5679] cleanUp stack for unittest

Changes by Michael Foord : Removed file: http://bugs.python.org/file13786/unittest-no-exit.patch ___ Python tracker <http://bugs.python.org/issue5679> ___ ___ Python-bug

[issue5679] cleanUp stack for unittest

Michael Foord added the comment: Proper patch and proper issue this time! Not my evening. -- Added file: http://bugs.python.org/file13787/unittest-no-exit.patch ___ Python tracker <http://bugs.python.org/issue5

[issue3202] Wish: disable tests in unittest

Michael Foord added the comment: Is this made obsolete by test skipping? -- nosy: +michael.foord ___ Python tracker <http://bugs.python.org/issue3202> ___ ___

[issue5846] Deprecate obsolete functions in unittest

New submission from Michael Foord : _makeLoader, getTestCaseNames, makeSuite and findTestCases have all had the comment "these functions should be considered obsolete" for a long time. Is is ok to go straight to deprecation or should they be marked with PendingDeprecationWar

[issue1207] Load tests from path (patch included)

Michael Foord added the comment: I'm intending to implement loadTestsFromPackage which will do a *similar* job. As well as allowing test autodiscovery it will allow for customizing test loading from modules / packages using a protocol thrashed out on the Testing in Python mailing

[issue3379] Option to not-exit on test

Changes by Michael Foord : Removed file: http://bugs.python.org/file13784/unittest-no-exit.patch ___ Python tracker <http://bugs.python.org/issue3379> ___ ___ Python-bug

[issue3379] Option to not-exit on test

Michael Foord added the comment: Damn somehow managed to upload the patch to the wrong issue twice in a row. Must have been late at night. -- ___ Python tracker <http://bugs.python.org/issue3

[issue3379] Option to not-exit on test

Michael Foord added the comment: Correct patch this time. If there are no objections I'll apply this in a couple of days. -- Added file: http://bugs.python.org/file13790/unittest-no-exit.patch ___ Python tracker <http://bugs.python.org/i

[issue5679] cleanUp stack for unittest

Michael Foord added the comment: Updated patch with docs. My intention is to apply this in the next couple of days. I've settled on calling doCleanups *after* tearDown. The issues and reasoning explained below. One point of view concerns using addCleanups with existing tests. If the

[issue5848] Minor unittest doc patch

New submission from Michael Foord : Removes some blank lines from unittest.rst that were suppressing some version changed messages from appearing in output. Also added documentation for TestSuite.__iter__ and TextTestRunner._makeResult as they are unittest extensibility points. I see

[issue5337] Scanner class in re module undocumented

Michael Foord added the comment: Whether it was intended to be exposed or not it is known and used - and therefore we can't change the API without going through the usual deprecation process. As it is used and useful it should be docum

[issue3379] Option to not-exit on test

Michael Foord added the comment: Committed in revision 71291. -- status: open -> closed ___ Python tracker <http://bugs.python.org/issue3379> ___ ___ Python-

[issue3379] Option to not-exit on test

Michael Foord added the comment: No, make that revision 72191. :-) -- ___ Python tracker <http://bugs.python.org/issue3379> ___ ___ Python-bugs-list mailin

[issue5679] cleanUp stack for unittest

Michael Foord added the comment: Committed in revision 72219. -- status: open -> closed ___ Python tracker <http://bugs.python.org/issue5679> ___ ___ Python-

[issue5728] Support telling TestResult objects a test run has finished

Michael Foord added the comment: Committed in revision 72225. -- status: open -> closed ___ Python tracker <http://bugs.python.org/issue5728> ___ ___ Python-

[issue5846] Deprecate obsolete functions in unittest

Michael Foord added the comment: So it turns out that unittest.makeSuite is used about 100 times throughout the standard library tests. More than half the time it can be replaced with unittest.TestLoader().loadTestsFromTestCase(...) Some of the other times a loader needs to be constructed and

[issue5989] unittest.TestLoader.loadTestsFromNames should accept module / class name

New submission from Michael Foord : It would be really nice if unittest.TestLoader.loadTestsFromNames accepted module and class names. My main motivation for that is so that I can do: python -m unittest module_name There is no backwards compatibility issue as currently this doesn't

[issue5989] unittest.TestLoader.loadTestsFromNames should accept module / class name

Michael Foord added the comment: Actually they do - it is an obscure bug in the way the module is specified in TestProgram that prevents this from working. The code in parseArgs that is currently: if len(args) > 0: self.testNames = args Should probably

[issue5995] unittest command line behaviour

New submission from Michael Foord : This patch adds a verbosity keyword argument to unittest.main - so you can do: if __name__ == '__main__': unittest.main(verbosity=2) It also has a minor fix allowing you to specify test modules / classes from the command line. Th

[issue5995] unittest command line behaviour

Michael Foord added the comment: I didn't add the issue number because I created the patch prior to creating the issue. Will add when I commit. Would like permission to commit this from an interested core developer. -- ___ Python tracker

[issue5995] unittest command line behaviour

Michael Foord added the comment: Committed in revision 72570. -- status: open -> closed ___ Python tracker <http://bugs.python.org/issue5995> ___ ___ Python-

[issue6001] Test discovery for unittest

New submission from Michael Foord : Attached is a patch that implements test discovery for unittest. It includes command line argument handling (awkward manual handling but works fine...), so that it can be invoked through: python -m unittest discover python -m unittest discover

[issue5846] Deprecate obsolete functions in unittest

Michael Foord added the comment: Hehe - I wasn't actually doing that, just replacing the use of the obsolete functions. -- ___ Python tracker <http://bugs.python.org/i

[issue5995] unittest command line behaviour

Michael Foord added the comment: This commit caused a regression in command line behavior of modules using unittest.main(). Fixed in revision 72583. -- ___ Python tracker <http://bugs.python.org/issue5

[issue6001] Test discovery for unittest

Michael Foord added the comment: The usage information in TestProgram in this patch is not correct. If __name__ != __main__ it should be unchanged - the new usage message should only be displayed if unittest is run as __main__. -- ___ Python

[issue1207] Load tests from path (patch included)

Michael Foord added the comment: See issue 6001 for a patch implementing test discovery for unittest. It would allow you to do: python -m unittest discover -- ___ Python tracker <http://bugs.python.org/issue1

[issue706406] fix bug #685846: raw_input defers signals

Michael Stone added the comment: ajaksu2 has uploaded a file called "test.py" that seems to have nothing to do with this issue, unless I'm misunderstanding something. I don't see any call to readline in the uploaded file at all. Perhaps the file you meant to upload, wa

[issue706406] fix bug #685846: raw_input defers signals

Changes by Michael Stone : -- nosy: +ajaksu2 ___ Python tracker <http://bugs.python.org/issue706406> ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue4080] pyunit - display time of each test case - patch

Michael Foord added the comment: Needs test and documentation. Otherwise looks good. -- ___ Python tracker <http://bugs.python.org/issue4080> ___ ___ Python-bug

[issue6072] unittest.TestCase._result is very likely to collide (and break) with application-defined TestCase attributes

Michael Foord added the comment: Patch is fine. I'll apply shortly. There was a specific use case for being able to call doCleanups directly which was why the results object needed to be stored. -- ___ Python tracker <http://bugs.py

[issue6078] freeze.py doesn't work

New submission from Michael Zalokar : I've tried this with python 2.6.0, python 2.6.1 and python 2.6.2 all with the same results. bash-3.2$ cat hello.py print "hello world" bash-3.2$ python -V Python 2.6.2 bash-3.2$ python $PYTHON_DIR/Python-2.6.2/Tools/freeze/freeze.py h

[issue6072] unittest.TestCase._result is very likely to collide (and break) with application-defined TestCase attributes

Michael Foord added the comment: Committed in revision 72812. -- resolution: -> fixed status: open -> closed ___ Python tracker <http://bugs.python.org/

[issue6001] Test discovery for unittest

Michael Foord added the comment: Updated patch with documentation and fixed command line usage message. Unless there are objections I intend to check this in in the next few days. It would be helpful if someone else could go over the documentation and check for errors / typos etc. I&#x

[issue6001] Test discovery for unittest

Michael Foord added the comment: Georg Brandl has pointed out various minor issues in the docs (and discover docstring) that I am correcting. -- ___ Python tracker <http://bugs.python.org/issue6

[issue6001] Test discovery for unittest

Michael Foord added the comment: http://codereview.appspot.com/63157 -- ___ Python tracker <http://bugs.python.org/issue6001> ___ ___ Python-bugs-list mailin

<    19   20   21   22   23   24   25   26   27   28   >