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
Scott Dial <[EMAIL PROTECTED]> writes:
> I would argue to go even further:
>
> assertEqual = assert_eq
> assertAlmostEqual = assert_almost_eq
> assertNotEqual = assert_ne
> assertNotAlmostEqual = assert_almost_ne
>
> I'm not sure if there are others, but using the same abbreviations
> from opera
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
On 2008-07-16 02:20, Collin Winter wrote:
On Tue, Jul 15, 2008 at 6:58 AM, Ben Finney <[EMAIL PROTECTED]> wrote:
Significant updates include removing all reference to the
(already-resolved) new-style class issue, adding footnotes and
references, and a Rationale summary of discussion on both side
"M.-A. Lemburg" <[EMAIL PROTECTED]> writes:
> Since this is a major change in the unit test API, I'd also like
> to suggest that you use a new module name.
>
> This is both a precaution to prevent tests failing due to not having
> been upgraded and a way for old code to continue working by adding
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,
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
On 2008-07-16 10:14, Ben Finney wrote:
"M.-A. Lemburg" <[EMAIL PROTECTED]> writes:
Since this is a major change in the unit test API, I'd also like
to suggest that you use a new module name.
This is both a precaution to prevent tests failing due to not having
been upgraded and a way for old co
M.-A. Lemburg wrote:
On 2008-07-16 10:14, Ben Finney wrote:
"M.-A. Lemburg" <[EMAIL PROTECTED]> writes:
Since this is a major change in the unit test API, I'd also like
to suggest that you use a new module name.
This is both a precaution to prevent tests failing due to not having
been upgrade
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
Terry Reedy wrote:
Michael Foord wrote:
Collin Winter wrote:
Is any provision being made for a 2to3 fixer/otherwise-automated
transition for the changes you propose here?
As the deprecation is intended for 2.X and 3.X - is 2to3 fixer needed?
A fixer will only be needed when it actual
"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
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".
Brett Cannon wrote:
On Tue, Jul 15, 2008 at 7:05 PM, Ben Finney <[EMAIL PROTECTED]> wrote:
Scott Dial <[EMAIL PROTECTED]> writes:
Why [introduce redundant test names]?
assert_not_less_than = assert_greater_than_or_equal
assert_not_greater_than = assert_less_than_or_equal
assert_not_le
On 2008-07-16 14:02, Michael Foord wrote:
M.-A. Lemburg wrote:
On 2008-07-16 10:14, Ben Finney wrote:
"M.-A. Lemburg" <[EMAIL PROTECTED]> writes:
Since this is a major change in the unit test API, I'd also like
to suggest that you use a new module name.
This is both a precaution to prevent t
"M.-A. Lemburg" <[EMAIL PROTECTED]> writes:
> The PEP doesn't mention changing the module name and deprecating
> the old one.
Right. The intention is to have a PEP-8-conformant 'unittest' module,
not an entirely new module.
> Instead it wants to deprecate all the old names (and cites PEP 4 for
>
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
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
Ben Finney wrote:
...
def assert_compare_true(op, first, second, msg=None):
if msg is None:
msg = "%(first)r %(op)r %(second)" % vars()
if not op(first, second):
raise self.failure_exception(msg)
I would rather something more like
"M.-A. Lemburg" <[EMAIL PROTECTED]> writes:
> On 2008-07-16 14:02, Michael Foord wrote:
> > M.-A. Lemburg wrote:
> >> Note that PEP 4 targets deprecating use of whole modules, not
> >> single APIs, or - like in your case - more or less the complete
> >> existing API of a module.
> >
> > Which PEP
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Jul 15, 2008, at 8:32 AM, Barry Warsaw wrote:
If there is anything you need a decision on, please follow up to
this thread. I'm inundated with email so I can't watch every thread
on the mailing lists. Or ping me on #python-dev.
I'm not cur
Michael Foord <[EMAIL PROTECTED]> writes:
> I'm inclined to agree. It was part of a set of additions suggested
> by Guido. From here I think (as part of the unittest extensions that
> google maintains):
>
> http://mail.python.org/pipermail/python-dev/2008-April/078702.html
>
> I've used tests li
Scott David Daniels <[EMAIL PROTECTED]> writes:
> I would rather something more like:
>
> def assert_compare_true(op, first, second, msg=None):
> if op(first, second):
> return
> raise self.failure_exception(msg)
> if msg is None:
>
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
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 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
Ben Finney wrote:
Do you perhaps mean something like this::
def assert_compare_true(op, first, second, msg=None):
fail_detail = "%(first)r %(op)r %(second)r" % vars()
if msg is None:
msg = fail_detail
else:
msg = "%(fail_detail)s: %(msg)s" % va
Does anyone know why 'F' is the same as 'f'? Wouldn't it make more
sense to either drop it, or make it convert the exponent to upper case
(like 'E' and 'G')? Compatibility with %-formatting is the only reason
I can think of to keep up, but I get the sense we've given up on an
automatic conver
On Wed, Jul 16, 2008 at 3:35 PM, Eric Smith
<[EMAIL PROTECTED]> wrote:
> Does anyone know why 'F' is the same as 'f'? Wouldn't it make more sense to
> either drop it, or make it convert the exponent to upper case
What exponent? Isn't the point of 'f' formatting that there is no exponent?
In C,
On Wed, Jul 16, 2008 at 10:07 AM, Mark Dickinson <[EMAIL PROTECTED]> wrote:
> On Wed, Jul 16, 2008 at 3:35 PM, Eric Smith
> <[EMAIL PROTECTED]> wrote:
>> Does anyone know why 'F' is the same as 'f'? Wouldn't it make more sense to
>> either drop it, or make it convert the exponent to upper case
>
>
On Tue, Jul 15, 2008 at 6:03 PM, Michael Foord
<[EMAIL PROTECTED]> wrote:
> Collin Winter wrote:
>>
>> On Tue, Jul 15, 2008 at 6:58 AM, Ben Finney <[EMAIL PROTECTED]>
>> wrote:
>>>
>>> Backwards Compatibility
>>> ===
>>>
>>> The names to be obsoleted should be deprecated and rem
Mark Dickinson wrote:
On Wed, Jul 16, 2008 at 3:35 PM, Eric Smith
<[EMAIL PROTECTED]> wrote:
Does anyone know why 'F' is the same as 'f'? Wouldn't it make more sense to
either drop it, or make it convert the exponent to upper case
What exponent? Isn't the point of 'f' formatting that there i
On Wed, Jul 16, 2008 at 5:21 AM, Michael Foord
<[EMAIL PROTECTED]> wrote:
> Terry Reedy wrote:
>>
>>
>> Michael Foord wrote:
>>>
>>> Collin Winter wrote:
>>
Is any provision being made for a 2to3 fixer/otherwise-automated
transition for the changes you propose here?
>>>
>>> As the de
On Wed, Jul 16, 2008 at 4:14 PM, Daniel Stutzbach
<[EMAIL PROTECTED]> wrote:
> There's no exponent for small-magnitude numbers, but still an exponent
> for large-magnitude numbers:
>
'%f' % (10**100)
> '1e+100'
So there is! Thanks for the correction.
Mark
___
On Wed, Jul 16, 2008 at 4:15 PM, Eric Smith
<[EMAIL PROTECTED]> wrote:
> There's no exponent until the number gets large. I haven't looked up how
> big the number has to get. On my Mac, it's somewhere between 1e50 and 1e60.
I think it's around 1e50, courtesy of the rather oddly-phrased line in
u
On 2008-07-16 15:12, Ben Finney wrote:
"M.-A. Lemburg" <[EMAIL PROTECTED]> writes:
On 2008-07-16 14:02, Michael Foord wrote:
M.-A. Lemburg wrote:
Note that PEP 4 targets deprecating use of whole modules, not
single APIs, or - like in your case - more or less the complete
existing API of a mod
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
On Tue, Jul 15, 2008 at 11:50 PM, engelbert gruber
<[EMAIL PROTECTED]> wrote:
> I see mostly ``dict.has_key() not supported in 3.x;`` and sometimes
> ``DeprecationWarning: callable() not supported in 3.x;`` .
Good catch, Engelbert.
But why would has_key() need a warning when 2to3 will fix it just
On Wed, Jul 16, 2008 at 7:35 AM, Eric Smith
<[EMAIL PROTECTED]> wrote:
> Does anyone know why 'F' is the same as 'f'? Wouldn't it make more sense to
> either drop it, or make it convert the exponent to upper case (like 'E' and
> 'G')? Compatibility with %-formatting is the only reason I can think
Guido van Rossum wrote:
On Wed, Jul 16, 2008 at 7:35 AM, Eric Smith
<[EMAIL PROTECTED]> wrote:
Does anyone know why 'F' is the same as 'f'? Wouldn't it make more sense to
either drop it, or make it convert the exponent to upper case (like 'E' and
'G')? Compatibility with %-formatting is the on
On Wed, Jul 16, 2008 at 10:30 AM, Eric Smith
<[EMAIL PROTECTED]> wrote:
> Guido van Rossum wrote:
>>
>> On Wed, Jul 16, 2008 at 7:35 AM, Eric Smith
>> <[EMAIL PROTECTED]> wrote:
>>>
>>> Does anyone know why 'F' is the same as 'f'? Wouldn't it make more sense
>>> to
>>> either drop it, or make it c
On Wed, Jul 16, 2008 at 7:02 PM, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> On Tue, Jul 15, 2008 at 11:50 PM, engelbert gruber
> <[EMAIL PROTECTED]> wrote:
>> I see mostly ``dict.has_key() not supported in 3.x;`` and sometimes
>> ``DeprecationWarning: callable() not supported in 3.x;`` .
>
> Go
[Guido]
> My best guess as to why 'F' is the same as 'f' is that somebody
> (could've been me :-) thought, like several others in this thread,
> that %f never prints an exponent. I agree that making it emit an 'E'
> when an exponent is used is the right thing to do. Do it now!
The C standard doesn
Guido van Rossum wrote:
It shares code with %-formatting. Change that, too? I couldn't find any
occurrences of %F in the stdlib. Not that that's the entire universe, of
course.
The change is slightly less elegant if I don't change %-formatting, but
still doable, especially if the betas don't
-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
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
M.-A. Lemburg wrote:
> On 2008-07-16 02:20, Collin Winter wrote:
>> On Tue, Jul 15, 2008 at 6:58 AM, Ben Finney <[EMAIL PROTECTED]> wrote:
>>> Significant updates include removing all reference to the
>>> (already-resolved) new-style class issue, addin
Tres Seaver wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
M.-A. Lemburg wrote:
On 2008-07-16 02:20, Collin Winter wrote:
On Tue, Jul 15, 2008 at 6:58 AM, Ben Finney <[EMAIL PROTECTED]> wrote:
Significant updates include removing all reference to the
(already-resolved) ne
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, discus
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
notwithstand
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
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 g
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
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 mod
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 propos
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 n
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
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
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
C. Titus Brown wrote:
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
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__ == '__ma
Currently, most mutating bytearray methods only accept integers
as items (in 3k, in 2.6 they also accept single-char strings, for
a reason I can't remember).
Single-index assignment accepts anything compatible with
operator.index(). This should be made consistent, but in which
direction?
Georg
On Wed, Jul 16, 2008 at 2:48 PM, Georg Brandl <[EMAIL PROTECTED]> wrote:
> Currently, most mutating bytearray methods only accept integers
> as items (in 3k, in 2.6 they also accept single-char strings, for
> a reason I can't remember).
>
> Single-index assignment accepts anything compatible with
>
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 variables
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
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
>>> al
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
"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
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 criticism comes
Significant changes: now targets only Python 3.1, and recording the
new status (and rationale) as rejected by BDFL pronouncement.
Feel free to mine for ideas.
:PEP: XXX
:Title: Consolidating names in the `unittest` module
:Version: 0.4
:Last-Modified: 2008
Significant changes: targeting Python 3.1, removal of separate
{lt,gt,le,ge} comparison tests, implementation of enhanced-information
failure message, reference to BDFL pronouncement.
I won't be working on this further; someone else should feel free to
champion this further if they wish.
:PEP:
Guido van Rossum schrieb:
On Wed, Jul 16, 2008 at 2:48 PM, Georg Brandl <[EMAIL PROTECTED]> wrote:
Currently, most mutating bytearray methods only accept integers
as items (in 3k, in 2.6 they also accept single-char strings, for
a reason I can't remember).
Single-index assignment accepts anythi
Ben Finney schrieb:
Significant changes: targeting Python 3.1, removal of separate
{lt,gt,le,ge} comparison tests, implementation of enhanced-information
failure message, reference to BDFL pronouncement.
I won't be working on this further; someone else should feel free to
champion this further i
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
On Wed, Jul 16, 2008 at 4:20 PM, Georg Brandl <[EMAIL PROTECTED]> wrote:
> Guido van Rossum schrieb:
>>
>> On Wed, Jul 16, 2008 at 2:48 PM, Georg Brandl <[EMAIL PROTECTED]> wrote:
>>>
>>> Currently, most mutating bytearray methods only accept integers
>>> as items (in 3k, in 2.6 they also accept si
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
Recently, I have submitted a number of defects (user krisvale)
I do have checkin privileges but since I have been lurking for so long, I
didn't want to actualhange anything.
Is this the way to proceed? I notic e that a couple of the defects (3367,
3368, 3369) have received attention and are pres
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
Hi Kristjan,
You are doing the right thing. In general, we prefer to have changes
reviewed by a senior committer first. Unfortunately, there is no
guarantee that bugs will get the attention they deserve, since the
senior developers are all pretty busy. Sending email to python-dev is
good, although
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
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
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 metho
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 i
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 c
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 simplicit
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 criti
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
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)
asso
Mark Dickinson wrote:
On Wed, Jul 16, 2008 at 4:15 PM, Eric Smith
<[EMAIL PROTECTED]> wrote:
There's no exponent until the number gets large. I haven't looked up how
big the number has to get. On my Mac, it's somewhere between 1e50 and 1e60.
I think it's around 1e50, courtesy of the rather o
On Wed, Jul 16, 2008 at 7:52 PM, Eric Smith
<[EMAIL PROTECTED]> wrote:
> Mark Dickinson wrote:
>>
>> On Wed, Jul 16, 2008 at 4:15 PM, Eric Smith
>> <[EMAIL PROTECTED]> wrote:
>>>
>>> There's no exponent until the number gets large. I haven't looked up how
>>> big the number has to get. On my Mac,
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 new functionality
"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 f
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
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
We have green buildbots, yay! Thanks everyone for that.
However, we still have three release blocker issues that I am not
comfortable deferring.
3088 test_multiprocessing hangs intermittently on POSIX platforms
3375 _multiprocessing.so build pro
Ben Finney wrote:
Scott David Daniels <[EMAIL PROTECTED]> writes:>
I would rather something more like:
def assert_compare_true(op, first, second, msg=None):
if op(first, second):
return
raise self.failure_exception(msg)
if msg is None:
"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
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
th
On Wed, 16 Jul 2008, engelbert gruber wrote:
On Wed, Jul 16, 2008 at 7:02 PM, Guido van Rossum <[EMAIL PROTECTED]> wrote:
On Tue, Jul 15, 2008 at 11:50 PM, engelbert gruber
<[EMAIL PROTECTED]> wrote:
I see mostly ``dict.has_key() not supported in 3.x;`` and sometimes
``DeprecationWarning: cal
100 matches
Mail list logo
