New submission from
Robert Collins
:
Python 2.5.1 (r251:54863, May 2 2007, 16:56:35)
[GCC 4.1.2 (Ubuntu 4.1.2-0ubuntu4)] on linux2
Type "help", "copyright", "credits" or "license"
Robert Collins added the comment:
> The error message is wrong: it's a TypeError, but the message should say
> something like...
>
> TypeError: slice indices must be integers or have an __index__ method
This would be a false message, as, as my report demonstrated, slice
indi
New submission from Robert Collins :
This affects the python implementation of RLock only.
If a signal occurs during RLock.acquire() or release() and then operates on the
same lock to acquire() or release() it, process hangs or assertions can be
triggered.
The attached test script
Robert Collins added the comment:
I'm not sure it is sensibly implementable in pure python: the semantics of
signal handling (AIUI) are that the vm is interrupted, sets a flag to say 'when
the GIL is released or the next bytecode interpretation happens, please process
signal X&#x
Robert Collins added the comment:
Normally I advocate very strongly for Python implementation of C accelerated
modules, but when the two implementations are not equivalent, having a simpler
Python one around does not help anyone (not users, other language implementors
etc). True reentrancy
New submission from Robert Collins :
RUSAGE_THREAD (since Linux 2.6.26)
Return resource usage statistics for the calling thread.
This is very handy for multi threaded apps in determining runtime in a thread,
page faults from the thread etc.
--
messages: 121336
nosy
Changes by Robert Collins :
--
keywords: +patch
Added file: http://bugs.python.org/file19624/rusage-thread.patch
___
Python tracker
<http://bugs.python.org/issue10
Robert Collins added the comment:
Its a common convention in zope.testing, trial, testtools, bzr, ...
--
___
Python tracker
<http://bugs.python.org/issue7
Robert Collins added the comment:
I'm reopening this because I don't agree.
I opened the bug because we have evidence that users find the current
documentation confusing. Saying that its not confusing to us doesn't fix the
confusion.
Why should we mention the special case
Robert Collins added the comment:
New changeset b892d3ea468101d35e2fb081002fa693bd86eca9 by Robert Collins
(Jeroen Demeyer) in branch 'master':
bpo-36994: add test for profiling method_descriptor with **kwargs (GH-13461)
https://github.com/python/cpyt
Robert Collins added the comment:
New changeset b892d3ea468101d35e2fb081002fa693bd86eca9 by Robert Collins
(Jeroen Demeyer) in branch 'master':
bpo-36994: add test for profiling method_descriptor with **kwargs (GH-13461)
https://github.com/python/cpyt
Robert Collins added the comment:
I'd like to add a few notes; please do consider Windows interactions here -
Windows does not have the same model for inode replacement that Posix has.
Secondly, I note that the thread model discussed here hasn't been particular
well artic
Robert Collins added the comment:
Thank you @Eryk
--
___
Python tracker
<https://bugs.python.org/issue36656>
___
___
Python-bugs-list mailing list
Unsubscribe:
Robert Collins added the comment:
Sorry for the slow reply here;
There are API breaks involved in any decoupling that involves the exception
raising because of the failureException attribute. Something with signalling
that can be adapted by other test suites etc might have merit, but I
Robert Collins added the comment:
I think this is strictly redundant with that other ticket and I'm going to
close it. That said, they need access to self.failureException.
https://docs.python.org/3/library/unittest.html#unittest.TestCase.failureException
--
stage: ->
Robert Collins added the comment:
Right now that attribute could be set by each test separately, or even varied
within a test.
TBH I'm not sure that the attribute really should be supported; perhaps
thinking about breaking the API is worth doing.
But - what are we solving for here. T
Robert Collins added the comment:
Ok so design wise - there is state on the TestCase that influences assertions;
in potentially two ways.
The first way is formatting - the amount of detail shown in long list
comparisons etc.
The second way I don't think we have at the moment
Change by Robert Collins :
--
versions: +Python 3.9 -Python 3.5
___
Python tracker
<https://bugs.python.org/issue19645>
___
___
Python-bugs-list mailin
Robert Collins added the comment:
Oh, I didn't mean to imply that these are the only options I'd support - just
that these are the things I've thought through and that I think will all work
well... I'm sure there are mo
Robert Collins added the comment:
We've now spent more time debating the deprecation that we would have saved if
it had been deprecated.
Deprecations cost user good will. Whilst I very much want to delete all
assertions in favour of matchers, which would allow composed symmetry rather
Robert Collins added the comment:
This is now showing up in end user tools like black:
https://github.com/ambv/black/issues/564
--
nosy: +rbcollins
versions: +Python 3.7, Python 3.8, Python 3.9
___
Python tracker
<https://bugs.python.
Robert Collins added the comment:
Re: backporting this. I think backporting to 3.6/3.7 makes a lot of sense -
bugfix and prerelease respectively.
For 2.7, this bug has been around for ages, the patch is small, and I have no
objection - but the RM has already said no, so I guess not happening
Robert Collins added the comment:
Oh, and why look for __init__ - in part, because it predates namespace
packages, but also because unlike regular imports unittest will do negative
things like reading the entire filesystem otherwise.
--
___
Python
Robert Collins added the comment:
Whats the use for *unittest* - a tool to help folk develop - to run a test
which is only present in sourceless form?
--
___
Python tracker
<https://bugs.python.org/issue32
Robert Collins added the comment:
So, I think we're in a local minima here.
As I said earlier, neither the old nor new names really grab me, and I think
everyone has aknowledged that the new name is -at best- confusing. We don't
need *any more discussion* about that. The question
Robert Collins added the comment:
Serhiy, thats not a design flaw, its a feature.
in a class hierarchy, setup and teardown ordering is undefined: implementors
can choose whatever order they want to execute in. e.g.
class A(TestCase):
def setUp(self):
super().setUp()
acquire1()
class B
Robert Collins added the comment:
Hey, feel free to +nosy me on unittest things :). Julian pinged me on IRC about
this - Jml and I would be delight to prepare a patchset for assertThat for
unittest and as much of the core of Matchers as makes sense. The bare core can
come in without any of
Robert Collins added the comment:
This is a duplicate of 16662
--
nosy: +rbcollins
___
Python tracker
<http://bugs.python.org/issue18198>
___
___
Python-bug
Robert Collins added the comment:
Well, spoke with vila on IRC. I content it's a duplicate because if load_tests
in __init__ kicks in and supercedes discovery, I believe this bug would not be
needed.
--
___
Python tracker
<http://bugs.py
New submission from Robert Collins:
In bug https://bugs.launchpad.net/subunit/+bug/586176 I recorded a user request
- that if no tests are found, tools consuming subunit streams should be able to
consider that an error.
There is an analogous situation though, which is that if discover returns
Changes by Robert Collins :
--
nosy: +rbcollins
___
Python tracker
<http://bugs.python.org/issue18526>
___
___
Python-bugs-list mailing list
Unsubscribe:
Robert Collins added the comment:
I'll do a full review shortly, but at the conceptual level, I don't see any
benefit in making a new SkipTest base class, other than instantly breaking
other runners when an unknown exception is raised. SkipTest is part of the API.
Making a new exce
New submission from Robert Collins:
In 2.6 deepcopy(ConfigParser) worked, in 2.7 it doesn't due to the _optcre
variable which is a compiled regex pattern.
--
components: Library (Lib)
messages: 171364
nosy: rbcollins
priority: normal
severity: normal
status: open
title: ConfigPars
New submission from Robert Collins:
TextTestRunner calls str(TestCase) directly, which makes it hard for
testscenarios to rename the test cases as it parameterises them (because
__str__ is a descriptor). While testscenarios could use a decorator instead,
thats undesirable as the test case
Robert Collins added the comment:
Or anther way this could be done would be to make TestCase.__str__ call
self.id(), and then __str__ never needs to be adjusted - id() or
shortDescription are the only things to tweak.
--
___
Python tracker
<h
Robert Collins added the comment:
They aren't descriptors? They certainly aren't normal methods:
>>> class foo(object):
... def __str__(self): return "foo"
...
>>> f = foo()
>>> f.__str__ = lambda: "bar"
>>> str(f)
Robert Collins added the comment:
testscenarios copies the tests, it doesn't call the constructor for the class;
this makes things a lot simpler than trying to reconstruct whatever state the
object may have from scratch again.
As for str(test) and test.id() being different - well sure
Robert Collins added the comment:
@Michael I'll put a patch together next week then.
@R.david.murray no idea - but I've refreshed the page, we'll if it behaves
better. My guess would be a buggy in-flight-collision detection in the issu
New submission from Robert Collins:
In loader.py:
if fnmatch(path, pattern):
# only check load_tests if the package directory itself
matches the filter
name = self._get_name_from_path(full_path)
package = self
Robert Collins added the comment:
BTW I'm very happy with testscenarios (on pypi) for this, modulo one small
issue which is the use of __str__ by the stdlib [which isn't easily overridable
- there is a separate issue on that]. I'd be delighted to have testscenarios be
in the s
Robert Collins added the comment:
I have a package with tests in it. If the tests match test*.py, they are
loaded, and load_tests within each one called. But load_tests on the package
isn't called.
If I change the pattern supplied by the user to match the package, then the
tests w
New submission from Robert Collins:
Openstack recently switched from nose to using discover. discover walks the
filesystem using os.listdir(), and that is just a thin layer over readdir. On
ext3/ext4 filesystems, readdir is in an arbitrary order dependent on file
insertion into the directory
New submission from Robert Collins:
https://bugs.launchpad.net/testtools/+bug/1245672 was filed on testtools
recently. It would be easier to fix that if there was some way that something
loading a test suite could check to see if there were import errors. The
current code nicely works in the
Robert Collins added the comment:
I think we rather need a test that using a load_tests hook to recursively load
and transform a subdir works. Hacking on that now.
--
___
Python tracker
<http://bugs.python.org/issue16
Robert Collins added the comment:
Ok, implementation I'm happy with is up in
https://bitbucket.org/rbtcollins/cpython/commits/bbf2eb26dda8f3538893bf3dc33154089f37f99d
--
hgrepos: +269
Added file: http://bugs.python.org/file36482/16662_passing_tests
Robert Collins added the comment:
The doc part of the patch was assuming this would be in 3.4 which it wasn't.
Updated to 3.5. Also found a corner case - when packages were imported the
_get_module_from_name method was not guarded for un-importable modules. This is
strictly a separate
Robert Collins added the comment:
Thanks for landing this barry, there's a couple quirks with your improvements -
loadTestsFromModule(mod, foo, bar) will raise a TypeError but not warn about
foo the way loadTestsFromModule(mod, foo) will.
Secondly, the TypeError has an off-by-one error i
Robert Collins added the comment:
OH! One more thing I just spotted, which is that this change causes
non-'discover' unittest test loading to invoke load_tests.
IMO this is the Right Thing - its what I intended when I described the protocol
a few years back, but we should docum
Robert Collins added the comment:
Its more than just a docs issue - "AFAICT it isn't possible to tell if closefd
is set after the object is created."
The presence of the parameter in the signature is there, but it isn't
documented *where the bulk of the FileIO parameters a
Robert Collins added the comment:
Oh - the the 'open' function docs are fine - they are just a pointer. I was
specifically referring to the class docs around line 513 of Doc/library/io.rst.
Attached is a patch that changes repr to show this attribute and extends the
docs to docume
Robert Collins added the comment:
@michael - ah I think I inverted the sense of the old parameter. It was
defaulting True. So - no need to document anything extra:)
--
___
Python tracker
<http://bugs.python.org/issue16
Robert Collins added the comment:
Here is an implementation. I'm probably missing some finesse in the docs.
--
keywords: +patch
Added file: http://bugs.python.org/file36577/issue19746.patch
___
Python tracker
<http://bugs.python.org/is
Robert Collins added the comment:
I've just put a patch up for the related issue http://bugs.python.org/issue19746
I'll poke at this one briefly now, since I'm across the related code.
--
___
Python tracker
<http://bugs.py
Robert Collins added the comment:
Ok, here is an implementation that I believe covers everything Michael wanted.
I examined the other patches, and can rearrange my implementation to be more
like them if desired - but at the heart of this this bug really has two
requested changes:
- deferred
Robert Collins added the comment:
@Terry in principle you're right, there are an arbitrary number of things that
can go wrong, but in practice what we see is either catastrophic failure where
nothing is loaded at all *and* no error is returned or localised failure where
the deferred repo
Robert Collins added the comment:
You may need to apply the patch from http://bugs.python.org/issue19746 first as
well - I was testing with both applied.
--
___
Python tracker
<http://bugs.python.org/issue7
Robert Collins added the comment:
This is what I see in my tree:
E
==
ERROR: test_os (unittest.loader.ModuleImportFailure)
--
Traceback (most recent call last
Robert Collins added the comment:
Raced with your comment. Great - and thanks!
--
___
Python tracker
<http://bugs.python.org/issue7559>
___
___
Python-bugs-list m
Robert Collins added the comment:
Thanks; I'm still learning how to get the system here to jump appropriately :).
I thought I'd told hg to reset me to trunk...
"You are right about the docs. Reading that, I thought it was saying that
errors would have a list of the errors that
New submission from Robert Collins:
python -m unittest discover -t . foo
where foo is a package
will not trigger load_tests in foo/__init__.py.
To reproduce:
mkdir -p demo/tests
cd demo
cat < tests/__init__.py
import sys
import os
def load_tests(loader, tests, pattern):
print("H
Robert Collins added the comment:
I can certainly write the reporter glue to work with either a string or a full
reference. Note that the existing late-reporting glue captures the import error
into a string, and then raises an exception containing that string - so what
I've done is consi
Robert Collins added the comment:
This should fix this issue :)
--
keywords: +patch
Added file: http://bugs.python.org/file36694/issue22457.patch
___
Python tracker
<http://bugs.python.org/issue22
Robert Collins added the comment:
I've managed to get a windows setup working. Its my mini-vfs which needs to be
Windows aware (because the abs path of /foo is C:\\foo). I'll work up a patch
tomorrowish.
--
___
Python trac
Robert Collins added the comment:
Fix up the tests patch - tested on windows 7.
--
Added file: http://bugs.python.org/file36713/fix-windows-tests.patch
___
Python tracker
<http://bugs.python.org/issue16
Robert Collins added the comment:
bah, wrong extension to trigger review code :)
--
Added file: http://bugs.python.org/file36714/fix-windows-tests.diff
___
Python tracker
<http://bugs.python.org/issue16
Changes by Robert Collins :
Removed file: http://bugs.python.org/file36713/fix-windows-tests.patch
___
Python tracker
<http://bugs.python.org/issue16662>
___
___
Pytho
New submission from Robert Collins:
The .gitignore file was missing some build products on windows. The attached
patch makes the tree be clean after doing a debug build.
--
files: windows-git-ignore.diff
keywords: patch
messages: 227498
nosy: rbcollins
priority: normal
severity: normal
Robert Collins added the comment:
Updated patch - fixes windows tests for this patch.
--
Added file: http://bugs.python.org/file36716/issue22457.diff
___
Python tracker
<http://bugs.python.org/issue22
Robert Collins added the comment:
Right: the existing code stringifies the original exception and creates an
exception object and a closure
def test_thing(self):
raise exception_obj
but that has the stringified original exception.
--
___
Python
Robert Collins added the comment:
So this looks like its going to instantly create bugs in programs that use it.
HTTP/1.1 headers are one of:
latin1
MIME encoded (RFC2047)
invalid and working only by accident
HTTP/2 doesn't change this.
An API that encourages folk to encode into utf8 and
Robert Collins added the comment:
FWIW we probably need to capture the original unaltered URL somewhere, but also
ensure that PATH_INFO is always a relative path.
One should be able to implement a proxy in WSGI (because thats just another
specialised app), and doing that today requires
Robert Collins added the comment:
Oh, also - while its tempting to say that it doesn't matter whether we take the
urls host portion, or the host header or the server name - it does. Deployments
that look like:
LB/Firewall <-> backend container -> WSGI app
are likely to ha
Robert Collins added the comment:
So I guess the API concern I have is that there are two cases:
- common spec compliant - US-ASCII + RFC2047
- dealing with exceptions - UTF8 or otherwise
The former totally makes sense as a codec, though the current email
implementation of it isn't qu
Robert Collins added the comment:
I concur that this is a regression - "
unittest.expectedFailure()
Mark the test as an expected failure. If the test fails when run, the test
is not counted as a failure.
"
is in the public docs for the unittest module, and depending on
Robert Collins added the comment:
Oh! I didn't realise it was due to us looking at a private exception - I
haven't been given a traceback to review, just the statement of a problem
We shouldn't have done that(and *Definitely* should have filed a bug that we
needed to).
S
New submission from Robert Collins :
There is a systemic bug in BZ2File where the GIL is released to perform
compression work, and any other thread calling into BZ2File will
deadlock. We noticed in the write method, but inspection of the code
makes it clear that its systemic.
The problem is
Robert Collins added the comment:
On Sun, 2009-10-25 at 22:00 +, Antoine Pitrou wrote:
> Antoine Pitrou added the comment:
>
> Thanks, nice catch.
Yeah :).
> versions: +Python 2.6, Python 2.7, Python 3.1, Python 3.2
Python 2.5 is also affected - its what we're runn
Robert Collins added the comment:
On Sun, 2009-10-25 at 22:27 +, Antoine Pitrou wrote:
> Antoine Pitrou added the comment:
>
> > Python 2.5 is also affected - its what we're running on the server that
> > broke :)
>
> Yes, but it doesn't receive any
Robert Collins added the comment:
On Mon, 2009-10-26 at 19:23 +, Antoine Pitrou wrote:
> Antoine Pitrou added the comment:
>
> Here is a patch.
Looks fine to me assuming that the locking functions can be used outside
the GIL.
On the test side, the case I supplied was low noi
Robert Collins added the comment:
On Mon, 2009-10-26 at 21:27 +, Antoine Pitrou wrote:
> Antoine Pitrou added the comment:
> Well, your test case often succeeded here, so I decided on a more
> aggressive variation.
fair enough, if its needed - its needed
Robert Collins added the comment:
Ran into this trying to do some test isolation stuff.
Notwithstanding the questions about 'why', this is a clear limitation
hat can be solved quite simply - is there any harm that will occur if we
fix it?
I've attached a patch, with a test (
Robert Collins added the comment:
This affects 2.7 too.
--
versions: +Python 2.7
___
Python tracker
<http://bugs.python.org/issue1515>
___
___
Python-bugs-list m
Robert Collins added the comment:
@Antoine, I agree that the tests for copy should be a proper unit test;
that seems orthogonal to this patch though :)
I don't have a checkout of 3 at the moment, but do you think the test
failure on 3 is shallow or
Robert Collins added the comment:
Oh man, I looked for a regular unit test - sorry that I missed it. Bah.
I've added a call to the method and moved it into test_copy.
--
Added file: http://bugs.python.org/file15406/issue1515.patch
___
P
New submission from Robert Collins :
With deepcopy fixed, I ran across this little fixable component.
--
components: Library (Lib)
files: deepcopy-works.patch
keywords: patch
messages: 95823
nosy: rbcollins
severity: normal
status: open
title: cleanup now deepcopy copies instance
New submission from Robert Collins :
>>> from copy import deepcopy
>>> from itertools import count
>>> c = count()
>>> c.next()
0
>>> deepcopy(c)
count(0)
>>> c.next()
1
>>> deepcopy(c)
count(0)
>>> c
count(2)
>>>
Changes by Robert Collins :
--
nosy: +rbcollins
___
Python tracker
<http://bugs.python.org/issue2422>
___
___
Python-bugs-list mailing list
Unsubscribe:
Robert Collins added the comment:
"2) 0 args, e = MyException(), with overridden __str__:
py2.5 : str(e) -> 'ascii' or error; unicode(e) -> u'ascii' or error;
py2.6 : str(e) -> 'ascii' or error; unicode(e) -> u''
desired: st
New submission from Robert Collins :
:!python -m unittest foo.test_suite
Traceback (most recent call last):
File "/usr/lib/python2.6/runpy.py", line 122, in _run_module_as_main
"__main__", fname, loader, pkg_name)
File "/usr/lib/python2.6/runpy.py", line
New submission from Robert Collins :
Say I have a test module test_foo, which fails to import with
ImportError. A reason for this might be a misspelt import in that module.
TestLoader().loadTestsFromName swallows the import error and instead
crashes with:
File "/usr/lib/python2.6/unitte
Robert Collins added the comment:
mkdir thing
touch thing/__init__.py
echo "import blert" > thing/test_foo.py
python -m unittest thing.test_fooTraceback (most recent call last):
File "/usr/lib/python2.6/runpy.py", line 122, in _run_module_as_main
"__main
Robert Collins added the comment:
I'm scratching an itch at the moment, I just noted this in passing ;)
I'm partial to the 'turn it into a fake test case' approach, its what I
would do if I get to it first.
--
___
P
Robert Collins added the comment:
It should run after tearDown so that teardown can do actions that may
require cleanup; because the cleanups run in LIFO you can acquire
resources in setUp and have cleanups clean them up,
--
nosy: +rbcollins
Robert Collins added the comment:
Actually let me phrase that differently.
standard practice for setUp is
super.setUp()
my_setup_code()
and tearDown is
my_teardown_code()
super.tearDown()
because of the LIFO need.
If you imagine that clean ups are being done in the base class teardown,
at
New submission from Robert Collins :
Currently if you alter the way TestSuite iterates one must always
implement countTestCases, run, debug etc. The attached patch would make
this simpler.
If this looks ok I'll write up a test for it.
--
components: Library (Lib)
files: testsuite.
Robert Collins added the comment:
On Sat, 2009-04-04 at 22:09 +, Antoine Pitrou wrote:
> Antoine Pitrou added the comment:
>
> teardown
>
> Why should they? It's only an implementation choice, and not a wise one
> I would say (precisely because people are us
Robert Collins added the comment:
On Sat, 2009-04-04 at 23:06 +, Antoine Pitrou wrote:
> Antoine Pitrou 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?
&g
Robert Collins added the comment:
On Sun, 2009-04-05 at 07:25 +, Garrett Cooper wrote:
> Garrett Cooper added the comment:
>
> I think some perspective is required on this enhancement request. I
> originally filed this issue -- http://bugs.python.org/issue5538 --
> because
Robert Collins added the comment:
On Sun, 2009-04-05 at 10:15 +, Antoine Pitrou wrote:
> Antoine Pitrou added the comment:
>
> > Our experience in bzr (we use this heavily, and migrated to it
> > incrementally across our 17K fixture suite) is that we rarely need to
&
Robert Collins added the comment:
On Sun, 2009-04-05 at 21:31 +, Antoine Pitrou wrote:
> Antoine Pitrou added the comment:
>
> > So, we are talking about adding a feature that could cause problem whether
> > cleanup is performed before tearDown or after tearD
1 - 100 of 542 matches
Mail list logo
