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
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
"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
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:
-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
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
"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 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
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,
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
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
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 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
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
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
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
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
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
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:
>
> > 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:
> 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
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
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
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
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
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
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
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
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
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:
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
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
"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
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
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
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 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 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
>
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
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
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
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
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
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
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: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
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
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
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
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
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
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
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
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
-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
-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
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
[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
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
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
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 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
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
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 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
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 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 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
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 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
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 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,
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
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
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
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:
>
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
-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
"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
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
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 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
"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
>
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
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
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
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
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
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
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
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,
"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
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
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
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
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
100 matches
Mail list logo
