Brett Cannon wrote:
> On Wed, Jun 25, 2008 at 6:08 AM, Andrew Bennetts
[...]
> >
> > Should I file a bug for this?
> >
>
> 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 quick
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 wha
> 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 o
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 a
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
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 t
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 di
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
deallocat
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 su
> 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 th
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 tes
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 decreasi
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
> 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
> usef
[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
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 couldn't
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
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 thoug
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
d
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 t
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 transformed
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
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 imp
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 would
24 matches
Mail list logo
