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 quickly written
Andrew Bennetts wrote:
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
On Thu, 26 Jun 2008 23:56:23 +1000, Nick Coghlan [EMAIL PROTECTED] wrote:
[snip]
Ok, then we're back to there being no supported way to write tests that
need to
intercept warnings. Twisted has already suffered from this (JP reports
that
Twisted's assertWarns is broken in 2.6), and I doubt
On Thu, Jun 26, 2008 at 6:56 AM, Nick Coghlan [EMAIL PROTECTED] wrote:
Andrew Bennetts wrote:
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
Jean-Paul Calderone wrote:
The first assertion passes (by the way, I don't understand why w.message
isn't the message passed to warn, but is instead an instance of
UserWarning)
but the second assertion fails.
See Brett's comment elsewhere in this thread about the level of thought
(or lack
On Fri, 27 Jun 2008 01:14:36 +1000, Nick Coghlan [EMAIL PROTECTED] wrote:
Jean-Paul Calderone wrote:
[snip]
The real problem with testing many uses of the warning system is that it
doesn't expose enough public APIs for this to be possible. You *have*
to use APIs which are, apparently, private
Jean-Paul Calderone wrote:
I don't particularly care about the details, I just want some public
API for this. Making warn_explicit public seems better to me, since
it was already there in previous versions of Python, and it lets you
completely ignore both the filters list and the global
On Fri, 27 Jun 2008 01:52:18 +1000, Nick Coghlan [EMAIL PROTECTED] wrote:
Jean-Paul Calderone wrote:
I don't particularly care about the details, I just want some public
API for this. Making warn_explicit public seems better to me, since
it was already there in previous versions of Python, and
Guido van Rossum schrieb:
Ok, then we're back to there being no supported way to write tests that
need to
intercept warnings. Twisted has already suffered from this (JP reports
that
Twisted's assertWarns is broken in 2.6), and I doubt it's alone.
So I guess I am filing a bug after all... :)
On Thu, Jun 26, 2008 at 12:33 PM, Georg Brandl [EMAIL PROTECTED] wrote:
Guido van Rossum schrieb:
Ok, then we're back to there being no supported way to write tests that
need to
intercept warnings. Twisted has already suffered from this (JP reports
that
Twisted's assertWarns is broken in
On Thu, Jun 26, 2008 at 3:21 PM, Guido van Rossum [EMAIL PROTECTED] wrote:
On Thu, Jun 26, 2008 at 12:33 PM, Georg Brandl [EMAIL PROTECTED] wrote:
Since this is part of Benjamin's project, we will make sure that the
test_support that emerges from it will be properly documented, stable
and
On Thu, Jun 26, 2008 at 9:01 AM, Jean-Paul Calderone [EMAIL PROTECTED] wrote:
On Fri, 27 Jun 2008 01:52:18 +1000, Nick Coghlan [EMAIL PROTECTED] wrote:
Jean-Paul Calderone wrote:
I don't particularly care about the details, I just want some public
API for this. Making warn_explicit public
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 Devs,
Today, I saw the Py3k beta 1 announcement, so I thought Well, I gotta
do my duty and try to migrate my own code base to see if I can uncover
any problems. I'm just at the step where I run my test suite with the
-3 flag, and I noticed something peculiar: I get DeprecationWarning
from
Virgil Dupras wrote:
Hi Devs,
Today, I saw the Py3k beta 1 announcement, so I thought Well, I gotta
do my duty and try to migrate my own code base to see if I can uncover
any problems. I'm just at the step where I run my test suite with the
-3 flag, and I noticed something peculiar: I get
On Tue, Jun 24, 2008 at 12:34 PM, Nick Coghlan [EMAIL PROTECTED] wrote:
Probably because nobody has stepped up to write a migration HOWTO yet...
I'm not much of a writer, but once I'm finished with the migration,
I'll do it (if it hasn't been done then). It's about time I try to
learn reST...
On Tue, Jun 24, 2008 at 5:34 AM, Nick Coghlan [EMAIL PROTECTED] wrote:
I'd say so, yes. If tracker issues don't exist yet, please create them. The
focus for the first beta was really on getting all the syntax and API
changes stable - the remaining time between the first beta release and the
Benjamin Peterson wrote:
On Tue, Jun 24, 2008 at 5:34 AM, Nick Coghlan [EMAIL PROTECTED] wrote:
I'd say so, yes. If tracker issues don't exist yet, please create them. The
focus for the first beta was really on getting all the syntax and API
changes stable - the remaining time between the first
On Tue, Jun 24, 2008 at 8:08 AM, Nick Coghlan [EMAIL PROTECTED] wrote:
Benjamin Peterson wrote:
On Tue, Jun 24, 2008 at 5:34 AM, Nick Coghlan [EMAIL PROTECTED] wrote:
I'd say so, yes. If tracker issues don't exist yet, please create them.
The
focus for the first beta was really on getting
The same generic warning against sweeping changes applies here though.
You have to manually review each change. The stdlib and especially the
test suite is likely to break if you just let 2to3 run over it, even
just a single fixer like fix_has_key.
On Tue, Jun 24, 2008 at 6:11 AM, Benjamin
On Tue, Jun 24, 2008 at 11:42 AM, Guido van Rossum [EMAIL PROTECTED] wrote:
The same generic warning against sweeping changes applies here though.
You have to manually review each change. The stdlib and especially the
test suite is likely to break if you just let 2to3 run over it, even
just a
Benjamin Peterson wrote:
On Tue, Jun 24, 2008 at 11:42 AM, Guido van Rossum [EMAIL PROTECTED] wrote:
The same generic warning against sweeping changes applies here though.
You have to manually review each change. The stdlib and especially the
test suite is likely to break if you just let 2to3
On 10:05 pm, [EMAIL PROTECTED] wrote:
We need to be especially careful with the unit test suite itself -
changing the test code to avoid the warning will normally be the right
answer, but when the code is actually setting out to test the
deprecated feature we need to suppress the warning in
On Tue, 24 Jun 2008 23:03:33 -, [EMAIL PROTECTED] wrote:
On 10:05 pm, [EMAIL PROTECTED] wrote:
We need to be especially careful with the unit test suite itself - changing
the test code to avoid the warning will normally be the right answer, but
when the code is actually setting out to test
26 matches
Mail list logo
