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' modu
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 who
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
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 w
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 re
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.
>
> I
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 na
Ben Finney 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 negativ
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".
"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
Ben Finney 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
given def
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,
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
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)
> ch
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).
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 metho
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 meanin
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
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. Th
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 p
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
> 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
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 readabi
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 cons
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 intu
"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
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 k
"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 simi
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.
_
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: 13
-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 w
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 c
Benjamin Peterson wrote:
On Mon, Jul 14, 2008 at 6:18 PM, Ben Finney <[EMAIL PROTECTED]> wrote:
"Benjamin Peterson" <[EMAIL PROTECTED]> writes:
On Mon, Jul 14, 2008 at 8:25 AM, Ben Finney <[EMAIL PROTECTED]> wrote:
Use new-style classes throughout
The follo
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
http://mail.python.org/mailman/listinf
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?
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').
Disc
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 in
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 b
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
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;
>
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
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 alrea
Ben Finney wrote:
self.fail_if_almost_equal('were already on the 34th column before'
'writing anything substantive',
self.testedobject.tested_method(arg1, arg2 +
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
-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
"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
"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 w
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 P
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
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 prefe
Michael Foord wrote:
Benjamin Peterson wrote:
On Mon, Jul 14, 2008 at 6:18 PM, Ben Finney
<[EMAIL PROTECTED]> wrote:
"Benjamin Peterson" <[EMAIL PROTECTED]> writes:
On Mon, Jul 14, 2008 at 8:25 AM, Ben Finney
<[EMAIL PROTECTED]> wrote:
Use new-style classes throughout
---
Michael Foord wrote:
Benjamin Peterson wrote:
On Mon, Jul 14, 2008 at 6:18 PM, Ben Finney
<[EMAIL PROTECTED]> wrote:
"Benjamin Peterson" <[EMAIL PROTECTED]> writes:
On Mon, Jul 14, 2008 at 8:25 AM, Ben Finney
<[EMAIL PROTECTED]> wrote:
Use new-style classes throughout
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 ne
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
_
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 spell
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 ne
``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 not
Benjamin Peterson wrote:
On Mon, Jul 14, 2008 at 6:18 PM, Ben Finney <[EMAIL PROTECTED]> wrote:
"Benjamin Peterson" <[EMAIL PROTECTED]> writes:
On Mon, Jul 14, 2008 at 8:25 AM, Ben Finney <[EMAIL PROTECTED]> wrote:
Use new-style classes throughout
--
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.
>
> * ``TestResul
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
:V
On Mon, Jul 14, 2008 at 6:18 PM, Ben Finney <[EMAIL PROTECTED]> wrote:
> "Benjamin Peterson" <[EMAIL PROTECTED]> writes:
>
>> On Mon, Jul 14, 2008 at 8:25 AM, Ben Finney <[EMAIL PROTECTED]> wrote:
>> > Use new-style classes throughout
>> >
>> >
>> > The following cl
"Benjamin Peterson" <[EMAIL PROTECTED]> writes:
> On Mon, Jul 14, 2008 at 8:25 AM, Ben Finney <[EMAIL PROTECTED]> wrote:
> > Use new-style classes throughout
> >
> >
> > The following classes will inherit explicitly from the built-in
> > `object` type, to make all
Ben Finney benfinney.id.au> writes:
> The following attribute names exist only as synonyms for other names.
> They are to be removed, leaving only one name for each attribute in
> the API.
Just for information, here is the current distribution of the two synonym kinds:
(on py3k)
$ grep "self.ass
Ben Finney wrote:
[snip..]
Remove redundant names
--
The following attribute names exist only as synonyms for other names.
They are to be removed, leaving only one name for each attribute in
the API.
``TestCase`` attributes
~~~
* ``assertEqual``
* ``ass
On Mon, Jul 14, 2008 at 8:25 AM, Ben Finney <[EMAIL PROTECTED]> wrote:
> Use new-style classes throughout
>
>
> The following classes will inherit explicitly from the built-in
> `object` type, to make all classes in the module part of the new-style
> type hierarchy.
:PEP: XXX
:Title: Consolidating names and classes in the `unittest` module
:Version: 0.0
:Last-Modified: 2008-07-14
:Author:Ben Finney <[EMAIL PROTECTED]>
:Status:Draft
:Type: Standards Track
:Content-Type: test/x-rst
:Created: 2008-07-14
:Pos
65 matches
Mail list logo
