Ben Finney wrote:
Steve Holden <[EMAIL PROTECTED]> writes:
Michael Foord wrote:
Adding the following new asserts:
assertIn(member, container, msg=None)
assertNotIn (member, container, msg=None)
assertIs (first, second, msg=None)
assertNotIs (first, second, msg=None)
Michael Foord wrote:
Ben Finney wrote:
Howdy Michael,
I'm interested in the changes you're proposing for Python's 'unittest'
module. I am (like, I suspect, many Python coders) maintaining my own
set of extensions to the module across many projects, so I'd really
like to see many of the impro
On Mon, 2008-06-16 at 22:27 +0200, M.-A. Lemburg wrote:
> On 2008-06-15 16:47, Georg Brandl wrote:
> > Thomas Lee schrieb:
> >> Georg Brandl wrote:
> >>> Remember that it must still be possible to write (in 2.6)
> >>>
> >>> True = 0
> >>> assert not True
> >>
> >> Ah of course. Looks like I should
Martin v. Löwis wrote:
http://bugs.python.org/issue3026 comes to mind.
And I would rather use a little bit different wording: The ones
truncating size_t/ssize_t do matter, unless you know in advance that
you will always deal with data lesser than 2GiB.
I thought Nick's comment was in the cont
Nick Coghlan <[EMAIL PROTECTED]> writes:
> Ben Finney wrote:
> > The problem is, that makes it quite inconsistent with other "not"
> > uses (such as "assert_not_equal", "assert_not_in", etc.) I would
> > really prefer that all these "not" uses be gramatically consistent
> > for predictability. Is
Ben Finney wrote:
Nick Coghlan <[EMAIL PROTECTED]> writes:
Ben Finney wrote:
The problem is, that makes it quite inconsistent with other "not"
uses (such as "assert_not_equal", "assert_not_in", etc.) I would
really prefer that all these "not" uses be gramatically consistent
for predictability.
Nick Coghlan <[EMAIL PROTECTED]> writes:
> Would it be worth Ben collating your current notes into a draft PEP
> targeting 2.7/3.1?
I'll do it and we'll find out.
--
\ “A fine is a tax for doing wrong. A tax is a fine for doing |
`\ wel
Steve Holden wrote:
Ben Finney wrote:
To be clear, I take it you're in favour of the following names (with
no aliases):
assert_equalassert_not_equal
assert_is assert_is_not
assert_in assert_not_in
assert_almost_equal as
Steve Holden <[EMAIL PROTECTED]> writes:
> Ben Finney wrote:
> > and so on; i.e. that 'assert_is_not' breaks the obvious pattern
> > set by the others, in the interest of matching Python's 'is not'
> > grammar.
>
> Well, I'd have said "in the interest of reading correctly in English",
> though I
Michael Foord <[EMAIL PROTECTED]> writes:
> The full list of changes proposed (feel free to start - but ping me or
> the list) and not shot down was something like:
[…]
Thanks. I'm working these into another draft PEP that I hope to have
up in a day or two.
--
\ “[W]e are still the first g
Michael Foord <[EMAIL PROTECTED]> writes:
The full list of changes proposed (feel free to start - but ping me or
the list) and not shot down was something like:
[…]
Thanks. I'm working these into another draft PEP that I hope to have
up in a day or two.
Given all of the language changes in
Raymond Hettinger wrote:
Michael Foord <[EMAIL PROTECTED]> writes:
The full list of changes proposed (feel free to start - but ping me or
the list) and not shot down was something like:
[…]
Thanks. I'm working these into another draft PEP that I hope to have
up in a day or two.
Given all o
>> Clearly the unquote is str->bytes, You can't pass a Unicode string
>> back
>> as the result of unquote *without* passing in an encoding specifier,
>> because the character set is application-specific.
> So for unquote you're suggesting that it always return a bytes object
> UNLESS an encoding
: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
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.
Michael Foord <[EMAIL PROTECTED]> writes:
> As proposed the changes don't remove or rename anything - so there
> will be no code breakage, just additional test methods.
Right, so I'm putting up a separate PEP just for the renaming. Should
be arriving on this list soon.
> However, as we're into t
"Raymond Hettinger" <[EMAIL PROTECTED]> writes:
> Given all of the language changes in 2.6 and 3.0, I would think that
> it is dangerous to make any changes at all to the unittest API. That
> module is the one anchor in a sea of change.
Agreed. I'm not proposing to have the unittest API change at
On Mon, 14 Jul 2008 09:54:16 am Steve Holden wrote:
> > Python may be Guido's language, and if he wants to use his
> > dictatorial powers to say that tests must be written as positive
> > assertions because that's the way he likes it, that's his
> > prerogative. But let's not pretend that this part
Hi,
In case anyone is interested, I have git repositories for both the
trunk and the py3k branch of the Python source code. They are
up-to-date and so using them with git-svn would be much faster than
starting from scratch.
If anyone is interested, I will find a place to host them. They are
eac
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
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
"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
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
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 the py.test syntax. That i
On Mon, Jul 14, 2008 at 6:26 PM, Raymond Hettinger <[EMAIL PROTECTED]> wrote:.
>
> I would like to work with you or someone else who is interested
> on an alternative PEP for a separate, simpler test module
> using the py.test syntax. That is much simpler to learn and use.
> Instead of self.assert
On Mon, 14 Jul 2008 04:27:40 pm Stephen J. Turnbull wrote:
> FWIW, I meant 10 != not not 10.
>>> 10 != not not 10
File "", line 1
10 != not not 10
^
SyntaxError: invalid syntax
With respect, I think that the fact that you made an analogy with Python
code that you hadn't tested
Hi,
> I think some variant
> of py.test could be done that is compatable with unittest
> and the did not have the "magic" present in earlier versions of py.test.
It already exists:
http://www.somethingaboutorange.com/mrl/projects/nose/
Regards
Antoine.
___
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
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 t
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 t
On Tue, Jul 15, 2008 at 9:43 AM, Michael Foord
<[EMAIL PROTECTED]> wrote:
> I personally find unittest pretty readable, the feature most lacking is
> autodiscovery of tests which nose does seem to provide very well although I
> haven't used it yet.
FWIW, Twisted's 'trial' has done this since about
From: "Michael Foord" <[EMAIL PROTECTED]>
However, to provide readable output for errors in even simple tests
(like a == b) py.test does magic with stack frames and code objects - in
order to discover the objects being compared.
Don't have to go that route. Can use plain python assert failure
On Mon, Jul 14, 2008 at 6:43 PM, Michael Foord
<[EMAIL PROTECTED]> wrote:
>
> However, to provide readable output for errors in even simple tests (like a
> == b) py.test does magic with stack frames and code objects - in order to
> discover the objects being compared.
Maybe what we need to do then
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
On Mon, Jul 14, 2008 at 3:43 PM, Neil Schemenauer <[EMAIL PROTECTED]> wrote:
> Hi,
>
> In case anyone is interested, I have git repositories for both the
> trunk and the py3k branch of the Python source code. They are
> up-to-date and so using them with git-svn would be much faster than
> starting
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Jul 14, 2008, at 6:43 PM, Neil Schemenauer wrote:
In case anyone is interested, I have git repositories for both the
trunk and the py3k branch of the Python source code. They are
up-to-date and so using them with git-svn would be much faster tha
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
--
``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
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
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
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 ne
On Mon, Jul 14, 2008 at 5:13 PM, Raymond Hettinger <[EMAIL PROTECTED]> wrote:
> It takes about one day of using py.test to realize have much
> cleaner and more readable its syntax is. Also, writing the
> tests is *much* more pleasant. It has the same clean, clear
> joy as writing regular python c
Guido van Rossum wrote:
On Mon, Jul 14, 2008 at 5:13 PM, Raymond Hettinger <[EMAIL PROTECTED]> wrote:
It takes about one day of using py.test to realize have much
cleaner and more readable its syntax is. Also, writing the
tests is *much* more pleasant. It has the same clean, clear
joy as wr
From: "Michael Foord" <[EMAIL PROTECTED]>
Maybe Python needs a good mocking module in the standard library. There
are plenty, but we use a particularly nice one at Resolver Systems [1]. :-)
-1
This comes up occassionally and gets shot down.
http://bugs.python.org/issue708125
Mock objects mean
On Mon, Jul 14, 2008 at 09:37:30PM -0700, Raymond Hettinger wrote:
-> From: "Michael Foord" <[EMAIL PROTECTED]>
-> >Maybe Python needs a good mocking module in the standard library. There
-> >are plenty, but we use a particularly nice one at Resolver Systems [1]. :-)
->
-> -1
->
-> This comes up
From: "Michael Foord" <[EMAIL PROTECTED]>
Maybe Python needs a good mocking module in the standard library. There
are plenty, but we use a particularly nice one at Resolver Systems [1]. :-)
-1
This comes up occassionally and gets shot down.
http://bugs.python.org/issue708125
And: http://bug
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?
Definitely not. I thin we are in danger of insisting on a foolish
consistency. I'd far prefe
Ben Finney wrote:
> I'd count this as another (minor) point in favour of making the 'fail*'
> methods canonical: the names are consistent *and* gramatically sensible:
-1
I'm surprised nobody (that I've noticed) has brought up the point yet that
test code is a lot easier to read if it makes posit
51 matches
Mail list logo
