Ben Finney wrote:
Stephen J. Turnbull [EMAIL PROTECTED] writes:
Terry Reedy writes:
For the community as a whole, all stdlib modules are suggestions
and examples, not commands.
Well, even if standard is too strong a word, the DeprecationWarnings
and eventual removal of the methods
Nick Coghlan [EMAIL PROTECTED] writes:
What did you think of the check idea at the end of the email?
Test assertions:
check(x).almost_equal(y)
check(x).is_(y)
check(x).in_(y)
check(x).equals(y)
Test negative assertions:
check(x).not_almost_equal(y)
check(x).is_not(y)
Nick Coghlan wrote:
[...]
What did you think of the check idea at the end of the email?
Test assertions:
check(x).almost_equal(y)
check(x).is_(y)
check(x).in_(y)
check(x).equals(y)
Test negative assertions:
check(x).not_almost_equal(y)
check(x).is_not(y)
Andrew Bennetts [EMAIL PROTECTED] writes:
This is a textbook example of a bikeshed discussion. The names (and
now syntax!) of assertions are the most cosmetic issue there is with
the unittest module, yet I see over *200* messages about it.
I've found it much more insightful than you seem to.
Ben Finney writes:
This fail is a negative word has already been rebutted, by native
speakers of English.
Not successfully, it hasn't. Steven d'Aprano describes one style of
testing as the test passes if it fails to fail in each of a sequence
of cases. That is perfectly good English, which
Ben Finney ben+python at benfinney.id.au writes:
This fail is a negative word has already been rebutted, by native
speakers of English.
Well, Stephen's and Greg's own answers notwithstanding, if you really want an
authoritative answer, the best would be to open a dictionary and contrast the
Stephen J. Turnbull [EMAIL PROTECTED] writes:
The intuition that fail is a negative word is thus well-founded in
standard usage.
That's not the same thing as fail being a negative word in the sense
meant by double negative.
That is, not fail is not a double negative; nor is fail if X is not
Antoine Pitrou [EMAIL PROTECTED] writes:
* http://www.thefreedictionary.com/fail
To prove deficient or lacking; perform ineffectively or inadequately; To be
unsuccessful
Yes. It's a verb, not a negative modifer. To use it with a negative
like not is not creating a double negative.
--
\
Ben Finney ben+python at benfinney.id.au writes:
* http://www.thefreedictionary.com/fail
To prove deficient or lacking; perform ineffectively or inadequately; To be
unsuccessful
Yes. It's a verb, not a negative modifer. To use it with a negative
like not is not creating a double
On Tue, Jul 15 2008 at 07:38:59PM BRT, Ben Finney [EMAIL PROTECTED] wrote:
Tres Seaver [EMAIL PROTECTED] writes:
I would keep both by preference, rather than insist on a foolish
consistency.
+1
The consistency argument leads to the PEP 8 names. The removal of
redundant names is not made
Rodrigo Bernardo Pimentel [EMAIL PROTECTED] writes:
On Tue, Jul 15 2008 at 07:38:59PM BRT, Ben Finney [EMAIL PROTECTED] wrote:
The consistency argument leads to the PEP 8 names. The removal
of redundant names is not made in the name of consistency, but of
API simplicity.
Isn't this
On Wed, Jul 16 2008 at 10:54:26AM BRT, Ben Finney [EMAIL PROTECTED] wrote:
Rodrigo Bernardo Pimentel [EMAIL PROTECTED] writes:
On Tue, Jul 15 2008 at 07:38:59PM BRT, Ben Finney [EMAIL PROTECTED] wrote:
The consistency argument leads to the PEP 8 names. The removal
of redundant names is
Ben Finney writes:
Stephen J. Turnbull [EMAIL PROTECTED] writes:
The intuition that fail is a negative word is thus well-founded in
standard usage.
That's not the same thing as fail being a negative word in the sense
meant by double negative.
So what? This whole exercise is
Tres Seaver wrote:
-BEGIN PGP SIGNED MESSAGE-
If camelCase / duplicated names are such a pain, write a *new* module,
'unittest2', and port Python's tests to use it, thereby leaving the much
larger volume of not-in-Python tests still working. One might then
remove the 'unittest'
Raymond Hettinger wrote:
``set_up(…)``
Replaces ``setUp(…)``
. .
``tear_down(…)``
Replaces ``tearDown(…)``
Am I the only one who finds this sort of excessive pep-8 underscoring to
be horrorific?
Definitely not. I thin we are in danger of insisting on a foolish
consistency. I'd far
Raymond Hettinger writes:
Nobody I know spells setup and teardown as two words.
I set up a house of cards. When I'm done, I'm done with setup.
Similarly for tear down and teardown. The two word forms are
verbs, the one word forms are nouns. I don't think it's worth a
column to make that
Ben Finney writes:
Removal of ``assert*`` names
There is no overwhelming consensus on whether to remove the
``assert*`` names or the ``fail*`` names;
7 to 1 is overwhelming in my book. See
Message-ID: [EMAIL PROTECTED]
From: Antoine Pitrou [EMAIL
Raymond Hettinger [EMAIL PROTECTED] writes:
``set_up(…)``
Replaces ``setUp(…)``
. .
``tear_down(…)``
Replaces ``tearDown(…)``
Am I the only one who finds this sort of excessive pep-8
underscoring to be horrorific?
Nobody I know spells setup and teardown as two words.
I spell
Stephen J. Turnbull [EMAIL PROTECTED] writes:
Ben Finney writes:
Removal of ``assert*`` names
There is no overwhelming consensus on whether to remove the
``assert*`` names or the ``fail*`` names;
7 to 1 is overwhelming in my book. See
-On [20080715 12:35], Ben Finney ([EMAIL PROTECTED]) wrote:
That measured only usage of unittest *within the Python standard
library*. Is that the only body of unittest-using code we need
consider?
Some greps on random Python projects give me a 4-10:1 ratio for assert*
versus fail*.
Personally I
On 15/07/2008, Raymond Hettinger [EMAIL PROTECTED] wrote:
``set_up(…)``
Replaces ``setUp(…)``
. .
``tear_down(…)``
Replaces ``tearDown(…)``
Am I the only one who finds this sort of excessive pep-8 underscoring to be
horrorific?
No.
Nobody I know spells setup and teardown as
Ben Finney wrote:
self.fail_if_almost_equal('were already on the 34th column before'
'writing anything substantive',
self.testedobject.tested_method(arg1, arg2 +
Ben Finney writes:
Message-ID: [EMAIL PROTECTED]
From: Antoine Pitrou [EMAIL PROTECTED]
That measured only usage of unittest *within the Python standard
library*. Is that the only body of unittest-using code we need
consider?
Yes, for the purposes of this PEP. We already know
Nick Coghlan [EMAIL PROTECTED] writes:
fail_if_almost_equal is an undesirably long method name.
I disagree. It says what the method does, as precisely as necessary to
distinguish it from other methods of the class. It is as long as it
needs to be to say that while still being readable and PEP 8
Ben Finney wrote:
Stephen J. Turnbull [EMAIL PROTECTED] writes:
Ben Finney writes:
Removal of ``assert*`` names
There is no overwhelming consensus on whether to remove the
``assert*`` names or the ``fail*`` names;
7 to 1 is
Andrew Bennetts [EMAIL PROTECTED] writes:
Ben Finney wrote:
Stephen J. Turnbull [EMAIL PROTECTED] writes:
Message-ID: [EMAIL PROTECTED]
From: Antoine Pitrou [EMAIL PROTECTED]
That measured only usage of unittest *within the Python standard
library*. Is that the only body of
On Tue, 15 Jul 2008 08:54:25 pm Jeroen Ruigrok van der Werven wrote:
Some greps on random Python projects give me a 4-10:1 ratio for
assert* versus fail*.
Without knowing what those random projects are, or what the grep was,
it's impossible to interpret that statistic. For example, is it
On Tue, Jul 15, 2008 at 2:48 PM, Ben Finney [EMAIL PROTECTED] wrote:
So far I have precedent and tradition and positive admonition looks
better in support of preferring the 'assert*' names. Are there any
others?
I've been told by a couple of non-programmers that failUnless is
more intuitive
Nick Coghlan wrote:
One option for rationalising the API would be to merely keep the
shortest version of each phrase (i.e. use assert* instead of
fail_unless* for the positive tests and fail_if* instead of
assert_not* for the negative tests, and always drop the trailing 's'
from 'equals').
On Tue, Jul 15, 2008 at 03:00:30PM +0100, Richard Thomas wrote:
- On Tue, Jul 15, 2008 at 2:48 PM, Ben Finney [EMAIL PROTECTED] wrote:
- So far I have precedent and tradition and positive admonition looks
- better in support of preferring the 'assert*' names. Are there any
- others?
-
- I've
Nick Coghlan [EMAIL PROTECTED] writes:
While true, that doesn't change the fact that fail_if_almost_equal is
an undesirably long method name.
fail_if_near ?
___
Python-Dev mailing list
Python-Dev@python.org
Stephen J. Turnbull wrote:
Yes, for the purposes of this PEP. We already know that many people
want various different things. You want fail* /rather than/ assert*,
but Steven d'Aprono wants /both/, and I prefer assert* /exclusively/.
I don't see why we all shouldn't be satisfied[1], so the
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Andrew Bennetts wrote:
Ben Finney wrote:
Stephen J. Turnbull [EMAIL PROTECTED] writes:
Ben Finney writes:
Removal of ``assert*`` names
There is no overwhelming consensus on whether to remove the
On 15-Jul-08, at 6:05 AM, Andrew Bennetts wrote:
Ben Finney wrote:
Stephen J. Turnbull [EMAIL PROTECTED] writes:
That measured only usage of unittest *within the Python standard
library*. Is that the only body of unittest-using code we need
consider?
Three more data points then:
bzr: 13228
Terry Reedy writes:
For the community as a whole, all stdlib modules are suggestions and
examples, not commands.
Well, even if standard is too strong a word, the DeprecationWarnings
and eventual removal of the methods surely constitute an imposition.
C. Titus Brown [EMAIL PROTECTED] writes:
On Tue, Jul 15, 2008 at 03:00:30PM +0100, Richard Thomas wrote:
- I've been told by a couple of non-programmers that failUnless
- is more intuitive than assert if only for the reason that its
- unclear what assert might do. This is similar to one of
On Tue, Jul 15, 2008 at 3:34 PM, Ben Finney [EMAIL PROTECTED] wrote:
That's exactly the problem with the 'assert*' names: The test methods
of TestCase *don't* do the same thing as the Python 'assert'
statement, and aren't meant to. The association is confusing, even
(especially?) if one knows
Stephen J. Turnbull [EMAIL PROTECTED] writes:
Terry Reedy writes:
For the community as a whole, all stdlib modules are suggestions
and examples, not commands.
Well, even if standard is too strong a word, the DeprecationWarnings
and eventual removal of the methods surely constitute an
Nick Coghlan [EMAIL PROTECTED] writes:
A somewhat odd thought that occurred to me is that the shortest
possible way of writing negative assertions (i.e. asserting that
something is not the case) is to treat them as denials and use the
single word 'deny'.
-1
This, to me, is neither intuitive
Tres Seaver [EMAIL PROTECTED] writes:
FWIW: Zope2: 16878 'assert*', 2892 'fail*'.
Thanks.
I would keep both by preference, rather than insist on a foolish
consistency.
The consistency argument leads to the PEP 8 names. The removal of
redundant names is not made in the name of consistency,
Jonathan Lange wrote:
My name's Jonathan, and I spell set up as set up and tear down
as tear down.
In English, it depends on how they're being used. As
nouns they're single words, as verbs they're two
words.
As function names, they could be read either way, so
it comes down to readability.
So far I have precedent and tradition and positive admonition looks
better in support of preferring the 'assert*' names. Are there any
others?
Avoiding double negatives.
(and don't tell me fail is not a negative word, because you just used
the phrase positive admonition to refer to the
Ben Finney wrote:
Nick Coghlan [EMAIL PROTECTED] writes:
One option for rationalising the API would be to merely keep the
shortest version of each phrase (i.e. use assert* instead of
fail_unless* for the positive tests and fail_if* instead of
assert_not* for the negative tests, and always drop
Richard Thomas wrote:
I've been told by a couple of non-programmers that failUnless is
more intuitive than assert if only for the reason that its unclear
what assert might do.
But test frameworks are for use by programmers, not
non-programmers. Given that it's a test framework, would
a
Ben Finney wrote:
Nick Coghlan [EMAIL PROTECTED] writes:
the shortest
possible way of writing negative assertions (i.e. asserting that
something is not the case) is to treat them as denials and use the
single word 'deny'.
This, to me, is neither intuitive nor meaningful in context. The
Antoine Pitrou [EMAIL PROTECTED] writes:
(and don't tell me fail is not a negative word, because you just
used the phrase positive admonition to refer to the assert*
variants, which implies quite clearly that the fail* variants are on
the negative side ;-))
This fail is a negative word has
Greg Ewing wrote:
Ben Finney wrote:
Nick Coghlan [EMAIL PROTECTED] writes:
the shortest
possible way of writing negative assertions (i.e. asserting that
something is not the case) is to treat them as denials and use the
single word 'deny'.
This, to me, is neither intuitive nor meaningful
Significant updates are to the preamble (Python-Version field), the
sections Use new-style classes throughout, Module attributes, and
a new Rationale section Removal of ``assert*`` names.
:PEP: XXX
:Title: Consolidating names and classes in the `unittest` module
On Mon, Jul 14, 2008 at 6:42 PM, Ben Finney [EMAIL PROTECTED] wrote:
Specification
=
Use new-style classes throughout
The following classes are currently implemented as classic
(old-style) classes, with no metaclass.
* ``TestResult``
*
``set_up(…)``
Replaces ``setUp(…)``
. .
``tear_down(…)``
Replaces ``tearDown(…)``
Am I the only one who finds this sort of excessive pep-8 underscoring to be
horrorific?
Nobody I know spells setup and teardown as two words. I dread using the module with these new names. Underscores are
Raymond Hettinger wrote:
``set_up(…)``
Replaces ``setUp(…)``
. .
``tear_down(…)``
Replaces ``tearDown(…)``
Am I the only one who finds this sort of excessive pep-8 underscoring
to be horrorific?
Nobody I know spells setup and teardown as two words. I dread using
the module with these
On Tue, Jul 15, 2008 at 12:06 PM, Raymond Hettinger [EMAIL PROTECTED] wrote:
``set_up(…)``
Replaces ``setUp(…)``
. .
``tear_down(…)``
Replaces ``tearDown(…)``
Am I the only one who finds this sort of excessive pep-8 underscoring to be
horrorific?
Nobody I know spells setup and
It looks like Benjamin Peterson is right, in Python 2.5 TestCase already
appears to be a new style class:
Yep. I stand corrected. It looks like that changed five years ago (rev 28064). Not sure how that slipped through but it doesn't
seem to have caused any problems.
Raymond
Raymond Hettinger wrote:
``set_up(…)``
Replaces ``setUp(…)``
. .
``tear_down(…)``
Replaces ``tearDown(…)``
Am I the only one who finds this sort of excessive pep-8 underscoring to
be horrorific?
Nobody I know spells setup and teardown as two words. I dread using the
module with these
54 matches
Mail list logo
