Changes by Robert Collins :
--
type: -> enhancement
versions: +Python 3.6
___
Python tracker
<http://bugs.python.org/issue24629>
___
___
Python-bugs-list mai
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
Changes by Robert Collins :
--
resolution: -> duplicate
superseder: -> unittest.__init__:main shadows unittest.main
___
Python tracker
<http://bugs.python.org/i
Robert Collins added the comment:
See also https://github.com/testing-cabal/mock/issues/250
--
___
Python tracker
<http://bugs.python.org/issue22858>
___
___
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
Robert Collins added the comment:
This looks fine to me, I'm going to apply it.
--
___
Python tracker
<http://bugs.python.org/issue23661>
___
___
Pytho
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
Changes by Robert Collins :
--
keywords: +patch
Added file: http://bugs.python.org/file39924/issue24633.patch
___
Python tracker
<http://bugs.python.org/issue24
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
Changes by Robert Collins :
--
nosy: +rbcollins
versions: +Python 3.6
___
Python tracker
<http://bugs.python.org/issue18622>
___
___
Python-bugs-list mailin
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
Changes by Robert Collins :
--
assignee: michael.foord -> rbcollins
resolution: -> fixed
status: open -> closed
___
Python tracker
<http://bugs.python.or
Changes by Robert Collins :
--
assignee: -> rbcollins
versions: +Python 3.5, Python 3.6
___
Python tracker
<http://bugs.python.org/issue21750>
___
___
Python-
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
Changes by Robert Collins :
--
keywords: +patch
Added file: http://bugs.python.org/file39928/issue-21750.patch
___
Python tracker
<http://bugs.python.org/issue21
Changes by Robert Collins :
--
nosy: +rbcollins
versions: +Python 3.6
___
Python tracker
<http://bugs.python.org/issue23004>
___
___
Python-bugs-list mailin
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
Robert Collins added the comment:
There are already explicit tests for that, do you want another one?
--
___
Python tracker
<http://bugs.python.org/issue21
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
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
Changes by Robert Collins :
--
nosy: +berker.peksag, kushal.das, michael.foord
___
Python tracker
<http://bugs.python.org/issue24651>
___
___
Python-bugs-list m
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
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
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
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 -&
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
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
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'
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
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
Robert Collins added the comment:
Which part of the docs specifically?
--
___
Python tracker
<http://bugs.python.org/issue21750>
___
___
Python-bugs-list mailin
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
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:
Robert Collins added the comment:
I've applied this to 3.6.
--
nosy: +rbcollins
___
Python tracker
<http://bugs.python.org/issue13938>
___
___
Python-bugs-l
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
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
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 ? :)
--
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
Changes by Robert Collins :
--
resolution: -> fixed
stage: commit review -> resolved
status: open -> closed
___
Python tracker
<http://bugs.python.or
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
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
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
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
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
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
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
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
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.
Changes by Robert Collins :
--
resolution: -> fixed
stage: needs patch -> resolved
status: open -> closed
___
Python tracker
<http://bugs.python.or
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
Changes by Robert Collins :
--
resolution: -> fixed
stage: commit review -> resolved
status: open -> closed
___
Python tracker
<http://bugs.python.o
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
Changes by Robert Collins :
--
resolution: -> fixed
stage: patch review -> resolved
status: open -> closed
___
Python tracker
<http://bugs.python.or
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
Changes by Robert Collins :
--
priority: normal -> low
___
Python tracker
<http://bugs.python.org/issue24651>
___
___
Python-bugs-list mailing list
Unsubscrib
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
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
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
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.
--
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
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
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
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
Robert Collins added the comment:
I know it 'works', I just think its not appropriate here.
--
___
Python tracker
<http://bugs.python.org/issue24710>
___
___
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
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
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
Changes by Robert Collins :
--
resolution: -> fixed
stage: commit review -> resolved
status: open -> closed
___
Python tracker
<http://bugs.python.or
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
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
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
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
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
Changes by Robert Collins :
--
resolution: -> fixed
stage: commit review -> resolved
status: open -> closed
___
Python tracker
<http://bugs.python.or
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
Robert Collins added the comment:
ping @serhiy - there's a bug in the patch. Moving back to patch review.
--
nosy: +rbcollins
stage: commit review -> patch review
___
Python tracker
<http://bugs.python.org
Robert Collins added the comment:
@serhiy could you update the patch with the review feedback? Thanks. Moving
back to patch review. Lars hasn't commented on this in a year, so I think we
should go ahead once the patch is fixed: e.g. you should update the comments
and commit it dir
Changes by Robert Collins :
--
stage: commit review -> patch review
status: pending -> open
___
Python tracker
<http://bugs.python.org/issue22141>
___
___
Robert Collins added the comment:
reset.
--
nosy: +rbcollins
resolution: not a bug ->
stage: -> needs patch
status: closed -> languishing
___
Python tracker
<http://bugs.python.or
Robert Collins added the comment:
@ezio I think you should commit what you have so far. LGTM.
--
nosy: +rbcollins
___
Python tracker
<http://bugs.python.org/issue23
Robert Collins added the comment:
Yep: "The issue has no clear solution , e.g., no agreement on a technical
solution or if it is even a problem worth fixing."
Brett is saying he doesn't consider this a bug.
Steven says he doesn't have time to push it forward.
Oh, I
Robert Collins added the comment:
LGTM - lukasz, do you want to commit this, or would you like someone else to if
you're too busy? Looks like we should patch this in 3.4/3.5./3.6 at this point.
--
nosy: +rbcollins
versions: +Python 3.4, Pytho
Robert Collins added the comment:
So, I think this is worth applying. The discussion around :ipp etc is
irrelevant here: this patch changes large or negative ints to be a valueerror,
as non-ints are.
The only question is where. I think this is in the category of 'will only break
Robert Collins added the comment:
ok, 3.6 only.
--
versions: +Python 3.6 -Python 2.7, Python 3.4, Python 3.5
___
Python tracker
<http://bugs.python.org/issue20
Changes by Robert Collins :
--
stage: -> test needed
___
Python tracker
<http://bugs.python.org/issue24758>
___
___
Python-bugs-list mailing list
Unsubscrib
Robert Collins added the comment:
How were you setting/introducing your assertions on the mocks? e.g. could you
supply a small sample script showing what used to work? Thanks.
--
nosy: +rbcollins
___
Python tracker
<http://bugs.python.
Robert Collins added the comment:
Thanks for the patch @planet36, however I think this is sufficiently large a
change that we should also have a test case for it.
I'm also retargeting this to the current open branches for feature work - 3.6.
--
nosy: +rbcollins
stage: commit r
Robert Collins added the comment:
Bah, wrong stage. patch review.
--
stage: test needed -> patch review
___
Python tracker
<http://bugs.python.org/issu
Robert Collins added the comment:
Thanks for the patch. Applied to 3.4 through 3.6.
--
nosy: +rbcollins
resolution: -> fixed
stage: commit review -> resolved
status: open -> closed
___
Python tracker
<http://bugs.python.or
Robert Collins added the comment:
Yes, Python vendors pip, but is not maintaining it - it should be filed in
https://github.com/pypa/pip/issues.
--
nosy: +rbcollins
resolution: third party -> rejected
status: pending -> closed
___
Python t
Changes by Robert Collins :
--
versions: +Python 3.6
___
Python tracker
<http://bugs.python.org/issue22932>
___
___
Python-bugs-list mailing list
Unsubscribe:
Robert Collins added the comment:
Applied to 3.4 and up. Thanks for the patch!
--
nosy: +rbcollins
resolution: -> fixed
stage: commit review -> resolved
status: open -> closed
___
Python tracker
<http://bugs.python.or
Robert Collins added the comment:
Now at https://github.com/testing-cabal/mock/issues/189
--
nosy: +rbcollins
___
Python tracker
<http://bugs.python.org/issue17
Changes by Robert Collins :
--
nosy: +rbcollins
___
Python tracker
<http://bugs.python.org/issue22625>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Robert Collins :
--
stage: patch review -> commit review
___
Python tracker
<http://bugs.python.org/issue7>
___
___
Python-bugs-list mai
Robert Collins added the comment:
Looks committed a way back to me.
--
nosy: +rbcollins
resolution: -> fixed
stage: commit review -> resolved
status: open -> closed
___
Python tracker
<http://bugs.python.or
Robert Collins added the comment:
See also issue 6631
--
nosy: +rbcollins
___
Python tracker
<http://bugs.python.org/issue22852>
___
___
Python-bugs-list mailin
Robert Collins added the comment:
test_relativelocalfile is still in place in the urllib tests, so its affecting
urlopen to this point.
So I think the bug is fixed at least to the extent of the original report. I'm
going to close this.
--
nosy: +rbcollins
stage: commit r
Robert Collins added the comment:
I've updated the ref in the patch to this bug per Victor's comments, and
applied.
I'm not sure of protocol here. Do we close this ticket, or keep it open to
analyze the actual cause?
--
nosy: +rbcollins
___
Changes by Robert Collins :
--
stage: commit review -> needs patch
title: test_socket failure on AIX -> test_socket not running all tests on AIX
___
Python tracker
<http://bugs.python.org/i
301 - 400 of 542 matches
Mail list logo