"Steven D'Aprano" <[EMAIL PROTECTED]> writes:
> On Tue, 15 Jul 2008 09:26:45 am Raymond Hettinger wrote:
> > From: "Ben Finney" <[EMAIL PROTECTED]>
> >
> > > Right, so I'm putting up a separate PEP just for the renaming.
> > > Should be arriving on this list soon.
> >
> > I would like to work with
On Tue, 15 Jul 2008 09:26:45 am Raymond Hettinger wrote:
> From: "Ben Finney" <[EMAIL PROTECTED]>
>
> > Right, so I'm putting up a separate PEP just for the renaming.
> > Should be arriving on this list soon.
>
> I would like to work with you or someone else who is interested
> on an alternative PE
Ben Finney wrote:
Ron Adam <[EMAIL PROTECTED]> writes:
+1 for a simpler testing module.
I've no objection.
Just letting you know there is interest in a lighter weight testing
suite.
'doctest' is a very simple testing module, that is a very useful tool.
Looking at the unittest discussi
Ron Adam <[EMAIL PROTECTED]> writes:
> +1 for a simpler testing module.
I've no objection.
> Just letting you know there is interest in a lighter weight testing
> suite.
'doctest' is a very simple testing module, that is a very useful tool.
> Looking at the unittest discussions, it doesn't loo
Raymond Hettinger wrote:
From: "Ben Finney" <[EMAIL PROTECTED]>
Right, so I'm putting up a separate PEP just for the renaming. Should
be arriving on this list soon.
I would like to work with you or someone else who is interested
on an alternative PEP for a separate, simpler test module
using
"Guido van Rossum" <[EMAIL PROTECTED]> writes:
> It would, however, be a shame if we couldn't agree to *add* a bunch
> of features, for example better reporting when two lists or long
> strings differ.
I intend to phrase such additions in terms of PEP-8-only names, so
this name consolidation seem
http://lists.idyll.org/pipermail/testing-in-python/2007-November/000406.html
& associated thread, for those interested in the variety of mock
libraries...
That might be a good beginning for an updateable wiki page on mock
libraries.
___
Python-De
On Mon, Jul 14, 2008 at 11:55 PM, somebody wrote:
> I'm surprised nobody (that I've noticed) has brought up the point yet that
[...]
Not picking on whoever wrote that specifically, but if there's
anything that surprises me, it's how many people have voiced opinions
already (including many of them
On Tue, 15 Jul 2008 04:55:59 pm Thomas Lotze wrote:
> I'm surprised nobody (that I've noticed) has brought up the point yet
> that test code is a lot easier to read if it makes positive
> assertions.
Please don't claim that your subjective opinion is an objective fact.
> When reading failure c
Michael Foord wrote:
Raymond Hettinger wrote:
From: "Ben Finney" <[EMAIL PROTECTED]>
Right, so I'm putting up a separate PEP just for the renaming. Should
be arriving on this list soon.
I would like to work with you or someone else who is interested
on an alternative PEP for a separate, simpl
Thomas Lotze wrote:
Ben Finney wrote:
I'd count this as another (minor) point in favour of making the 'fail*'
methods canonical: the names are consistent *and* gramatically sensible:
-1
I'm surprised nobody (that I've noticed) has brought up the point yet that
test code is a lot easier to re
Ben Finney wrote:
> I'd count this as another (minor) point in favour of making the 'fail*'
> methods canonical: the names are consistent *and* gramatically sensible:
-1
I'm surprised nobody (that I've noticed) has brought up the point yet that
test code is a lot easier to read if it makes posit
From: "Michael Foord" <[EMAIL PROTECTED]>
Maybe Python needs a good mocking module in the standard library. There
are plenty, but we use a particularly nice one at Resolver Systems [1]. :-)
-1
This comes up occassionally and gets shot down.
http://bugs.python.org/issue708125
And: http://bug
On Mon, Jul 14, 2008 at 09:37:30PM -0700, Raymond Hettinger wrote:
-> From: "Michael Foord" <[EMAIL PROTECTED]>
-> >Maybe Python needs a good mocking module in the standard library. There
-> >are plenty, but we use a particularly nice one at Resolver Systems [1]. :-)
->
-> -1
->
-> This comes up
From: "Michael Foord" <[EMAIL PROTECTED]>
Maybe Python needs a good mocking module in the standard library. There
are plenty, but we use a particularly nice one at Resolver Systems [1]. :-)
-1
This comes up occassionally and gets shot down.
http://bugs.python.org/issue708125
Mock objects mean
Guido van Rossum wrote:
On Mon, Jul 14, 2008 at 5:13 PM, Raymond Hettinger <[EMAIL PROTECTED]> wrote:
It takes about one day of using py.test to realize have much
cleaner and more readable its syntax is. Also, writing the
tests is *much* more pleasant. It has the same clean, clear
joy as wr
On Mon, Jul 14, 2008 at 5:13 PM, Raymond Hettinger <[EMAIL PROTECTED]> wrote:
> It takes about one day of using py.test to realize have much
> cleaner and more readable its syntax is. Also, writing the
> tests is *much* more pleasant. It has the same clean, clear
> joy as writing regular python c
On Mon, Jul 14, 2008 at 6:43 PM, Michael Foord
<[EMAIL PROTECTED]> wrote:
>
> However, to provide readable output for errors in even simple tests (like a
> == b) py.test does magic with stack frames and code objects - in order to
> discover the objects being compared.
Maybe what we need to do then
From: "Michael Foord" <[EMAIL PROTECTED]>
However, to provide readable output for errors in even simple tests
(like a == b) py.test does magic with stack frames and code objects - in
order to discover the objects being compared.
Don't have to go that route. Can use plain python assert failure
On Tue, Jul 15, 2008 at 9:43 AM, Michael Foord
<[EMAIL PROTECTED]> wrote:
> I personally find unittest pretty readable, the feature most lacking is
> autodiscovery of tests which nose does seem to provide very well although I
> haven't used it yet.
FWIW, Twisted's 'trial' has done this since about
Raymond Hettinger wrote:
From: "Ben Finney" <[EMAIL PROTECTED]>
Right, so I'm putting up a separate PEP just for the renaming. Should
be arriving on this list soon.
I would like to work with you or someone else who is interested
on an alternative PEP for a separate, simpler test module
using t
Raymond Hettinger wrote:
From: "Ben Finney" <[EMAIL PROTECTED]>
Right, so I'm putting up a separate PEP just for the renaming. Should
be arriving on this list soon.
I would like to work with you or someone else who is interested
on an alternative PEP for a separate, simpler test module
using t
Hi,
> I think some variant
> of py.test could be done that is compatable with unittest
> and the did not have the "magic" present in earlier versions of py.test.
It already exists:
http://www.somethingaboutorange.com/mrl/projects/nose/
Regards
Antoine.
___
On Mon, Jul 14, 2008 at 6:26 PM, Raymond Hettinger <[EMAIL PROTECTED]> wrote:.
>
> I would like to work with you or someone else who is interested
> on an alternative PEP for a separate, simpler test module
> using the py.test syntax. That is much simpler to learn and use.
> Instead of self.assert
From: "Ben Finney" <[EMAIL PROTECTED]>
Right, so I'm putting up a separate PEP just for the renaming. Should
be arriving on this list soon.
I would like to work with you or someone else who is interested
on an alternative PEP for a separate, simpler test module
using the py.test syntax. That i
"Raymond Hettinger" <[EMAIL PROTECTED]> writes:
> Given all of the language changes in 2.6 and 3.0, I would think that
> it is dangerous to make any changes at all to the unittest API. That
> module is the one anchor in a sea of change.
Agreed. I'm not proposing to have the unittest API change at
Michael Foord <[EMAIL PROTECTED]> writes:
> As proposed the changes don't remove or rename anything - so there
> will be no code breakage, just additional test methods.
Right, so I'm putting up a separate PEP just for the renaming. Should
be arriving on this list soon.
> However, as we're into t
Raymond Hettinger wrote:
Michael Foord <[EMAIL PROTECTED]> writes:
The full list of changes proposed (feel free to start - but ping me or
the list) and not shot down was something like:
[…]
Thanks. I'm working these into another draft PEP that I hope to have
up in a day or two.
Given all o
Michael Foord <[EMAIL PROTECTED]> writes:
The full list of changes proposed (feel free to start - but ping me or
the list) and not shot down was something like:
[…]
Thanks. I'm working these into another draft PEP that I hope to have
up in a day or two.
Given all of the language changes in
Michael Foord <[EMAIL PROTECTED]> writes:
> The full list of changes proposed (feel free to start - but ping me or
> the list) and not shot down was something like:
[…]
Thanks. I'm working these into another draft PEP that I hope to have
up in a day or two.
--
\ “[W]e are still the first g
Steve Holden <[EMAIL PROTECTED]> writes:
> Ben Finney wrote:
> > and so on; i.e. that 'assert_is_not' breaks the obvious pattern
> > set by the others, in the interest of matching Python's 'is not'
> > grammar.
>
> Well, I'd have said "in the interest of reading correctly in English",
> though I
Steve Holden wrote:
Ben Finney wrote:
To be clear, I take it you're in favour of the following names (with
no aliases):
assert_equalassert_not_equal
assert_is assert_is_not
assert_in assert_not_in
assert_almost_equal as
Nick Coghlan <[EMAIL PROTECTED]> writes:
> Would it be worth Ben collating your current notes into a draft PEP
> targeting 2.7/3.1?
I'll do it and we'll find out.
--
\ “A fine is a tax for doing wrong. A tax is a fine for doing |
`\ wel
Ben Finney wrote:
Nick Coghlan <[EMAIL PROTECTED]> writes:
Ben Finney wrote:
The problem is, that makes it quite inconsistent with other "not"
uses (such as "assert_not_equal", "assert_not_in", etc.) I would
really prefer that all these "not" uses be gramatically consistent
for predictability.
Nick Coghlan <[EMAIL PROTECTED]> writes:
> Ben Finney wrote:
> > The problem is, that makes it quite inconsistent with other "not"
> > uses (such as "assert_not_equal", "assert_not_in", etc.) I would
> > really prefer that all these "not" uses be gramatically consistent
> > for predictability. Is
Michael Foord wrote:
Ben Finney wrote:
Howdy Michael,
I'm interested in the changes you're proposing for Python's 'unittest'
module. I am (like, I suspect, many Python coders) maintaining my own
set of extensions to the module across many projects, so I'd really
like to see many of the impro
Ben Finney wrote:
Steve Holden <[EMAIL PROTECTED]> writes:
Michael Foord wrote:
Adding the following new asserts:
assertIn(member, container, msg=None)
assertNotIn (member, container, msg=None)
assertIs (first, second, msg=None)
assertNotIs (first, second, msg=None)
Tim Peters wrote:
[Michael Foord]
...
Adding the following new asserts:
...
assertNotIs (first, second, msg=None)
[Steve Holden]
Please, let's call this one "assertIsNot".
+1
I know it's valid Python to say
if a not is b:
Nope, that's a syntax error.
Rats, naturally I was think
On Sun, 13 Jul 2008 23:51:44 +0100, Michael Foord <[EMAIL PROTECTED]> wrote:
Ben Finney wrote:
Howdy Michael,
I'm interested in the changes you're proposing for Python's 'unittest'
module. I am (like, I suspect, many Python coders) maintaining my own set
of extensions to the module across man
[Michael Foord]
>> ...
>> Adding the following new asserts:
>>
>> ...
>> assertNotIs (first, second, msg=None)
[Steve Holden]
> Please, let's call this one "assertIsNot".
+1
> I know it's valid Python to say
>
> if a not is b:
Nope, that's a syntax error.
> but it's a much less natural wa
Steve Holden <[EMAIL PROTECTED]> writes:
> Michael Foord wrote:
> > Adding the following new asserts:
> >
> >assertIn(member, container, msg=None)
> >assertNotIn (member, container, msg=None)
> >assertIs (first, second, msg=None)
> >assertNotIs (first, second, msg=Non
Michael Foord wrote:
Ben Finney wrote:
Howdy Michael,
I'm interested in the changes you're proposing for Python's 'unittest'
module. I am (like, I suspect, many Python coders) maintaining my own
set of extensions to the module across many projects, so I'd really
like to see many of the impro
Michael Foord <[EMAIL PROTECTED]> writes:
> Adding the following new asserts:
>
>assertIn(member, container, msg=None)
>assertNotIn (member, container, msg=None)
>assertIs (first, second, msg=None)
>assertNotIs (first, second, msg=None)
>assertRaisesWithMessage
Ben Finney wrote:
Howdy Michael,
I'm interested in the changes you're proposing for Python's 'unittest'
module. I am (like, I suspect, many Python coders) maintaining my own
set of extensions to the module across many projects, so I'd really
like to see many of the improvements you discuss ac
Neal Norwitz wrote:
[Michael working on cleaning up the unittest module]
it seems like most of the good ideas have been captured already. I'll
through two more (low priority) ideas out there.
1) Randomized test runner/option that runs tests in a random order
(like regrtest.py -r, but for meth
Neal Norwitz wrote:
All the expect methods duplicate the assert methods. Asserts can the
test to fail immediately, expects don't fail immediately allowing the
test to continue. All the expect failures are collected and printed
at the end of the method run. I was a little skeptical about assert
[Michael working on cleaning up the unittest module]
it seems like most of the good ideas have been captured already. I'll
through two more (low priority) ideas out there.
1) Randomized test runner/option that runs tests in a random order
(like regrtest.py -r, but for methods)
2) decorator to
Michael Foord wrote:
> that the 'assert' statement should be used
> instead of 'assert_'.
assert statements are actually a bad idea in tests - they get skipped
when the test suite is run with optimisation switched on.
Cheers,
Nick.
--
Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Austr
Terry Reedy wrote:
> "Michael Foord" <[EMAIL PROTECTED]> wrote in message
> news:[EMAIL PROTECTED]
> | I think that there is still work I can do on the docs even before any
> | grand renaming...
>
> In a related thread, I proposed and Guido approved that the 2.6/3.0 docs
> be changed to
> 1. speci
Guido van Rossum wrote:
> On Thu, Apr 17, 2008 at 3:31 PM, Jonathan Lange <[EMAIL PROTECTED]> wrote:
>> On Thu, Apr 17, 2008 at 11:49 PM, Michael Foord
>> <[EMAIL PROTECTED]> wrote:
>> > assert_raises_with_message(exc_class, message, callable, *args,
>> > **keywargs)
>> >
>>
>> I don'
On Fri, Apr 18, 2008 at 8:34 AM, Guido van Rossum <[EMAIL PROTECTED]> wrote:
>
> On Thu, Apr 17, 2008 at 3:31 PM, Jonathan Lange <[EMAIL PROTECTED]> wrote:
> > On Thu, Apr 17, 2008 at 11:49 PM, Michael Foord
> > <[EMAIL PROTECTED]> wrote:
> > > assert_raises_with_message(exc_class, mes
On Thu, Apr 17, 2008 at 3:31 PM, Jonathan Lange <[EMAIL PROTECTED]> wrote:
> On Thu, Apr 17, 2008 at 11:49 PM, Michael Foord
> <[EMAIL PROTECTED]> wrote:
> > assert_raises_with_message(exc_class, message, callable, *args,
> > **keywargs)
> >
>
> I don't think this one should go in.
>
On Thu, Apr 17, 2008 at 11:49 PM, Michael Foord
<[EMAIL PROTECTED]> wrote:
> assert_raises_with_message(exc_class, message, callable, *args,
> **keywargs)
>
I don't think this one should go in.
I think it would be better if assertRaises just returned the exception
object that it catches.
On Fri, Apr 18, 2008 at 12:54 AM, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> I'm worried that a mass renaming would do anything but inconvenience
> users during the already stressful 2->3 transition.
>
> I'm more in favor of the original proposal of reducing the redundancy
> post-3.0.
>
> If
-On [20080417 19:46], Terry Reedy ([EMAIL PROTECTED]) wrote:
>Have you or are you going to make these changes or should I open a separate
>tracker issue?
You can always put it on my account in the tracker (asmodai) and I'll get to
it in the coming days.
--
Jeroen Ruigrok van der Werven / asmod
"Michael Foord" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
| I think that there is still work I can do on the docs even before any
| grand renaming...
In a related thread, I proposed and Guido approved that the 2.6/3.0 docs
be changed to
1. specify that the Fail... names will di
On Thu, Apr 17, 2008 at 8:27 AM, Christian Heimes <[EMAIL PROTECTED]> wrote:
> Most of the etc. could be simplified with a function assertOp which
> takes an operator as first argument
>
> import operator
> def assertOp(self, op, a, b, msg):
> func = getattr(operator, op)
> self.assert_
On Thu, Apr 17, 2008 at 7:59 AM, Michael Foord
<[EMAIL PROTECTED]> wrote:
> By etc I assume you mean:
>
>assertLessThan
>assertGreaterThan
>assertLessThanOrEquals
>assertGreaterThanOrEquals
These names are used here:
assertListEqual(self, list1, list2, msg=None):
assertIn(self, a
Michael Foord wrote:
> Guido van Rossum wrote:
>> I'm worried that a mass renaming would do anything but inconvenience
>> users during the already stressful 2->3 transition.
>>
>> I'm more in favor of the original proposal of reducing the redundancy
>> post-3.0.
>>
>>
>
> So nix the PEP-8'if
Jesse Noller wrote:
> On Thu, Apr 17, 2008 at 10:59 AM, Michael Foord
> <[EMAIL PROTECTED]> wrote:
>
>> Guido van Rossum wrote:
>> > I'm worried that a mass renaming would do anything but inconvenience
>> > users during the already stressful 2->3 transition.
>> >
>> > I'm more in favor of th
Christian Heimes wrote:
> Michael Foord schrieb:
>
>> By etc I assume you mean:
>>
>> assertLessThan
>> assertGreaterThan
>> assertLessThanOrEquals
>> assertGreaterThanOrEquals
>>
>> Would not variants be useful as well - it seems not as the not of one is
>> always another... (I
Great that you're taking this on, Michael!
On 17 Apr 2008, at 16:59, Michael Foord wrote:
>> If you're looking for useful features, Google has a set of extensions
>> to unittest.py that I find useful:
>>
>> - module-level setUp and tearDown
>>
> So when a suite is made from a module the setUp sh
Michael Foord schrieb:
> By etc I assume you mean:
>
> assertLessThan
> assertGreaterThan
> assertLessThanOrEquals
> assertGreaterThanOrEquals
>
> Would not variants be useful as well - it seems not as the not of one is
> always another... (I think 'assertLessThan' reads better t
On Thu, Apr 17, 2008 at 10:59 AM, Michael Foord
<[EMAIL PROTECTED]> wrote:
> Guido van Rossum wrote:
> > I'm worried that a mass renaming would do anything but inconvenience
> > users during the already stressful 2->3 transition.
> >
> > I'm more in favor of the original proposal of reducing th
Guido van Rossum wrote:
> I'm worried that a mass renaming would do anything but inconvenience
> users during the already stressful 2->3 transition.
>
> I'm more in favor of the original proposal of reducing the redundancy
> post-3.0.
>
>
So nix the PEP-8'ifying until after 3.0.
So new method
I'm worried that a mass renaming would do anything but inconvenience
users during the already stressful 2->3 transition.
I'm more in favor of the original proposal of reducing the redundancy post-3.0.
If you're looking for useful features, Google has a set of extensions
to unittest.py that I find
Hello all,
I'm starting to put together a list of cleanups (with documentation
changes) for the unittest module. I thought someone had already done
this but the issue with the most comments I could find was 2578 which
doesn't go into much detail:
http://bugs.python.org/issue2578
The thing mos
67 matches
Mail list logo
