[issue23273] traceback: formatting a traceback stats the filesystem

New submission from Robert Collins: Discovered in issue 17911, all the traceback calls that render a stack trace end up calling linecache.checkcache, which stats files on disk, making getting a traceback rather more expensive than folk may expect. For "oops, it crashed" situations

[issue17911] traceback: add a new thin class storing a traceback without storing local variables

Robert Collins added the comment: I've split out the stat question to http://bugs.python.org/issue23273 - we can optimise it slightly in this patch, but I think its scope creep here, and will be unclear, to dive after a full fix in this

[issue3566] httplib persistent connections violate MUST in RFC2616 sec 8.1.4.

Robert Collins added the comment: FWIW, I agree with the analysis here, its standard HTTP behaviour in the real world, and we should indeed handle it. -- nosy: +rbcollins ___ Python tracker <http://bugs.python.org/issue3

[issue17911] traceback: add a new thin class storing a traceback without storing local variables

Robert Collins added the comment: Stack and Frame looking good, next update will be next Monday, when I finish off my TracebackException class. -- Added file: http://bugs.python.org/file37782/issue17911-1.patch ___ Python tracker <h

[issue17911] traceback: add a new thin class storing a traceback without storing local variables

Robert Collins added the comment: Right, and a usable API. I believe that this will meet Guido's use case: tb = TracebackException(*sys.exc_info, lookup_lines=False) some time later if should_show_tb: lines = list(tb.format()) I'm not 100% sold on the public A

[issue17911] traceback: add a new thin class storing a traceback without storing local variables

Robert Collins added the comment: Thanks for the review - shall action it all as it seems all good improvements. Two key notes: the use of an exception triple is useful to ease backports of this: a primary goal for me is being able to use the locals stuff in unittest for existing production

[issue17911] traceback: add a new thin class storing a traceback without storing local variables

Robert Collins added the comment: The generator thing: the code was refactoring not so long ago to be generator based internally with lists as a UI shim. I don't think there is a major advantage either way. Less buffering on one hand. Less convenient in some cases on the other. Simpl

[issue17911] traceback: add a new thin class storing a traceback without storing local variables

Robert Collins added the comment: And for profit, review changes applied (minus the small number I disagreed with). I've clarified in the code why the exc_info tuple break out is still used (compat with the legacy API is the strongest argument). I haven't fleshed out the locals thin

[issue17911] traceback: add a new thin class storing a traceback without storing local variables

Robert Collins added the comment: actually, strike that, I'm happy with this pending a final +1 from another reviewer. Finishing the locals stuff is a separate patch, and will look like a single new parameter to StackSummary.extract, similarly on TracebackException.__init__ and then c

[issue17911] traceback: add a new thin class storing a traceback without storing local variables

Robert Collins added the comment: So its fairly simple IMO: it will be more code, not less, to support the non-triple API, *and* it can be added later, unless we're proposing not to support the triple API at all (which hasn't been proposed AFAICT). To me thats a fairly strong ar

[issue22936] traceback module has no way to show locals

Robert Collins added the comment: First cut implementation. I'm sure there is lots we can add, but this will make things nicer in and of itself. Thanks for the pointer to cgitb, I've skimmed it and its definitely much more comprehensive. I'm not entirely sure about the best way

[issue17911] traceback: add a new thin class storing a traceback without storing local variables

Robert Collins added the comment: Why do you consider it crippling? -- ___ Python tracker <http://bugs.python.org/issue17911> ___ ___ Python-bugs-list mailin

[issue2786] Names in traceback should have class names, if they're methods

Robert Collins added the comment: I wonder if you could add this to the new code in http://bugs.python.org/issue17911 which I'm hoping to commit this week. -- nosy: +rbcollins ___ Python tracker <http://bugs.python.org/i

[issue17911] traceback: add a new thin class storing a traceback without storing local variables

Robert Collins added the comment: This iteration provides two constructors for TracebackException, one for exception objects, one for exc_info tuples. So it should be easy to use. The __init__ takes the exc_info tuple because thats less code (much easier to destructure rather than restructure

[issue22936] traceback module has no way to show locals

Robert Collins added the comment: updated with the latest 17911 patch basis. -- Added file: http://bugs.python.org/file38008/issue-22936-2.patch ___ Python tracker <http://bugs.python.org/issue22

[issue17911] traceback: add a new thin class storing a traceback without storing local variables

Robert Collins added the comment: I can certainly do that; I was aiming to make it fair I guess, given Antoines strong feelings on this matter. As long as I'm not piggy-in-the-middle, I don't have a care in this regard :) -- ___ Pyth

[issue17911] traceback: add a new thin class storing a traceback without storing local variables

Robert Collins added the comment: Sorry xonatius I wasn't clear: AFAICT your patch is going to require changes to the traceback tests, and this issue is changing the implementation substantially: I was suggesting that you make sure your patch applies on top of this issue, not that you

[issue17911] traceback: add a new thin class storing a traceback without storing local variables

Robert Collins added the comment: Nick, Antoine - I'm now stuck between you. Options going forward: - I can JFDI realising you won't both be happy :) - you two can reach consensus! I could cripple __init__ by switching to __new__, but I think thats massive overcomplication and

[issue17911] traceback: add a new thin class storing a traceback without storing local variables

Robert Collins added the comment: I'm idealogically opposed to polymorphic interpretation of args :) Antoine, will you be ok with one __init__ and one classmethod? -- ___ Python tracker <http://bugs.python.org/is

[issue17911] traceback: add a new thin class storing a traceback without storing local variables

Robert Collins added the comment: @Mahmoud thanks! I had a quick look and the structural approach we've taken is a bit different. What do you think of the current patch here (issue17911-4.patch) ? -- ___ Python tracker <http://bugs.py

[issue4753] Faster opcode dispatch on gcc

Robert Collins added the comment: FWIW I'm interested and willing to poke at this if more testers/reviewers are needed. -- nosy: +rbcollins ___ Python tracker <http://bugs.python.org/i

[issue24412] setUpClass equivalent for addCleanup

Robert Collins added the comment: It would be nice for symmetry. I mean, setUpClass isn't needed either, and we have it ;). however, we actually have two contexts this would be called from - setUpClass and setUpModule; both share their internals. So we probably need a decoupled cle

[issue24263] unittest cannot load module whose name starts with Unicode

Robert Collins added the comment: Are the module names valid in import statements? it would help if you could perhaps attach a little tar/zip file with an example failure. -- ___ Python tracker <http://bugs.python.org/issue24

[issue24134] assertRaises can behave differently

Robert Collins added the comment: Hi, catching up (see my mail to -dev about not getting tracker mail). Deprecations++. Being nice for folk whom consume unittest2 which I backport to everything is important to me :). -- ___ Python tracker <h

[issue24249] unittest API for detecting test failure in cleanup/teardown

Robert Collins added the comment: Setting some basic design parameters here. Its ok for a test to know if it itself has decided on some status. See e.g. testtools.expectThat for a related design thing. Making some official API within the test itself so code after the failure can take

[issue24629] unittest.main shadows unittest.main module

Changes by Robert Collins : -- type: -> enhancement versions: +Python 3.6 ___ Python tracker <http://bugs.python.org/issue24629> ___ ___ Python-bugs-list mai

[issue24629] unittest.main shadows unittest.main module

New submission from Robert Collins: this is a bad practice - it interferes with test discovery and with the use of mock (see https://github.com/testing-cabal/mock/issues/250). We could move main.py to mainmod.py or something -- messages: 246704 nosy: rbcollins priority: normal

[issue24629] unittest.main shadows unittest.main module

Changes by Robert Collins : -- resolution: -> duplicate superseder: -> unittest.__init__:main shadows unittest.main ___ Python tracker <http://bugs.python.org/i

[issue22858] unittest.__init__:main shadows unittest.main

Robert Collins added the comment: See also https://github.com/testing-cabal/mock/issues/250 -- ___ Python tracker <http://bugs.python.org/issue22858> ___ ___

[issue23661] Setting a exception side_effect on a mock from create_autospec does not work

Robert Collins added the comment: Also reported in the mock project as https://github.com/testing-cabal/mock/issues/264 -- nosy: +rbcollins ___ Python tracker <http://bugs.python.org/issue23

[issue23661] Setting a exception side_effect on a mock from create_autospec does not work

Robert Collins added the comment: This looks fine to me, I'm going to apply it. -- ___ Python tracker <http://bugs.python.org/issue23661> ___ ___ Pytho

[issue24633] Not a directory: '//anaconda/lib/python2.7/site-packages/readme/__about__.py'

Robert Collins added the comment: So, README is a valid package name. readme conflicting with README on case insensitive filesystems is a special case, but the general problem remains. We've no particular reason to use README rather than e.g. README.txt, which would open with a much

[issue24633] Not a directory: '//anaconda/lib/python2.7/site-packages/readme/__about__.py'

Changes by Robert Collins : -- keywords: +patch Added file: http://bugs.python.org/file39924/issue24633.patch ___ Python tracker <http://bugs.python.org/issue24

[issue21750] mock_open data is visible only once for the life of the class

Robert Collins added the comment: This is a regression in 3.5 vs 3.3 I think. It would have worked with the initial mock import. https://github.com/testing-cabal/mock/issues/280 Minimal reproducer case attached (With commentted out bits to switch out the mock for the rolling backport etc

[issue18622] reset_mock on mock created by mock_open causes infinite recursion

Changes by Robert Collins : -- nosy: +rbcollins versions: +Python 3.6 ___ Python tracker <http://bugs.python.org/issue18622> ___ ___ Python-bugs-list mailin

[issue18622] reset_mock on mock created by mock_open causes infinite recursion

Robert Collins added the comment: Applying this to 3.4 and up with a test. Laurent, it would be good to sign the CLA - since your change here is minimal and Nicola has, I'm just going ahead. -- ___ Python tracker <http://bugs.python.org/is

[issue18622] reset_mock on mock created by mock_open causes infinite recursion

Changes by Robert Collins : -- assignee: michael.foord -> rbcollins resolution: -> fixed status: open -> closed ___ Python tracker <http://bugs.python.or

[issue21750] mock_open data is visible only once for the life of the class

Changes by Robert Collins : -- assignee: -> rbcollins versions: +Python 3.5, Python 3.6 ___ Python tracker <http://bugs.python.org/issue21750> ___ ___ Python-

[issue21750] mock_open data is visible only once for the life of the class

Robert Collins added the comment: I think its worth noting that both the original mock_open and the new one are entirely broken for mocking access to multiple files. But, the breakage was not deliberate, and as the mock-280 example shows, folk subclassing a test suite will be surprisingly

[issue21750] mock_open data is visible only once for the life of the class

Changes by Robert Collins : -- keywords: +patch Added file: http://bugs.python.org/file39928/issue-21750.patch ___ Python tracker <http://bugs.python.org/issue21

[issue23004] mock_open() should allow reading binary data

Changes by Robert Collins : -- nosy: +rbcollins versions: +Python 3.6 ___ Python tracker <http://bugs.python.org/issue23004> ___ ___ Python-bugs-list mailin

[issue22858] unittest.__init__:main shadows unittest.main

Robert Collins added the comment: So unittest.main, the symbol, needs to exist. What currently references unittest.main, the module, today? AFAICT its only accessible vis sys.modules['unittest.main'] because of the shadowing. -- ___ Pyth

[issue21750] mock_open data is visible only once for the life of the class

Robert Collins added the comment: There are already explicit tests for that, do you want another one? -- ___ Python tracker <http://bugs.python.org/issue21

[issue21750] mock_open data is visible only once for the life of the class

Robert Collins added the comment: Ok, so - good to commit to 3.4 and up? -- ___ Python tracker <http://bugs.python.org/issue21750> ___ ___ Python-bugs-list mailin

[issue24651] Mock.assert* API is in user namespace

New submission from Robert Collins: We had a discussion on the list sparked by the assret checking, and in it I proposed that the API would be cleaner if the asserts were module functions. e.g. rather than:: a_mock.assert_called_with(Foo) assert_called_with(a_mock, Foo) Michael has

[issue24651] Mock.assert* API is in user namespace

Changes by Robert Collins : -- nosy: +berker.peksag, kushal.das, michael.foord ___ Python tracker <http://bugs.python.org/issue24651> ___ ___ Python-bugs-list m

[issue24653] Mock.assert_has_calls([]) incorrectly passes

New submission from Robert Collins: >From https://github.com/testing-cabal/mock/issues/243 from unittest import mock mmock = mock.MagicMock() mmock.foobar("baz") mmock.assert_has_calls([]) # No exception raised. Why?mmock.assert_has_calls(['x']) # Excep

[issue24653] Mock.assert_has_calls([]) incorrectly passes

Robert Collins added the comment: This might go back further, haven't checked 3.3, but IIRC we're only doing fixes on 3.4 up anyhow. -- nosy: +berker.peksag, kushal.das, michael.foord versions: +Python 3.4, Python 3.5, Python 3.6 ___ Pyth

[issue21750] mock_open data is visible only once for the life of the class

Robert Collins added the comment: The fix for this uncovered more testing / scenarios that folk use mock_open for that were not accounted for. I'm reverting it from mock, and am going to roll-forward for Python: I should have a fix in a day or two and we can fix it more completely

[issue24653] Mock.assert_has_calls([]) is surprising for users

Robert Collins added the comment: Ok, so as a doc bug this should still be tracked here - I'm going to reopen it to reflect that, hope thats ok. -- assignee: -> docs@python components: +Documentation nosy: +docs@python resolution: not a bug -> status: closed -&

[issue21750] mock_open data is visible only once for the life of the class

Robert Collins added the comment: Fixup patch. I've tested this with the reported failures and they all work. -- Added file: http://bugs.python.org/file39967/issue-21750-2.patch ___ Python tracker <http://bugs.python.org/is

[issue21750] mock_open data is visible only once for the life of the class

Robert Collins added the comment: But - its worth discussing. Perhaps we should roll this all back, and just say 'use a vfs layer for tests like this'. The problem in doing that, is that the @patch def test_foo... use case is actually pretty common IME, and this conflicts with t

[issue21750] mock_open data is visible only once for the life of the class

Robert Collins added the comment: @pkoning in Python3.3 == mock 1.0.1, >>> m = mock_open(read_data='f') >>> m().read() 'f' >>> m().read() 'f' >>> x = m() >>> x.read() 'f' >>> x.read() 'f'

[issue21750] mock_open data is visible only once for the life of the class

Robert Collins added the comment: So the 1.1.4 behaviour matches that of a VFS most closely. But, see the earlier messages, it does do only and precisely because it breaks regular mock idioms. Thus I think we're better off with the new patch, which addresses the issue with reuse of the

[issue6087] distutils.sysconfig.get_python_lib gives surprising result when used with a Python build

Robert Collins added the comment: Moving this back to patch review since I'm 90% sure that the patch won't apply anymore (if I had a little more time I'd pull it down and double check) - but I've hit this myself and would totally commit it if updated. -- nosy: +rbc

[issue21750] mock_open data is visible only once for the life of the class

Robert Collins added the comment: Which part of the docs specifically? -- ___ Python tracker <http://bugs.python.org/issue21750> ___ ___ Python-bugs-list mailin

[issue8585] zipimporter.find_module is untested

Robert Collins added the comment: Applied to 3.6 only. -- nosy: +rbcollins resolution: -> fixed stage: commit review -> resolved status: open -> closed versions: +Python 3.6 -Python 3.5 ___ Python tracker <http://bugs.python.o

[issue2091] file accepts 'rU+' as a mode

Robert Collins added the comment: Updated patch. I'm not going to apply right now - giving it a little time to let folk chime on whether this should be applied all the way back to 3.4, or not. My inclination is to only apply it to 3.6. -- nosy: +rbcollins Added file:

[issue13938] 2to3 fails to convert types.StringTypes appropriately

Robert Collins added the comment: I've applied this to 3.6. -- nosy: +rbcollins ___ Python tracker <http://bugs.python.org/issue13938> ___ ___ Python-bugs-l

[issue13938] 2to3 fails to convert types.StringTypes appropriately

Robert Collins added the comment: Not clear to me either: I figured that after three years the relevance to 2.7 was pretty low, but I can transplant it if you think thats relevant. -- ___ Python tracker <http://bugs.python.org/issue13

[issue22153] Documentation of TestCase.runTest is incorrect and confusing

Robert Collins added the comment: Thanks for the update, it looks good to me. Applied to 3.4 and up. I'm not applying to 2.7 at this stage. -- ___ Python tracker <http://bugs.python.org/is

[issue13938] 2to3 fails to convert types.StringTypes appropriately

Robert Collins added the comment: So, I don't think I've ever done 2.x stuff with hg here, I'll leave this open till I've looked up the docs and applied it safely. ... unless you'd like to do the 2.7 application ? :) --

[issue22153] Documentation of TestCase.runTest is incorrect and confusing

Changes by Robert Collins : -- resolution: -> fixed stage: commit review -> resolved status: open -> closed versions: +Python 3.6 -Python 2.7 ___ Python tracker <http://bugs.python.or

[issue13938] 2to3 fails to convert types.StringTypes appropriately

Changes by Robert Collins : -- resolution: -> fixed stage: commit review -> resolved status: open -> closed ___ Python tracker <http://bugs.python.or

[issue9232] Allow trailing comma in any function argument list.

Robert Collins added the comment: FWIW I would like to see this, but I think it does need a PEP given the contention so far. For that, we need a BDFL delegate AIUI. -- nosy: +rbcollins versions: +Python 3.6 -Python 3.5 ___ Python tracker <h

[issue21750] mock_open data is visible only once for the life of the class

Robert Collins added the comment: @Paul So the problem is that its never been a high fidelity thing in that sense In that: 3.3 -> read() is a constant for the thing opened from the mock 3.4 -> read() works once and only once across all opened files from the mock 3.5 today -> rea

[issue24694] callables registered in TestCase.addCleanup should be run before tearDown

Robert Collins added the comment: The ordering is deliberate to support folk migrating from tearDown to cleanups - its not a bug. I thought we documented it clearly - https://docs.python.org/dev/library/unittest.html#unittest.TestCase.doCleanups - but if you wanted to submit improvements to

[issue24694] callables registered in TestCase.addCleanup should be run before tearDown

Robert Collins added the comment: Argh, and my memory had things inverted. Anyhow - the inheritance story was the big thing, and -1 on changing. -- ___ Python tracker <http://bugs.python.org/issue24

[issue24694] callables registered in TestCase.addCleanup should be run before tearDown

Robert Collins added the comment: So yeah - setup + cleanup is LIFO. setup + teardown *can* be LIFO [depends on where you upcall] setup + teardown + cleanup CANNOT be LIFO in all cases: we have to pick one, and either local-first or local-last. So it is ultimately somewhat arbitrary and

[issue21750] mock_open data is visible only once for the life of the class

Robert Collins added the comment: Discussed with Michael Foord; we're going to go with the -2 patch - the new behaviour. -- ___ Python tracker <http://bugs.python.org/is

[issue2091] file accepts 'rU+' as a mode

Robert Collins added the comment: @Larry - should this go in 3.5, or would you rather it not? -- nosy: +larry ___ Python tracker <http://bugs.python.org/issue2

[issue24695] Don't print traceback header if traceback is None in TracebackException

Robert Collins added the comment: Huh,indeed. So clearly we should have a test for that behaviour (and fix it). We're very close to the 3.5 release date, but this is a regression - care to whip up a patch? -- ___ Python tracker

[issue24699] TemporaryDirectory is cleaned up twice

Robert Collins added the comment: I think you may need to instrument TemporaryDirectory._cleanup to be sure, but it sounds like its being run twice. now, you're not using it like a context manager (at least as far as your code shows), so it must be happening from the weakref.

[issue21750] mock_open data is visible only once for the life of the class

Changes by Robert Collins : -- resolution: -> fixed stage: needs patch -> resolved status: open -> closed ___ Python tracker <http://bugs.python.or

[issue2091] file accepts 'rU+' as a mode

Robert Collins added the comment: @larry thanks - that was my inclination too. Applied to 3.6 @Serhiy I've not done a warning in 3.4/3.5 because - the behaviour is already broken, this patch just catches it a lot earlier (on open rather than subsequent opera

[issue2091] file accepts 'rU+' as a mode

Changes by Robert Collins : -- resolution: -> fixed stage: commit review -> resolved status: open -> closed ___ Python tracker <http://bugs.python.o

[issue24710] Class name hardcoded in TracebackException.from_exception()

Robert Collins added the comment: We can't use from_exception in __init__ because from_exception's job is to look up __traceback__, but the legacy API allows arbitrary tb objects which may not be exc.__traceback__, and modifying exc.__traceback__ or creating a shim object just to

[issue24710] Class name hardcoded in TracebackException.from_exception()

Changes by Robert Collins : -- resolution: -> fixed stage: patch review -> resolved status: open -> closed ___ Python tracker <http://bugs.python.or

[issue24651] Mock.assert* API is in user namespace

Robert Collins added the comment: Some great points raised here. Yes, we'd need .calls and .returnvalue and so on all made accessible via another route, and that would be a less direct spelling. e.g. a_mock.returnvalue = 3 -> # function set_returnvalue(a_mock, 3) or # separate objec

[issue24651] Mock.assert* API is in user namespace

Changes by Robert Collins : -- priority: normal -> low ___ Python tracker <http://bugs.python.org/issue24651> ___ ___ Python-bugs-list mailing list Unsubscrib

[issue12750] datetime.strftime('%s') should respect tzinfo

Robert Collins added the comment: Moving this back to patch needed: the patch was reviewed by a committer and changes requested. -- nosy: +rbcollins stage: commit review -> patch review ___ Python tracker <http://bugs.python.org/issu

[issue15989] Possible integer overflow of PyLong_AsLong() results

Robert Collins added the comment: @serhiy - I'm a little confused about the state of this patch. It seems like you need more review? -- nosy: +rbcollins ___ Python tracker <http://bugs.python.org/is

[issue10388] spwd returning different value depending on privileges

Robert Collins added the comment: Too late for 3.5 for this IMO. -- nosy: +rbcollins versions: +Python 3.6 -Python 3.5 ___ Python tracker <http://bugs.python.org/issue10

[issue18787] Misleading error from getspnam function of spwd module

Robert Collins added the comment: Sounds like we want something analogous to http://bugs.python.org/file33404/fix_error_message_getspall_v2.patch for this bug. Moving to patch needed. It looks like it would be easily tested too, so I'd like to see a test too please. --

[issue10388] spwd returning different value depending on privileges

Robert Collins added the comment: The man page for setspent says this: "The functions that return a pointer return NULL if no more entries are available or if an error occurs during processing. The functions which have int as the return value return 0 for success and -1 for fa

[issue10388] spwd returning different value depending on privileges

Robert Collins added the comment: I'm moving this back to patch review - it needs a test, particularly because of the question I have around setspent. -- stage: commit review -> patch review ___ Python tracker <http://bugs.python.org

[issue20544] Use specific asserts in operator tests

Robert Collins added the comment: Looks sane to me. Should go in 3.6 if we're going to do this or get closed to remove cognitive overhead in the issue tracker. No point backporting this to older releases. -- nosy: +rbcollins versions: +Python 3.6 -Python 2.7, Python 3.4, Pytho

[issue24710] Class name hardcoded in TracebackException.from_exception()

Robert Collins added the comment: Oh I see, - different things could have been meant but that application will work. But - please don't use self.from_exception: its a class method, so TracebackException.from_exception(...) is the right spe

[issue24710] Class name hardcoded in TracebackException.from_exception()

Robert Collins added the comment: I know it 'works', I just think its not appropriate here. -- ___ Python tracker <http://bugs.python.org/issue24710> ___ ___

[issue20544] Use specific asserts in operator tests

Robert Collins added the comment: So, is this specific patch ok to apply, or are we going to reject it? I don't particularly care either way, but having this issue open and stalled just adds cognitive load to working with the bug tracker. FWIW I agree that it should not be backp

[issue17527] PATCH as valid request method in wsgiref.validator

Robert Collins added the comment: Applied to 2.7/3.4/3.5(for .1)/3.6 -- nosy: +rbcollins resolution: -> fixed stage: commit review -> resolved status: open -> closed versions: +Python 3.6 ___ Python tracker <http://bugs.python.or

[issue23426] run_setup is broken in distutils

Robert Collins added the comment: The change in exec doesn't make sense to me (but see lower :)) __file__ should be in globals, not locals, right? Also if it is right, then exec(foo, g) should be equivalent :) The reset of the patch looks ok. But I can see your patch shows this bre

[issue23426] run_setup is broken in distutils

Changes by Robert Collins : -- resolution: -> fixed stage: commit review -> resolved status: open -> closed ___ Python tracker <http://bugs.python.or

[issue24740] make patchcheck doesn't detect changes if commit is done first

New submission from Robert Collins: ./python ./Tools/scripts/patchcheck.py Getting the list of files that have been added/changed ... 0 files Fixing whitespace ... 0 files Fixing C file whitespace ... 0 files Fixing docs whitespace ... 0 files Docs modified ... NO Misc/ACKS updated ... NO Misc

[issue22141] rlcompleter.Completer matches too much

Robert Collins added the comment: I'm struggling to understand this bug. I've tried idle and plain cPython and neither exhibit it. I suspect thats due to how readline is itself tokenizing things. Python 3.6.0a0 (default:ef5a2ba9df62, Jul 28 2015, 15:48:19) [GCC 4.9.1] on linux

[issue24651] Mock.assert* API is in user namespace

Robert Collins added the comment: I don't mind if this is open or closed: we've now got a clear set of requirements *should* someone want to work on it:: - it would feel as convenient to use as the current API does - it would be possible to be both forward and backwards compatibl

[issue23254] Document how to close the TCPServer listening socket

Robert Collins added the comment: Applied to 2.7/3.4/3.5/3.6. Thanks! -- nosy: +rbcollins resolution: -> fixed stage: commit review -> resolved status: open -> closed ___ Python tracker <http://bugs.python.or

[issue23589] Redundant sentence in FAQ

Robert Collins added the comment: @Demian, I agree that there are more improvements we can make. The current patch addresses the specific issue of this bug, and if you wished to make a new issue with further improvements that would be great. I'm going to apply this patch now t

[issue23589] Redundant sentence in FAQ

Changes by Robert Collins : -- resolution: -> fixed stage: commit review -> resolved status: open -> closed ___ Python tracker <http://bugs.python.or

[issue20557] Use specific asserts in io tests

Robert Collins added the comment: @serhiy I think you should apply this: you're a committer, and no committers have objected in over a year. -- nosy: +rbcollins ___ Python tracker <http://bugs.python.org/is

<    1   2   3   4   5   6   >