Ben Finney wrote:
The function name should say *all* that the function does, from the
perspective of the caller.
I have to disagree with that (and I think you'll find plenty of other
folks here will disagree as well). A good function names needs to have a
few characters:
- serve as a
Nick Coghlan wrote:
Taking an existing function such as assertRaises and going hey, we
aren't using the return value from this, wouldn't it be really
convenient if it told us the exact exception it actually caught?
doesn't cause any problems for existing code, and makes it much easier
to
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Ron Adam wrote:
Nick Coghlan wrote:
The essence of the function remains unchanged - you're still asserting
that a particular exception is raised. Returning the actual exception
object that was caught is merely a convenience that makes a lot
Please move all discussions of unittest frameworks to
[EMAIL PROTECTED] It is an interesting topic -- so interesting,
in fact, that exploring all the different ideas under discussion is
overwhelming the primary purpose of python-dev, which at this point is
to get the 2.6 and 3.0 releases into
Tres Seaver wrote:
Ron Adam wrote:
Nick Coghlan wrote:
The essence of the function remains unchanged - you're still asserting
that a particular exception is raised. Returning the actual exception
object that was caught is merely a convenience that makes a lot of sense.
I'm not sure I
Having skimmed much material about proposed changes to the venerable
unitest module, I'd like to set some boundaries. PEPs that don't
follow the following rules are very unlikely to be accepted.
1. The API is not going to be renamed to PEP-8 conformance. This
notwithstanding the purported outcome
On Wed, Jul 16, 2008 at 2:57 PM, Guido van Rossum [EMAIL PROTECTED] wrote:
Having skimmed much material about proposed changes to the venerable
unitest module, I'd like to set some boundaries. PEPs that don't
follow the following rules are very unlikely to be accepted.
So basically, discussion
Guido van Rossum wrote:
Having skimmed much material about proposed changes to the venerable
unitest module, I'd like to set some boundaries. PEPs that don't
follow the following rules are very unlikely to be accepted.
1. The API is not going to be renamed to PEP-8 conformance. This
From: Michael Foord [EMAIL PROTECTED]
I assume this doesn't rule out the addition of [some of..] the new
convenience test methods?
In Kent Beck's book on Test Driven Development, he complains that most
unittest implementations spawned from his original work have grown far
too complicated and
Raymond Hettinger wrote:
From: Michael Foord [EMAIL PROTECTED]
I assume this doesn't rule out the addition of [some of..] the new
convenience test methods?
In Kent Beck's book on Test Driven Development, he complains that most
unittest implementations spawned from his original work have
If some people want to proceed down the path of useful additions,
I challenge them to think bigger. Give me some test methods that
improve my life. Don't give me thirty ways to spell something I can
already do.
From: Michael Foord [EMAIL PROTECTED]
I assert that... the following changes do
On Wed, Jul 16, 2008 at 1:03 PM, Michael Foord
[EMAIL PROTECTED] wrote:
Guido van Rossum wrote:
2. Radical changes to the API are off the table. If a radically
different API is to be accepted, the road to such acceptance is not a
design-by-committee PEP, but adoption of a 3rd party module with
On Wed, Jul 16, 2008 at 02:03:29PM -0700, Raymond Hettinger wrote:
- - self.assert_(func(x) in result_set)
- + self.assertIn(func(x), result_set)
-
- Yawn. The gain is zero. Actually, it's negative because the second
- doesn't read as nicely as the pure python expression.
People are proposing
C. Titus Brown wrote:
[snip..]
Paranthetically, wrt unittest, the world seems to be divided into two
kinds of people : those who find the current API uninspiring but ok, and
those who absolutely hate it. Has anyone said that they *love* the
current unittest API with all of its boilerplate? If
On Wed, Jul 16, 2008 at 02:15:29PM -0700, C. Titus Brown wrote:
- At this point I might suggest taking a look at the nose and py.test
- discovery rules and writing a simple test discovery system to find
- wrap 'test_' functions/classes and doctests in a unittest wrapper.
-
- Many people use nose
On Wed, Jul 16, 2008 at 2:03 PM, Raymond Hettinger [EMAIL PROTECTED] wrote:
From: Michael Foord [EMAIL PROTECTED]
assertIn / assertNotIn I use very regularly for collection membership
- self.assert_(func(x) in result_set)
+ self.assertIn(func(x), result_set)
Yawn. The gain is zero.
C. Titus Brown schrieb:
Sorry for the second message, but... let's compare:
test_sort.py:
#! /usr/bin/env python
import unittest
class Test(unittest.TestCase):
def test_me(self):
seq = [ 5, 4, 1, 3, 2 ]
seq.sort()
self.assertEqual(seq, [1, 2, 3, 4, 5])
if __name__ ==
On 16/07/2008, at 18:24, Guido van Rossum wrote:
Think bigger! No fat APIs. Do something cool! Checkout the
dynamic test creation in test_decimal to see if it can be
generalized.
Give me some cool test runners. Maybe find a way to automatically
launch pdb or to dump the locals
On Wed, Jul 16, 2008 at 10:37:46PM +0100, Michael Foord wrote:
- test_sort2.py :
-
- def test_me():
- seq = [ 5, 4, 1, 3 2 ]
- seq.sort()
- assert seq == [1, 2, 3, 4, 5]
-
- The *only value* that unittest adds here is in the 'assertEqual'
- statement, which (I think) returns a
On Wed, Jul 16, 2008 at 2:03 PM, Raymond Hettinger [EMAIL PROTECTED] wrote:
If some people want to proceed down the path of useful additions,
I challenge them to think bigger. Give me some test methods that
improve my life. Don't give me thirty ways to spell something I can
already do.
Guido van Rossum [EMAIL PROTECTED] writes:
Having skimmed much material about proposed changes to the venerable
unitest module, I'd like to set some boundaries. PEPs that don't
follow the following rules are very unlikely to be accepted.
Thanks for giving the attention to this topic and
On Wed, Jul 16, 2008 at 3:52 PM, Ben Finney [EMAIL PROTECTED] wrote:
For my part, I wanted the redundancies removed and the PEP 8
conformance fixed as a precondition too *any* addition to the unittest
API.
That seems an unproductive attitude towards backwards incompatibility.
I'm glad you see
Guido van Rossum wrote:
On Wed, Jul 16, 2008 at 2:03 PM, Raymond Hettinger [EMAIL PROTECTED] wrote:
From: Michael Foord [EMAIL PROTECTED]
assertIn / assertNotIn I use very regularly for collection membership
- self.assert_(func(x) in result_set)
+ self.assertIn(func(x), result_set)
Yawn.
Michael Foord wrote:
Raymond Hettinger wrote:
[...]
If some people want to proceed down the path of useful additions,
I challenge them to think bigger. Give me some test methods that
improve my life. Don't give me thirty ways to spell something I can
already do.
I assert that... the
Andrew Bennetts [EMAIL PROTECTED] writes:
This one is easily solved by making assertRaises return the
exception it caught.
That breaks one simple feature of the unittest API: that all the test
methods will either raise a failure asertion, or return None.
--
\ “In case you haven't
Ben Finney wrote:
Andrew Bennetts [EMAIL PROTECTED] writes:
This one is easily solved by making assertRaises return the
exception it caught.
That breaks one simple feature of the unittest API: that all the test
methods will either raise a failure asertion, or return None.
How is
Andrew Bennetts [EMAIL PROTECTED] writes:
Ben Finney wrote:
Andrew Bennetts [EMAIL PROTECTED] writes:
This one is easily solved by making assertRaises return the
exception it caught.
That breaks one simple feature of the unittest API: that all the
test methods will either raise
Ben Finney wrote:
Andrew Bennetts [EMAIL PROTECTED] writes:
[...]
How is returning None a feature?
A test method having exactly one meaning is a feature. If it's
consistent across the API, the API retains a level of simplicity.
Your reply makes no sense to me.
I am proposing that it
On Jul 16, 2008, at 9:45 PM, Andrew Bennetts wrote:
I am proposing that it should have exactly one meaning. Callers
will be free to
ignore the return value if they don't need it, and will see zero
difference in
behaviour.
Sounds like adding a new method, catchException(...), that returns
I'd quote “Practicality beats purity”, but I'm not even sure if it
is purity that you have in mind.
From: Ben Finney [EMAIL PROTECTED]
Close: I'm interested in keeping camel's noses out of tents.
I have no idea what you mean or are trying to accomplish
(unless the camel's nose refers to
Andrew Bennetts [EMAIL PROTECTED] writes:
Ben Finney wrote:
Andrew Bennetts [EMAIL PROTECTED] writes:
[...]
How is returning None a feature?
A test method having exactly one meaning is a feature. If it's
consistent across the API, the API retains a level of simplicity.
Your reply
Ben Finney wrote:
Michael Foord [EMAIL PROTECTED] writes:
Collecting testcases from the filesystem is a pain. But actually
writing tests (including custom TestCases) using the unittest API is
fine. I find unittest straightforward and readable, I like it.
I don't understand a lot of the
Ben Finney wrote:
[...]
I hope that clarifies it. The name of a thing, in Python especially,
is very important; in an API, even more so. If the behaviour of the
function isn't matched by the name, it's a poorly chosen name, a
poorly designed function, or both.
It doesn't really clarify it
Steve Holden [EMAIL PROTECTED] writes:
Yes, but unless I misunderstand you, you don't regard a mass
renaming of the module's functionality and removal of existing
aliases as a change to the API.
You slightly misunderstand me. The above changes *are* a change to the
API, by definition. My
Ben Finney [EMAIL PROTECTED] writes:
You're proposing to give assertRaises a *new* meaning, without
changing its name to assertRaisesAndReturnExceptionIfRaises.
This might be misunderstood, so I'll make it clearer.
The name assert raises has a strong (and, per Guido, deliberate)
association
Guido van Rossum [EMAIL PROTECTED] writes:
On Wed, Jul 16, 2008 at 7:42 PM, Ben Finney [EMAIL PROTECTED] wrote:
The result I'm trying to avoid by this is that of having the
externally visible behaviour of functions drift from the promise
made by their names. Either rename the function, or
Guido van Rossum wrote:
On Wed, Jul 16, 2008 at 7:42 PM, Ben Finney [EMAIL PROTECTED] wrote:
The result I'm trying to avoid by this is that of having the
externally visible behaviour of functions drift from the promise made
by their names. Either rename the function, or create a new one for
the
37 matches
Mail list logo
