Jean-Paul Calderone wrote:
On Tue, 24 Jun 2008 23:03:33 -, [EMAIL PROTECTED] wrote:
It's also nice to have this facility in the test harness itself, so
that you don't run the additional risk of accidentally (and silently)
leaving warning suppression in place for subsequent tests.
It
Nick Coghlan wrote:
[...]
I forgot this had already been added to the Python regression test
machinery, so it will just be a matter of updating the relevant tests to
use it:
That's a nice surprise! I'm glad the standard library is growing facilities
like this.
I think it could be
On Wed, Jun 25, 2008 at 6:08 AM, Andrew Bennetts
[EMAIL PROTECTED] wrote:
Nick Coghlan wrote:
[...]
I forgot this had already been added to the Python regression test
machinery, so it will just be a matter of updating the relevant tests to
use it:
That's a nice surprise! I'm glad the
Hi there,
I've just witnessed an interesting consequence of the way doctest works.
I ran into an issue when doctesting an aspect of SQLAlchemy, where the
following guard clause tripped me up:
# In the normal call flow, a request for any of the 3 basic collection
# types is
On Jun 25, 2008, at 2:45 PM, Martijn Faassen wrote:
This places new key/value pairs into a dictionary, in this case
test.globs. Unfortunately when the execution results in a class
definition, it'll have its __module__ attribute set to
'__builtin__'. Try as I might, I couldn't convince exec
It seems to me that the root problem is allocation spikes of legitimate,
useful data. Perhaps then we need some sort of test to determine if those
are legitimate. Perhaps checking every nth (with n decreasing as allocation
bytes increases) object allocated during a spike could be useful. Then
On Wed, Jun 25, 2008 at 12:18 PM, Brett Cannon [EMAIL PROTECTED] wrote:
If you want, but Benjamin plans to undocument this for users along
with all other test.support stuff (which I agree with). Most of the
APIs in test.support were just quickly written and have not
necessarily been thought
Hi all!
In Python Argentina we get together in two places, Buenos Aires and
Santa Fe, and worked out around 10-12 bugs, which is around the half
of the total for both days, so I'm very happy, :)
We even had a Python logo shaped cake, see, see [1].
Did you participate? What do you think it's the
Fred Drake wrote:
On Jun 25, 2008, at 2:45 PM, Martijn Faassen wrote:
This places new key/value pairs into a dictionary, in this case
test.globs. Unfortunately when the execution results in a class
definition, it'll have its __module__ attribute set to '__builtin__'.
Try as I might, I
[Adding back the list.]
On Tue, Jun 24, 2008 at 9:53 PM, Raymond Hettinger [EMAIL PROTECTED] wrote:
While I think it's fine to have some function that reveals the binary
representation of floats, I don't think that overlaying this on
hex/oct/bin is worth the problems it causes.
What
It seems to me that the root problem is allocation spikes of legitimate,
useful data. Perhaps then we need some sort of test to determine if
those are legitimate. Perhaps checking every nth (with n decreasing as
allocation bytes increases) object allocated during a spike could be
useful. Then
I'm a little worried about making stuff undocumented that every core
developer needs to use -- everyone writing tests needs to continue to
use test_support (now test.support?). I imagine people writing unit
test suites for 3rd party libraries might want to use its services
too.
In general I'm not
On Wed, Jun 25, 2008 at 4:55 PM, Martin v. Löwis [EMAIL PROTECTED]
wrote:
It seems to me that the root problem is allocation spikes of legitimate,
useful data. Perhaps then we need some sort of test to determine if
those are legitimate. Perhaps checking every nth (with n decreasing as
On Wed, Jun 25, 2008 at 2:00 PM, Guido van Rossum [EMAIL PROTECTED] wrote:
I'm a little worried about making stuff undocumented that every core
developer needs to use -- everyone writing tests needs to continue to
use test_support
Right, but I would think all core developers know about
I took the statement, Current GC only takes into account container
objects, which, most significantly, ignores string objects (of which
most applications create plenty) to mean that strings were ignored for
deciding when to do garbage collection. I mistakenly thought that was
because they
On Wed, Jun 25, 2008 at 4:00 PM, Guido van Rossum [EMAIL PROTECTED] wrote:
I'm a little worried about making stuff undocumented that every core
developer needs to use -- everyone writing tests needs to continue to
use test_support (now test.support?). I imagine people writing unit
test suites
On Wed, Jun 25, 2008 at 4:55 PM, Martin v. Löwis [EMAIL PROTECTED] wrote:
I think exactly the other way 'round. The timing of thing should not
matter at all, only the exact sequence of allocations and deallocations.
I would it be possible, if not a good idea, to only track object
deallocations
Hi,
I just reported issue3202 in the bugracker
(http://bugs.python.org/issue3202) with a patch that implements a way
to disable unittest.TestCases using a decorator. Benjamin Peterson
suggested that I bring up the issue on python-dev.
The idea behind the patch is that it’s sometimes useful to
On Thu, Jun 26, 2008 at 7:13 AM, Justin Mazzola Paluska [EMAIL PROTECTED]
wrote:
Hi,
...
The idea behind the patch is that it's sometimes useful to disable
tests without removing them from the TestCase. For example, a
co-worker and I have a module with a few tests that will fail for the
2008/6/25 Justin Mazzola Paluska [EMAIL PROTECTED]:
The idea behind the patch is that it's sometimes useful to disable
tests without removing them from the TestCase. For example, a
co-worker and I have a module with a few tests that will fail for the
forseeable future because we haven't had
On Wed, Jun 25, 2008 at 7:52 PM, Facundo Batista
[EMAIL PROTECTED] wrote:
What about TestSkipped? I thought that raising
test_support.TestSkipped should behave like this: you're saying that
you're actually NOT executing the tests, but you say that they are
there.
I think he's talking about
I would it be possible, if not a good idea, to only track object
deallocations as the GC traversal trigger? As far as I know, dangling
cyclic references cannot be formed when allocating objects.
Not sure what you mean by that.
x = []
x.append(x)
del x
creates a cycle with no deallocation
On Thu, Jun 26, 2008 at 12:01 AM, Martin v. Löwis [EMAIL PROTECTED] wrote:
I would it be possible, if not a good idea, to only track object
deallocations as the GC traversal trigger? As far as I know, dangling
cyclic references cannot be formed when allocating objects.
Not sure what you mean
23 matches
Mail list logo
