Re: [Python-Dev] Proposed unittest changes

[Steve Holden]

Thomas Lotze wrote:

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 positive assertions. When
reading failure conditions, one has to constantly invert them in order to
deduce the behaviour that is tested. failUnless and friends aren't better
either IMO since while they do work with positive assertions, the method
names themselves are doubly negative. assert* methods are so much more
straightforward to comprehend.


I think this is where I came in.

regards
 Steve
--
Steve Holden+1 571 484 6266   +1 800 494 3119
Holden Web LLC  http://www.holdenweb.com/

___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] unittest's redundant assertions: asserts vs. failIf/Unlesses

[Stephen J. Turnbull]

Steven D'Aprano writes:
 > 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, got it wrong, then corrected it, and 
 > *still* got it wrong, is telling.

It's telling only if you ignore the fact that it's the ad hominem fallacy.

 > When it comes to assert* versus fail* tests, this is one case where I 
 > don't believe "one obvious way to do it" should apply.

In the context you were talking about, where you don't need to show
anybody your tests, I don't see any reason why TOOWTDI should apply.
In a debugging context, I don't see any reason why it should, either.

But here we're talking about the standard unit-testing framework,
which is used by Python itself.  So it *is* about communication with
other developers, and it *does* make sense to avoid proliferation of
redundant vocabulary.  Some of us have enough trouble remembering when
parentheses are redundant, as you noticed.

Regression test suites aspire to full coverage.  If you mix assert*
and fail* clauses, you are going to need to invert one or the other to
determine whether there are cases that are missed.

IMO those are strong indications that only one of the pair should be
used in a test suite.

 > I believe that assert* and fail* tests are the same:

In logic, they are.  I just think that assert* is much more natural in
several simple cases, such as the pure regression test where you use
Python X.Y to compute foo(), and add "assertEqual(foo(), pyXYresult)"
to the test suite.  I'd be a lot more sympathetic if you'd describe
a similarly plausible and generic application for fail*.

___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP: Consolidating names and classes in the `unittest`module (updated 2008-07-15)

[Stephen J. Turnbull]

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 distinction, though.

 > Another thought is that test suite code is going to get seriously crunched 
 > when the new, longer method names meet the 78/80 column 
 > pep 8 restrictions.
 > 
 > class TestMisc(unittest.test_case):
 > def lost_four_spaces_here_already(self):

Eight spaces, actually.  Make that 13 by the time you get to the "."
after "self" in the next line.

 > Are there any ideas for some short, pithy, mnemonic names that are
 > self-explantory and not full of underscores; something that
 > wouldn't suck to type hundreds of times in a good test module?

"test" or "check" instead of "assert" or "fail_unless" comes to mind
to shorten the prefix.  But the best I can come up with for
"fail_unless_equal" is something like "equalize" which really fails
EIBTI.

___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

[Python-Dev] PEP: Consolidating names and classes in the `unittest` module (updated 2008-07-15)

[Stephen J. Turnbull]

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 PROTECTED]>

While people's preferences are important, I think there is a very good
case to made that keeping this much continuity in the test suite as
possible is more so.

 > * Explicit is better than implicit: The ``fail*`` names state *what
 >   the function will do* explicitly: fail the test. With the
 >   ``assert*`` names, the action to be taken is only implicit.

EIBTI applies with the most force to "local" names, ie, specific to a
particular function, class, or program.  Here we propose to impose a
community-wide convention.  I think we can document it explicitly and
expect near-instant uptake on the appropriate connotations to "assert"
(especially since that connotation is pretty much universal across
languages with an assert facility, anyway).

 > * Avoid false implication: The test methods do not have any necessary
 >   connection with the built-in ``assert`` statement.

Data point: Use of `Assert' as a test method in the XEmacs test suite
has never caused any confusion with either C-level asserts, or with
the Lisp function `assert'.

___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Proposed unittest changes

[Nick Coghlan]

Michael Foord wrote:

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 the py.test syntax.  That is much simpler to learn and use.
Instead of self.assertIsNot and whatnot, you write:
  assert a is not b
No need for tons of word-by-word spellings on things we already
have syntax for.  Almost anyone who has used py.test can attest
its syntax is much more natural, easy to learn, easy to both
read and write, and is much lighter weight.  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.


Ah, in my haste I skipped over your comment about "magic", my apologies. 
But in the absence of magic how do you propose to provide a meaningful 
error message from the failure of:


assert a == b

To wrap it in a function like "assert equals(a, b)" seems to gain little 
over unittest.


Aside from the question of providing nice error messages, two questions 
that immediately come to mind for me are:
- how do I run my tests with -O or -OO? (since the compiler will throw 
all the assert statements away before any Python code gets a chance to 
look at them)

- how do I test that code raises an expected exception?
- how do I explicitly fail a test case? (e.g. I'll often do this when I 
want to test an operation with a variety of different inputs - I'll test 
for all of the inputs of interest, collecting the failures in a list, 
then reporting a single error message at the end detailing all of the 
cases that failed)


And I've also never had any problem whatsoever debugging unit tests with 
print statements - one of the effects of the -v switch is to display 
anything which is written to stderr/stdout on the console again.


Cheers,
Nick.

--
Nick Coghlan   |   [EMAIL PROTECTED]   |   Brisbane, Australia
---
http://www.boredomandlaziness.org
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

[Python-Dev] Default metaclass in Python 3.0 modules (was: PEP: Consolidating names and classes in the `unittest` module (updated 2008-07-15))

[Ben Finney]

"Benjamin Peterson" <[EMAIL PROTECTED]> writes:

> On Mon, Jul 14, 2008 at 6:42 PM, Ben Finney <[EMAIL PROTECTED]> wrote:
> > The `unittest` module will gain the following attribute, to set the
> > default metaclass for classes in the module and thus make all classes
> > in the module part of the new-style type hierarchy::
> >
> >__metaclass__ = type
> 
> It's already done.
> 
> Line 94-95 in unittest.py (trunk):
> # All classes defined herein are 'new-style' classes, allowing use of 
> 'super()'
> __metaclass__ = type

Hmm, you're right; I see that in Python 2.5.2 'unittest.py'.

Why is it not there in 3.0's 'unittest.py'? Is this achieved some
other way?

-- 
 \ “Pinky, are you pondering what I'm pondering?” “I think so, |
  `\ Brain, but if they called them ‘Sad Meals’, kids wouldn't buy |
_o__)them!” —_Pinky and The Brain_ |
Ben Finney

___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Default metaclass in Python 3.0 modules

[Eric Smith]

Ben Finney wrote:

"Benjamin Peterson" <[EMAIL PROTECTED]> writes:


On Mon, Jul 14, 2008 at 6:42 PM, Ben Finney <[EMAIL PROTECTED]> wrote:

The `unittest` module will gain the following attribute, to set the
default metaclass for classes in the module and thus make all classes
in the module part of the new-style type hierarchy::

   __metaclass__ = type

It's already done.

Line 94-95 in unittest.py (trunk):
# All classes defined herein are 'new-style' classes, allowing use of 'super()'
__metaclass__ = type


Hmm, you're right; I see that in Python 2.5.2 'unittest.py'.

Why is it not there in 3.0's 'unittest.py'? Is this achieved some
other way?


In 3.0 there are only new-style classes, so nothing needs to be done there.
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP: Consolidating names and classes in the `unittest`module (updated 2008-07-15)

[Ben Finney]

"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 them as two words. The existing unittest framework also spells
them as two words, using camelCase.

> It's not going to be easy to remember where they are used (ie.
> isinstance is still isinstance but isset is now is_set). Go figure.

I don't see the connection of this sentence to the existing discussion.

> Another thought is that test suite code is going to get seriously
> crunched when the new, longer method names meet the 78/80 column pep
> 8 restrictions.
> 
> class TestMisc(unittest.test_case):
>def lost_four_spaces_here_already(self):
>self.fail_if_almost_equal('were already on the 34th column before'
>  'writing anything substantive',
>  self.testedobject.tested_method(arg1, arg2 +
>  arg3, arg4)
># Imagine typing and line wrapping dozens more tests like this

Yikes. Why are you using such huge indents? Break the line where
indents won't be so enormous.

class TestMisc(unittest.test_case):
   def lost_four_spaces_here_already(self):
   self.fail_if_almost_equal(
   'we know this is going to be long, so we indent before'
   'writing anything substantive',
   self.testedobject.tested_method(
   arg1, arg2 + arg3, arg4)

> Are there any ideas for some short, pithy, mnemonic names that are
> self-explantory and not full of underscores; something that wouldn't
> suck to type hundreds of times in a good test module?  IMO, the
> current names are already too long.

I'm very much in favour of having the namessay exactly what they're
testing. They need to be long because there are many of them doing
slightly-different things, so need careful disambiguation.

> Beautiful is better than ugly.
> Readability counts.
> 
> These are especially important for the unittest module.  When I'm
> making tests, I have to type self.very_long_method_name so many times
> it isn't funny.  It's easy to just stop writing tests when you get
> tired of it.  Long api names with underscores are a disincentive
> (IMO).

Yes, this is something that deserves consideration.

-- 
 \“Why was I with her? She reminds me of you. In fact, she |
  `\reminds me more of you than you do!” —Groucho Marx |
_o__)  |
Ben Finney

___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Default metaclass in Python 3.0 modules

[Ben Finney]

Eric Smith <[EMAIL PROTECTED]> writes:

> Ben Finney wrote:
> > "Benjamin Peterson" <[EMAIL PROTECTED]> writes:
> >> Line 94-95 in unittest.py (trunk):
> >> # All classes defined herein are 'new-style' classes, allowing use of 
> >> 'super()'
> >> __metaclass__ = type
> >
> > Hmm, you're right; I see that in Python 2.5.2 'unittest.py'.
> >
> > Why is it not there in 3.0's 'unittest.py'? Is this achieved some
> > other way?
> 
> In 3.0 there are only new-style classes, so nothing needs to be done
> there.

What makes that happen in the case where a class declares no
superclass? Is there an invisible enforced "__metaclass__ = type" for
every module? Where can I read about this change?

-- 
 \   “The apparent lesson of the Inquisition is that insistence on |
  `\ uniformity of belief is fatal to intellectual, moral, and |
_o__)spiritual health.” —_The Uses Of The Past_, Herbert J. Muller |
Ben Finney

___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP: Consolidating names and classes in the `unittest` module (updated 2008-07-15)

[Ben Finney]

"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
> 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?

> While people's preferences are important, I think there is a very
> good case to made that keeping this much continuity in the test
> suite as possible is more so.

That's a separate argument, then. One which I don't dismiss, but it
needs to be stated as such.

-- 
 \   “A poet more than thirty years old is simply an overgrown |
  `\ child.” —Henry L. Mencken |
_o__)  |
Ben Finney

___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] git repositories for trunk and py3k

[Paul Moore]

On 15/07/2008, Barry Warsaw <[EMAIL PROTECTED]> 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 than
> > starting from scratch.
> >
> > If anyone is interested, I will find a place to host them.  They are
> > each about 150 MB in size.
> >
>
> Neil, we should try to host them on code.python.org.

If we're setting up a variety of DVCS systems there, I'd be willing to
set up Mercurial repos (I have my own local one, just trunk at the
moment but py3k would be easy enough to add). I'd need access in order
to set up any sort of sync process, though.

Paul.
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP: Consolidating names and classes in the `unittest` module (updated 2008-07-15)

[Jeroen Ruigrok van der Werven]

-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 also find the assert* syntax preferable over fail*.

-- 
Jeroen Ruigrok van der Werven  / asmodai
イェルーン ラウフロック ヴァン デル ウェルヴェン
http://www.in-nomine.org/ | http://www.rangaku.org/ | GPG: 2EAC625B
If I am telling you the Truth now, do you believe it..?
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP: Consolidating names and classes in the `unittest`module (updated 2008-07-15)

[Paul Moore]

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 two words. I dread using the
> module with these new names. Underscores are not fun to type. They create a
> weird_mental_pause when reading them.

I agree. The java-esque setUp and tearDown are (in my view) ugly, but
set_up and tear_down are as bad.

+1 for setup and teardown.

+1 also for thinking a *lot* harder about naming, and not just going
with phrases_joined_up_with_underscores, or
phrasesWithNoSpacesAndFunnyCapitalisation.

There are certainly issues with the simple

assert expression

approach, but ugliness and unreadability aren't two of them.

Paul.
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP: Consolidating names and classes in the `unittest`module (updated 2008-07-15)

[Nick Coghlan]

Ben Finney wrote:

   self.fail_if_almost_equal('were already on the 34th column before'
 'writing anything substantive',
 self.testedobject.tested_method(arg1, arg2 +
 arg3, arg4)
   # Imagine typing and line wrapping dozens more tests like this


Yikes. Why are you using such huge indents? Break the line where
indents won't be so enormous.


While true, that doesn't change the fact that fail_if_almost_equal is an 
undesirably long method name.



I'm very much in favour of having the namessay exactly what they're
testing. They need to be long because there are many of them doing
slightly-different things, so need careful disambiguation.


The "almost_equal" methods for floating point comparison are the main 
culprits for excessive method length, closely followed by the 
"fail_unless" variants.


(21, 'failUnlessAlmostEqual') -> 24 with underscores
(21, 'assertNotAlmostEquals') -> 25 with underscores
(20, 'assertNotAlmostEqual')  -> 24 with underscores
(18, 'assertAlmostEquals')-> 20 with underscores
(17, 'failIfAlmostEqual') -> 20 with underscores
(17, 'assertAlmostEqual') -> 19 with underscores
(16, 'failUnlessRaises')  -> 18 with underscores
(15, 'failUnlessEqual')   -> 17 with underscores
(15, 'assertNotEquals')   -> 17 with underscores
(14, 'assertNotEqual')-> 16 with underscores
(12, 'assertRaises')  -> 13 with underscores
(12, 'assertEquals')  -> 13 with underscores
(11, 'failIfEqual')   -> 13 with underscores
(11, 'assertFalse')   -> 12 with underscores
(11, 'assertEqual')   -> 12 with underscores
(10, 'failUnless')-> 11 with underscores
(10, 'assertTrue')-> 11 with underscores
(7, 'assert_')->  7 with underscores
(6, 'failIf') ->  7 with underscores
(4, 'fail')   ->  4 with underscores

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'). 
This simple rule would eliminate 12 of the 20 methods (including the 
four longest method names and 7 of the longest 9), leaving the following 
minimal set of methods:


fail_if_almost_equal (20)
assert_almost_equal  (19)
assert_raises(13)
fail_if_equal(13)
assert_equal (12)
assert_  (7)
fail_if  (7)
fail (4)

Adding in possible positive and negative forms of the proposed new 
methods (using words more appropriate for a method rather than copying 
the infix operators):


fail_if_identical (17)
fail_if_contains  (16)
assert_identical (16)
assert_contains  (15)

Cheers,
Nick.

--
Nick Coghlan   |   [EMAIL PROTECTED]   |   Brisbane, Australia
---
http://www.boredomandlaziness.org
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Default metaclass in Python 3.0 modules

[Nick Coghlan]

Ben Finney wrote:

Eric Smith <[EMAIL PROTECTED]> writes:


Ben Finney wrote:

"Benjamin Peterson" <[EMAIL PROTECTED]> writes:

Line 94-95 in unittest.py (trunk):
# All classes defined herein are 'new-style' classes, allowing use of 'super()'
__metaclass__ = type

Hmm, you're right; I see that in Python 2.5.2 'unittest.py'.

Why is it not there in 3.0's 'unittest.py'? Is this achieved some
other way?

In 3.0 there are only new-style classes, so nothing needs to be done
there.


What makes that happen in the case where a class declares no
superclass? Is there an invisible enforced "__metaclass__ = type" for
every module? Where can I read about this change?


The magic is actually in 2.x, not in 3.0. In 2.x, if you don't explicit 
set the metaclass (or inherit explicitly from an object which sets it), 
then the default metaclass is 'classobj'. In 3.0, that magic goes away 
and the default metaclass is just 'type'.


Cheers,
Nick.


--
Nick Coghlan   |   [EMAIL PROTECTED]   |   Brisbane, Australia
---
http://www.boredomandlaziness.org
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP: Consolidating names and classes in the `unittest` module (updated 2008-07-15)

[Stephen J. Turnbull]

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 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 content of
unittest should not set policy for our own projects.  So there should
be other modules (perhaps in the stdlib, perhaps not) to satisfy those
preferences not catered to by stdlib's unittest.

Thus this PEP should restrict it's concern to revising unittest to
conform to PEPs and help standardize Python's own testing, without
trying to impose standards on the whole community of Python users.

That's my rationale.  YMMV.

Footnotes: 
[1]  For myself, if the fail*-only proposal wins, I'd switch to that;
fighting the tide on this isn't my idea of fun.  But other assert*
fans may be more faithful to their original preference.

___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] git repositories for trunk and py3k

[Barry Warsaw]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Jul 15, 2008, at 6:41 AM, Paul Moore wrote:


On 15/07/2008, Barry Warsaw <[EMAIL PROTECTED]> 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 than
starting from scratch.

If anyone is interested, I will find a place to host them.  They are
each about 150 MB in size.



Neil, we should try to host them on code.python.org.


If we're setting up a variety of DVCS systems there, I'd be willing to
set up Mercurial repos (I have my own local one, just trunk at the
moment but py3k would be easy enough to add). I'd need access in order
to set up any sort of sync process, though.


We need to get the python.org admins involved in the process at this  
point.  I'm pretty sure that Thomas runs the Bazaar sync operations on  
one of his machines and pushes to code.python.org.  I don't know if  
that's an option for you and/or whether we should bring this in- 
house.  I do remember that at the time, there were issues with bzr-svn  
requiring svn 1.5, which hadn't been released yet.  Now that that's  
out, and there is a more stable generic fast-import process, perhaps  
bringing the sync operations in will be easier.  Unfortunately I will  
have no cycles for this in the next several weeks.


When we put up the experimental bzr repos, we generalized the scripts  
we use to set up access control based on ssh.  It would be a good  
thing if we can use the same arrangement to control access to git and  
hg.


- -Barry

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (Darwin)

iQCVAwUBSHyYQXEjvBPtnXfVAQKNUwP/bH9XYHqZPLipE/cWvI6MpFSrLHU7ANPd
oa/VBsb0QiO3G1+dWj6Q7czJ2QvV/IE0VmXi37AXy3NSp7of80hRDRdpwNabDvnI
cRKSueL/7qCb6+HG0DKoZ+4oh1g94jAok2naUNzffxdx4qFGlQ72WK3bQH1ZrNlp
k5ynDPw9Xdg=
=oC0s
-END PGP SIGNATURE-
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

[Python-Dev] Reminder: beta 2's schedule for tomorrow

[Barry Warsaw]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

A reminder: the second betas of Python 2.6 and 3.0 are schedule for  
tomorrow.  I will try to hang out on #python-dev today and will start  
looking at the trackers and buildbots.  Hopefully, we're on track to  
get the releases out!


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.


- -Barry

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (Darwin)

iQCVAwUBSHyY5XEjvBPtnXfVAQKvYgP+J4GYVDWOraKhErC4wRl0ylEdHcc9LypB
O7yxhBjb+tLu54IImxLkj/Nzff4uUQI6zsA6lg87A4b+sC0/0ltH4+vGkZaq8z7/
xSlP0b0UOaBpOEhTR8ZJK3DJBjSk97IR8Ty3MV1DuM0cczYltorCmQVpodA5ciXj
PRy/LAIalJg=
=DTQM
-END PGP SIGNATURE-
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP: Consolidating names and classes in the `unittest`module (updated 2008-07-15)

[Ben Finney]

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
compliant.

> 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').

I think clarity, consistency, and discoverability are more important
criteria than saving a few characters in a method name.

> Adding in possible positive and negative forms of the proposed new
> methods

A major point of this PEP is to *remove* redundant names in the API.

-- 
 \  “It's dangerous to be right when the government is wrong.” |
  `\   —Francois Marie Arouet Voltaire |
_o__)  |
Ben Finney

___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Default metaclass in Python 3.0 modules

[Ben Finney]

Nick Coghlan <[EMAIL PROTECTED]> writes:

> Ben Finney wrote:
> > What makes that happen in the case where a class declares no
> > superclass? Is there an invisible enforced "__metaclass__ = type"
> > for every module? Where can I read about this change?
> 
> The magic is actually in 2.x, not in 3.0. In 2.x, if you don't
> explicit set the metaclass (or inherit explicitly from an object
> which sets it), then the default metaclass is 'classobj'. In 3.0,
> that magic goes away and the default metaclass is just 'type'.

That helps. Thanks.

-- 
 \  “When I get real bored, I like to drive downtown and get a |
  `\ great parking spot, then sit in my car and count how many |
_o__)people ask me if I'm leaving.” —Steven Wright |
Ben Finney

___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP: Consolidating names and classes in the `unittest` module (updated 2008-07-15)

[Andrew Bennetts]

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 overwhelming in my book.  See
> > 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?

Three more data points then:

bzr: 13228 assert* vs. 770 fail*.

Twisted: 6149 assert* vs. 1666 fail*.

paramiko: 431 assert* vs. 4 fail*.

The data seems pretty overwhelmingly in favour of keeping assert*. 

-Andrew.

___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] [Python-3000] Reminder: beta 2's schedule for tomorrow

[Mark Dickinson]

On Tue, Jul 15, 2008 at 1:32 PM, Barry Warsaw <[EMAIL PROTECTED]> 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.

Can I request permission to check in the patch attached to issue 3008
(float <-> hex) conversion?  This is the revised version of the bin/oct/hex
for floats patch that Raymond had to withdraw shortly after the first beta.

Link to the issue:

http://bugs.python.org/issue3008

and the long recent thread on python-dev

http://mail.python.org/pipermail/python-dev/2008-June/080558.html

Mark
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Mercurial mirrors

[Antoine Pitrou]

Paul Moore  gmail.com> writes:
> 
> If we're setting up a variety of DVCS systems there, I'd be willing to
> set up Mercurial repos (I have my own local one, just trunk at the
> moment but py3k would be easy enough to add).

Using the convert extension or using hgsvn?
I already have public mirrors using hgsvn (synced every 10 minutes):
http://hg.pitrou.net/public/py3k/py3k/
http://hg.pitrou.net/public/cpython/trunk/

I don't know if I'm the only one using them... I know Ralf Schmitt has his own
mirrors at http://hgpy.de/py/ , but they don't have the full history.

Regards

Antoine.


___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] [Python-3000] Reminder: beta 2's schedule for tomorrow

[Nick Coghlan]

Barry Warsaw wrote:
A reminder: the second betas of Python 2.6 and 3.0 are schedule for 
tomorrow.  I will try to hang out on #python-dev today and will start 
looking at the trackers and buildbots.  Hopefully, we're on track to get 
the releases out!


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'll be checking in the fix for issue 2235 shortly (the problem with 
__hash__ not being inherited in 2.x). A pre-review from Guido would have 
been nice (since monkeying with typeobject.c is always a somewhat 
delicate operation), but it looks like he didn't get a chance to get 
back to it after Europython.


I'm also going to forward port the underlying implementation to Py3k (so 
that a non-existent hash is indicated by PyObject_HashNotImplemented in 
tp_hash at the C level as well as by __hash__ = None at the Python level).


Cheers,
Nick.

___
Python-3000 mailing list
[EMAIL PROTECTED]
http://mail.python.org/mailman/listinfo/python-3000
Unsubscribe:
http://mail.python.org/mailman/options/python-3000/ncoghlan%40gmail.com

--
Nick Coghlan   |   [EMAIL PROTECTED]   |   Brisbane, Australia
---
http://www.boredomandlaziness.org
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] [Python-3000] Reminder: beta 2's schedule for tomorrow

[Jesse Noller]

On Tue, Jul 15, 2008 at 8:32 AM, Barry Warsaw <[EMAIL PROTECTED]> wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> A reminder: the second betas of Python 2.6 and 3.0 are schedule for
> tomorrow.  I will try to hang out on #python-dev today and will start
> looking at the trackers and buildbots.  Hopefully, we're on track to get the
> releases out!
>
> 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.
>
> - -Barry
>

One fix I would like for the upcoming beta is the patch to issue874900
- this seems to have resolved a good chunk of the test_multiprocessing
hangs we've been having problems with. I'm in the process of
double-checking the latest patch posted by Greg.

http://bugs.python.org/issue874900
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Proposed unittest changes

[Steven D'Aprano]

On Tue, 15 Jul 2008 04:55:59 pm Thomas Lotze wrote:

> 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 positive
> assertions. 

Please don't claim that your subjective opinion is an objective fact.


> When reading failure conditions, one has to constantly 
> invert them in order to deduce the behaviour that is tested.

You might have to. Don't assume that everyone else has your difficulty.


> failUnless and friends aren't better either IMO since while they do
> work with positive assertions, the method names themselves are doubly
> negative. assert* methods are so much more straightforward to
> comprehend.

Maybe for you. That's not a human universal. Please don't assume that 
your favourite bike-shed colour must be the favourite colour of 
everyone else too.



-- 
Steven
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Mercurial mirrors

[Paul Moore]

On 15/07/2008, Antoine Pitrou <[EMAIL PROTECTED]> wrote:
> Paul Moore  gmail.com> writes:
> >
> > If we're setting up a variety of DVCS systems there, I'd be willing to
> > set up Mercurial repos (I have my own local one, just trunk at the
> > moment but py3k would be easy enough to add).
>
> Using the convert extension or using hgsvn?
> I already have public mirrors using hgsvn (synced every 10 minutes):
> http://hg.pitrou.net/public/py3k/py3k/
> http://hg.pitrou.net/public/cpython/trunk/

Personally, I use convert, because it's more robust on WIndows (there
were a few commits with case clashes which hgsvn can't get past on a
Windows box).

For a central repo, I don't care - but I'd prefer it if all the
options were hosted on code.python.org, just so that no one option
feels more "official" than any other. If I do the work, I'd use
convert, simply because I'm more familiar with it, but that's all.
OTOH, if the process is just copying a local mirror up to the server,
copying your repo might be better (my PC is not always on, and I don't
have frequent syncs set up at the moment).

Paul.
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Default metaclass in Python 3.0 modules (was: PEP: Consolidating names and classes in the `unittest` module (updated 2008-07-15))

[Benjamin Peterson]

On Tue, Jul 15, 2008 at 5:04 AM, Ben Finney <[EMAIL PROTECTED]> wrote:
> "Benjamin Peterson" <[EMAIL PROTECTED]> writes:
>>
>> Line 94-95 in unittest.py (trunk):
>> # All classes defined herein are 'new-style' classes, allowing use of 
>> 'super()'
>> __metaclass__ = type
>
> Hmm, you're right; I see that in Python 2.5.2 'unittest.py'.
>
> Why is it not there in 3.0's 'unittest.py'? Is this achieved some
> other way?

All classes are new-style classes in 3.0!




-- 
Cheers,
Benjamin Peterson
"There's no place like 127.0.0.1."
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP: Consolidating names and classes in the `unittest` module (updated 2008-07-15)

[Ben Finney]

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 unittest-using code we need
> > consider?
> 
> Three more data points then:
> 
> bzr: 13228 assert* vs. 770 fail*.
> Twisted: 6149 assert* vs. 1666 fail*.
> paramiko: 431 assert* vs. 4 fail*.
> 
> The data seems pretty overwhelmingly in favour of keeping assert*. 

Noted, thanks.

So far I have "precedent and tradition" and "positive admonition looks
better" in support of preferring the 'assert*' names. Are there any
others?

I believe I've stated (in the most-recent PEP revision) the strongest
reasons in favour of the 'fail*' names.

This all gets summarised in the Rationale section for the PEP.

-- 
 \   “Killing the creator was the traditional method of patent |
  `\protection” —Terry Pratchett, _Small Gods_ |
_o__)  |
Ben Finney

___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP: Consolidating names and classes in the `unittest` module (updated 2008-07-15)

[Steven D'Aprano]

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 biased 
by the existence of the assert keyword? Do they represent programmers' 
free choices, or the projects' compulsory style guides?

> Personally I also find the assert* syntax preferable over fail*.

Thank you for acknowledging that as a personal preference rather than 
making another spurious claim of objective superiority.



-- 
Steven
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

[Python-Dev] PEP: Consolidating names in the `unittest` module

[Ben Finney]

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 sides of the
divide for 'assert*' versus 'fail*' names.


:PEP:   XXX
:Title: Consolidating names in the `unittest` module
:Version:   0.2
:Last-Modified: 2008-07-15
:Author:Ben Finney <[EMAIL PROTECTED]>
:Status:Draft
:Type:  Standards Track
:Content-Type:  test/x-rst
:Created:   2008-07-14
:Python-Version:2.7, 3.1
:Post-History:


..  contents::


Abstract


This PEP proposes to consolidate the names that constitute the API of
the standard library `unittest` module, with the goal of removing
redundant names, and conforming with PEP 8.


Motivation
==

The normal use case for the `unittest` module is to subclass its
classes, overriding and re-using its functios and methods. This draws
constant attention to the fact that the existing implementation fails
several current Python standards:

* It does not conform to PEP 8 [#PEP-8]_, requiring users to write
  their own non-PEP-8 conformant names when overriding methods, and
  encouraging extensions to further depart from PEP 8.

* It has many synonyms in its API, which goes against the Zen of
  Python [#PEP-20]_ (specifically, that "there should be one, and
  preferably only one, obvious way to do it").


Specification
=

Remove obsolete names
-

The following module attributes are not documented as part of the API
and are marked as obsolete in the implementation. They will be
removed.

* ``_makeLoader``
* ``getTestCaseNames``
* ``makeSuite``
* ``findTestCases``

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``
* ``assertEquals``
* ``assertNotEqual``
* ``assertNotEquals``
* ``assertAlmostEqual``
* ``assertAlmostEquals``
* ``assertNotAlmostEqual``
* ``assertNotAlmostEquals``
* ``assertRaises``
* ``assert_``
* ``assertTrue``
* ``assertFalse``

Conform API with PEP 8
--

The following names are to be introduced, each replacing an existing
name, to make all names in the module conform with PEP 8 [#PEP-8]_.
Each name is shown with the existing name that it replaces.

Where function parameters are to be renamed also, they are shown.
Where function parameters are not to be renamed, they are elided with
the ellipse ("…") symbol.

Module attributes
~

``default_test_loader``
  Replaces ``defaultTestLoader``

``TestResult`` attributes
~

``add_error(…)``
  Replaces ``addError(…)``

``add_result(…)``
  Replaces ``addResult(…)``

``add_success(…)``
  Replaces ``addSuccess(…)``

``should_stop``
  Replaces ``shouldStop``

``start_test(…)``
  Replaces ``startTest(…)``

``stop_test(…)``
  Replaces ``stopTest(…)``

``tests_run``
  Replaces ``testsRun``

``was_successful(…)``
  Replaces ``wasSuccessful(…)``

``TestCase`` attributes
~~~

``__init__(self, method_name='run_test')``
  Replaces ``__init__(self, methodName='runTest')``

``_test_method_doc``
  Replaces ``_testMethodDoc``

``_test_method_name``
  Replaces ``_testMethodName``

``failure_exception``
  Replaces ``failureException``

``count_test_cases(…)``
  Replaces ``countTestCases(…)``

``default_test_result(…)``
  Replaces ``defaultTestResult(…)``

``fail_if(…)``
  Replaces ``failIf(…)``

``fail_if_almost_equal(…)``
  Replaces ``failIfAlmostEqual(…)``

``fail_if_equal(…)``
  Replaces ``failIfEqual(…)``

``fail_unless(…)``
  Replaces ``failUnless(…)``

``fail_unless_almost_equal(…)`` 
  Replaces ``failUnlessAlmostEqual(…)``

``fail_unless_equal(…)``
  Replaces ``failUnlessEqual(…)``

``fail_unless_raises(exc_class, callable_obj, *args, **kwargs)``
  Replaces ``failUnlessRaises(excClass, callableObj, *args, **kwargs)``

``run_test(…)``
  Replaces ``runTest(…)``

``set_up(…)``
  Replaces ``setUp(…)``

``short_description(…)``
  Replaces ``shortDescription(…)``

``tear_down(…)``
  Replaces ``tearDown(…)``

``FunctionTestCase`` attributes
~~~

``__init__(self, test_func, set_up, tear_down, description)``
  Replaces ``__init__(self, testFunc, setUp, tearDown, description)``

``run_test(…)``
  Replaces ``runTest(…)``

``set_up(…)``
  Replaces ``setUp(…)``

``short_description(…)``
  Replaces ``shortDescription(…)``

``tear_down(…)``
  Replaces ``tearDown(…)``

``TestSuite`` attributes


``add_test(…)``
  Replaces ``addTest(…)``

``add_tests(…)``
  Replaces ``addTests(…)``

``count_test_cases(…)``
  Replaces ``countTestCases(…)``

``TestLoader`` attributes
~

``sort_test_methods_using``
  Replaces ``sortTestMethodsUsing``

``suite_class``
  Replaces ``su

Re: [Python-Dev] Mercurial mirrors

[Antoine Pitrou]

Paul Moore  gmail.com> writes:
> 
> Personally, I use convert, because it's more robust on WIndows (there
> were a few commits with case clashes which hgsvn can't get past on a
> Windows box).

If the convert extension is finally usable for incremental mirroring, then it's
good news. I don't want to maintain hgsvn all my life :-)

> For a central repo, I don't care - but I'd prefer it if all the
> options were hosted on code.python.org, just so that no one option
> feels more "official" than any other.

I completely agree.

Regards

Antoine.


___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP: Consolidating names and classes in the `unittest` module (updated 2008-07-15)

[Richard Thomas]

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 than "assert" if only for the reason that its unclear
what "assert" might do. This is similar to one of the arguments raised
in the PEP, but considered from the point of view of someone new to
test frameworks it could be all the more important.

On another note, while I understand that consistency is a good thing
is it really that important in test suites? Obviously the unittest
module itself should be internally consistent but why not provide
people using the all the synonyms they might want? I can see people
just wrapping TestCase to add the synonyms back in.

Richard
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP: Consolidating names and classes in the `unittest`module (updated 2008-07-15)

[Nick Coghlan]

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').


Disclaimer: I'm not convinced the ideas in this message are actually a 
good idea myself. But I found them intriguing enough to bother posting 
them. To give some idea of how the different styles would look, here's 
an example (based on one of the tests in test_runpy) using a combination 
of assert* and fail_if* names:


self.fail_if_contains(d1, "result")
self.assert_identical(d2["initial"], initial)
self.assert_equal(d2["result"], self.expected_result)
self.assert_equal(d2["nested"]["x"], 1)
self.assert_(d2["run_name_in_sys_modules"])
self.assert_(d2["module_in_sys_modules"])
self.assert_identical(d2["run_argv0"], file)
self.assert_identical(sys.argv[0], saved_argv0)
self.fail_if_contains(sys.modules, name)

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'.


This approach would give:

Test assertions:
  assert_almost_equal
  assert_identical
  assert_contains
  assert_raises
  assert_equal
  assert_

Test denials (negative assertions):
  deny_almost_equal   (17)
  deny_identical  (14)
  deny_contains   (13)
  deny_equal  (10)
  deny (4)

Explicit failure:
  fail (4)

Using the test_runpy example assertions:
self.deny_contains(d1, "result")
self.assert_identical(d2["initial"], initial)
self.assert_equal(d2["result"], self.expected_result)
self.assert_equal(d2["nested"]["x"], 1)
self.assert_(d2["run_name_in_sys_modules"])
self.assert_(d2["module_in_sys_modules"])
self.assert_identical(d2["run_argv0"], file)
self.assert_identical(sys.argv[0], saved_argv0)
self.deny_contains(sys.modules, name)

I actually quite like that - and it saves not only several characters, 
but also an underscore over the fail_if* and assert_not* variants.


The second odd thought was what happens if the 'assert' is made implicit?

Test assertions:
  are_almost_equal
  are_identical
  does_contain
  does_raise
  are_equal
  assert_

Test negative assertions:
  not_almost_equal
  not_identical
  not_contains
  not_equal
  not_

Explicit failure:
  fail

Using the test_runpy example assertions:
self.not_contains(d1, "result")
self.are_identical(d2["initial"], initial)
self.are_equal(d2["result"], self.expected_result)
self.are_equal(d2["nested"]["x"], 1)
self.assert_(d2["run_name_in_sys_modules"])
self.assert_(d2["module_in_sys_modules"])
self.are_identical(d2["run_argv0"], file)
self.are_identical(sys.argv[0], saved_argv0)
self.not_contains(sys.modules, name)

Yecch, I think that idea can be safely consigned to the mental trash heap.
Another late night API concept: create a "check" object with the LHS of 
the binary operation being asserted, then use methods on that check 
object to supply the RHS:


self.check("result").not_in(d1)
self.check(d2["initial"]).is_(initial)
self.check(d2["result"]).equals(self.expected_result)
self.check(d2["nested"]["x"]).equals(1)
self.assert_(d2["run_name_in_sys_modules"])
self.assert_(d2["module_in_sys_modules"])
self.check(d2["run_argv0"]).is_(file)
self.check(sys.argv[0]).is_(saved_argv0)
self.check(name).not_in(sys.modules)

This approach would also be handy if you needed to check multiple 
conditions on a single result:


check = self.check(result)
check.is_equal(expected_result) # Right answer
check.is_not(expected_result)   # Fresh object
check.is_(recent_results[-1])   # Recorded properly

Cheers,
Nick.

--
Nick Coghlan   |   [EMAIL PROTECTED]   |   Brisbane, Australia
---
http://www.boredomandlaziness.org
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP: Consolidating names and classes in the `unittest` module (updated 2008-07-15)

[C. Titus Brown]

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 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 the arguments raised
-> in the PEP, but considered from the point of view of someone new to
-> test frameworks it could be all the more important.

Maybe this is an unnecessarily hard line, but if someone doesn't know
what "assert" does, then they should go look up the keyword -- it's
part of Python (and present in C, C++, Perl, and PHP as well).  So
unless the person is new to Python AND testing, they should know it.

-> On another note, while I understand that consistency is a good thing
-> is it really that important in test suites? Obviously the unittest
-> module itself should be internally consistent but why not provide
-> people using the all the synonyms they might want? I can see people
-> just wrapping TestCase to add the synonyms back in.

While I don't have a strong position on the assert* vs fail*, I think
consistency and simplicity in test suites is at least as important as in
code: if you have to work hard to understand and debug your test suites,
you've done something seriously wrong in building your tests.

Tests should be as simple as possible, and no simpler.

--titus
-- 
C. Titus Brown, [EMAIL PROTECTED]
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP: Consolidating names and classes in the `unittest`module (updated 2008-07-15)

[Paul Rudin]

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/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Mercurial mirrors

[Paul Moore]

On 15/07/2008, Antoine Pitrou <[EMAIL PROTECTED]> wrote:
> Paul Moore  gmail.com> writes:
> >
> > Personally, I use convert, because it's more robust on WIndows (there
> > were a few commits with case clashes which hgsvn can't get past on a
> > Windows box).
>
> If the convert extension is finally usable for incremental mirroring, then 
> it's
> good news. I don't want to maintain hgsvn all my life :-)

It works for me. I think a couple of very recently landed patches[1]
may be needed for certain case issues on Windows, but that's all.
Also, it requires the Subversion bindings, and the "official" Windows
binaries don't include those - but it's easy to build your own copy
that does.

Paul.

[1] In other words, not in 1.0 or even 1.0.1.
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] [Python-3000] Reminder: beta 2's schedule for tomorrow

[Nick Coghlan]

Nick Coghlan wrote:

Barry Warsaw wrote:
A reminder: the second betas of Python 2.6 and 3.0 are schedule for 
tomorrow.  I will try to hang out on #python-dev today and will start 
looking at the trackers and buildbots.  Hopefully, we're on track to 
get the releases out!


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'll be checking in the fix for issue 2235 shortly (the problem with 
__hash__ not being inherited in 2.x). A pre-review from Guido would have 
been nice (since monkeying with typeobject.c is always a somewhat 
delicate operation), but it looks like he didn't get a chance to get 
back to it after Europython.


I'm also going to forward port the underlying implementation to Py3k (so 
that a non-existent hash is indicated by PyObject_HashNotImplemented in 
tp_hash at the C level as well as by __hash__ = None at the Python level).


This is now done. There's some documentation updates still to do, as 
well as adding the Py3k warning back in to the 2.6 version, but I won't 
have time to do that for this release - I dropped the tracker item down 
to deferred blocker so it gets back on the list for beta 3.


Looking at the buildbots, getting the multiprocessing fixes in looks 
like it will be a major help in getting more of them to go green, and 
the import related lib2to3 tests also appear to need some attention.


Cheers,
Nick.

--
Nick Coghlan   |   [EMAIL PROTECTED]   |   Brisbane, Australia
---
http://www.boredomandlaziness.org
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Proposed unittest changes

[Guido van Rossum]

On Mon, Jul 14, 2008 at 11:55 PM, somebody wrote:
> I'm surprised nobody (that I've noticed) has brought up the point yet that
[...]

Not picking on whoever wrote that specifically, but if there's
anything that surprises me, it's how many people have voiced opinions
already (including many of them that I hadn't heard in this group
before). There doesn't seem to be an end to this debate, and it is
awfully close to deteriorating to pure bikeshedding and attempted
ad-hominem attacks. I really don't have time to participate in detail,
since all the time I have for Python I need to spend on trying to help
review the 2.6 and 3.0 beta releases. But I want to remind people that
radical changes to the unittest infrastructure will inconvenience many
large 3rd party projects using Python, and I urge folks to look for
ways to improve the unittest APIs in other ways instead. It's not the
end of the world if the unittesting API uses assertEqual() instead of
assert_equal() until the end of times. It would, however, be a shame
if we couldn't agree to *add* a bunch of features, for example better
reporting when two lists or long strings differ.

-- 
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP: Consolidating names and classes in the `unittest` module

[Terry Reedy]

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 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.

* ``TestResult``
* ``TestCase``
* ``TestSuite``
* ``TestLoader``
* ``_WritelnDecorator``
* ``TextTestRunner``
* ``TestProgram``

They already do. __metaclass__ = type is found in unittest.py.

Not in the copy I have. Is that in 3.x only, or in 2.x also?


Python 2.5.2 (r252:60911, Feb 22 2008, 07:57:53)
[GCC 4.0.1 (Apple Computer, Inc. build 5363)] on darwin
Type "help", "copyright", "credits" or "license" for more information.

import unittest
isinstance(unittest.TestCase, object)

True


*Everything* is an instance of object.
The question is whether the test classes are subclasses of object.
In particular, issubclass(unittest.TestCase, object)?
Either direct inheritance from object or '__metaclass__ = type' will 
make them so.  With neither, they will not be.


tjr

___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP: Consolidating names and classes in the `unittest` module (updated 2008-07-15)

[Terry Reedy]

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 content of
unittest should not set policy for our own projects.  So there should
be other modules (perhaps in the stdlib, perhaps not) to satisfy those
preferences not catered to by stdlib's unittest.


It should be trivial to write a module 'unitfail' that would 'from 
unittest import *' and then flip the assert names to fail names.  The 
only question is whether it needs to be in the stdlib or merely PyPI.


I word this this way because Guido has already blessed the assert forms 
for unittest.  If he is persuaded otherwise, revise accordingly.



Thus this PEP should restrict it's concern to revising unittest to
conform to PEPs and help standardize Python's own testing, without
trying to impose standards on the whole community of Python users.


For the community as a whole, all stdlib modules are suggestions and 
examples, not commands.


tjr

___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Proposed unittest changes

[Terry Reedy]

http://lists.idyll.org/pipermail/testing-in-python/2007-November/000406.html

& associated thread, for those interested in the variety of mock
libraries...


That might be a good beginning for an updateable wiki page on mock 
libraries.


___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Running Py2.6 with the -3 option

[Guido van Rossum]

On Fri, Jul 11, 2008 at 1:16 PM, Brett Cannon <[EMAIL PROTECTED]> wrote:
> No, we should eat our own dog food and transition the code over. If
> anything it will help with code maintenance between 2.x and 3.x.

Agreed. It would be annoying to users trying to clear their own code
of -3 warnings if the stdlib emitted warnings they couldn't easily
suppress.

It should be done with extreme caution though, and preferably on a
case-by-case basis rather than in a sweeping pass. Caution should also
be taken that the changes aren't merged into 3.0 (where presumably
they would conflict with already 3.0-compatible code).

I wonder if it might not be simpler (at least in some cases) to just
disable the warnings for certain modules? I imagine in many cases
fixing up the 2.6 code to suppress -3 warnings would be mere busywork
-- e.g. for code that gets deleted in 3.0 altogether. (Hm, in fact for
such code there's no need to suppress the -3 warnings, as they serve
as a warning to any user of the module that they are using something
that won't survive into 3.0.)

-- 
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] ctypes assertion failure

[Thomas Heller]

Tim Golden schrieb:
> This problem was raised on the comtypes-users list
> as it prevents comtypes from being imported on Python 2.6
> at the moment.
> 
> http://bugs.python.org/issue3258
> 
> I'll try to find the time to step through to code to work out
> what's going on, but it's inside the innards of ctypes which
> I've never looked into before.
> 
> Could someone confirm at a glance whether this should be
> given a high priority, please? It results in an assertion error
> in debug mode, a SystemError in non-debug referring to
> a NULL return without an Exception set.
> 

The problem is now fixed.

-- 
Thanks,
Thomas

___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Running Py2.6 with the -3 option

[Benjamin Peterson]

On Tue, Jul 15, 2008 at 12:37 PM, Guido van Rossum <[EMAIL PROTECTED]> wrote:
>
> I wonder if it might not be simpler (at least in some cases) to just
> disable the warnings for certain modules? I imagine in many cases
> fixing up the 2.6 code to suppress -3 warnings would be mere busywork
> -- e.g. for code that gets deleted in 3.0 altogether. (Hm, in fact for
> such code there's no need to suppress the -3 warnings, as they serve
> as a warning to any user of the module that they are using something
> that won't survive into 3.0.)

Very true. It might be easiest to just throw (maybe even just temporarily)

if sys.py3kwarning:
warnings.filterwarnings("ignore", category=DeprecationWarning,
module=__name__)

at the top of the offending module.


-- 
Cheers,
Benjamin Peterson
"There's no place like 127.0.0.1."
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP: Consolidating names and classes in the `unittest` module (updated 2008-07-15)

[Tres Seaver]

-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
>>>  > ``assert*`` names or the ``fail*`` names;
>>>
>>> 7 to 1 is overwhelming in my book.  See
>>> 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?
> 
> Three more data points then:
> 
> bzr: 13228 assert* vs. 770 fail*.
> 
> Twisted: 6149 assert* vs. 1666 fail*.
> 
> paramiko: 431 assert* vs. 4 fail*.
> 
> The data seems pretty overwhelmingly in favour of keeping assert*. 

FWIW:  Zope2:  16878 'assert*', 2892 'fail*'.  I would keep both by
preference, rather than insist on a "foolish consistency."


Tres.
- --
===
Tres Seaver  +1 540-429-0999  [EMAIL PROTECTED]
Palladion Software   "Excellence by Design"http://palladion.com
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFIfOJI+gerLs4ltQ4RArw5AJ0fUzXiMefC4CQZDk4K0mlQFn3nAACfRLya
CuhfeNQd8OUPFi5+E5aJN9M=
=2Hsl
-END PGP SIGNATURE-

___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] [Python-3000] Reminder: beta 2's schedule for tomorrow

[Brett Cannon]

On Tue, Jul 15, 2008 at 5:32 AM, Barry Warsaw <[EMAIL PROTECTED]> wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> A reminder: the second betas of Python 2.6 and 3.0 are schedule for
> tomorrow.  I will try to hang out on #python-dev today and will start
> looking at the trackers and buildbots.  Hopefully, we're on track to get the
> releases out!
>
> 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.
>

The new urllib package landed between the last beta and now, but
without fixers. Issue3316 has potential ones, but they have some
tweaks that need to be made before they are release quality. If the
beta goes out 2to3 will not be able to fix imports for urllib and
urllib2. Don't know if that is enough to hold up the release or just
something to put in the release notes that this will be resolved by
the next beta; made it a release blocker to catch your eye, Barry. =)

Oh, and fixers for test.test_support to test.support is not in either,
but this is probably such a small use case outside the core that I am
not sweating bullets for writing a new fixer just for this one case.

-Brett
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP: Consolidating names and classes in the `unittest` module (updated 2008-07-15)

[Mike Klaas]

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 assert* vs. 770 fail*.

Twisted: 6149 assert* vs. 1666 fail*.

paramiko: 431 assert* vs. 4 fail*.


Our internal code base:

$ ack self.assert. | wc -l
3232
$ ack self.fail. | wc -l
1124

-Mike

___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] git repositories for trunk and py3k

[Neil Schemenauer]

On Mon, Jul 14, 2008 at 09:31:47PM -0400, Barry Warsaw wrote:
> Neil, we should try to host them on code.python.org.

I was hoping to get a sense of the interest.  Oh well, if you build
it they might come. ;-) I've written draft instructions, temporarily
at .  The trunk and py3k
repositories are now avaliable at git://code.python.org.  They
currently get updated every 30 minutes.

I'm definitely not a git guru so I hope the instructions work for
people.  The setup is a little complicated because I want updates to
use the more efficient git protocol rather than hammering the SVN
server.  I've tried making a check-in using dcommit and everything
seems okay.  I'd gladly receive suggestions on improving the
instructions.

  Neil
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] git repositories for trunk and py3k

[Benjamin Peterson]

On Tue, Jul 15, 2008 at 3:04 PM, Neil Schemenauer <[EMAIL PROTECTED]> wrote:
> On Mon, Jul 14, 2008 at 09:31:47PM -0400, Barry Warsaw wrote:
>> Neil, we should try to host them on code.python.org.
>
> I was hoping to get a sense of the interest.  Oh well, if you build
> it they might come. ;-) I've written draft instructions, temporarily
> at .  The trunk and py3k
> repositories are now avaliable at git://code.python.org.  They
> currently get updated every 30 minutes.

Can we push branches?



-- 
Cheers,
Benjamin Peterson
"There's no place like 127.0.0.1."
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] git repositories for trunk and py3k

[Brett Cannon]

On Tue, Jul 15, 2008 at 1:04 PM, Neil Schemenauer <[EMAIL PROTECTED]> wrote:
> On Mon, Jul 14, 2008 at 09:31:47PM -0400, Barry Warsaw wrote:
>> Neil, we should try to host them on code.python.org.
>
> I was hoping to get a sense of the interest.  Oh well, if you build
> it they might come. ;-) I've written draft instructions, temporarily
> at .  The trunk and py3k
> repositories are now avaliable at git://code.python.org.  They
> currently get updated every 30 minutes.
>
> I'm definitely not a git guru so I hope the instructions work for
> people.  The setup is a little complicated because I want updates to
> use the more efficient git protocol rather than hammering the SVN
> server.  I've tried making a check-in using dcommit and everything
> seems okay.  I'd gladly receive suggestions on improving the
> instructions.
>

If you are up to keep this up and running, Neil, I (or anyone else
with pydotorg access) can put your instructions online like the bzr
instructions at http://www.python.org/dev/bazaar/ .

-Brett
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP: Consolidating names and classes in the `unittest` module (updated 2008-07-15)

[Stephen J. Turnbull]

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.
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] git repositories for trunk and py3k

[Neil Schemenauer]

Benjamin Peterson <[EMAIL PROTECTED]> wrote:
> Can we push branches?

The git-daemon is setup as read-only.  If you have write access to
the SVN repository then you can push back changes using git-svn.
That's quite a nice way to work, IMHO and provides an easy path for
people who are used to Subversion and want to dip their toe in the
dvcs waters.

While there is no support on code.python.org for publishing your own
git branches, there's no reason why you couldn't publish a branch
using some other host (it's a dvcs after all).  In the short term,
perhaps using private branches in combination with "git
format-patch" and email is the easiest process.

Regards,

  Neil

___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] [Python-3000] commit access request

[Antoine Pitrou]

Le mardi 15 juillet 2008 à 13:57 -0700, Brett Cannon a écrit :
> I can't give the privileges, Antoine, but I know that an SSH 2 public
> key is going to be needed (see the dev FAQ at
> http://www.python.org/dev/faq/ if you don't know how to generate one).

It's attached.

> They will also need to know how you want your first.last name spelled
> for your user account.

Please make that antoine.pitrou.

> Just send that all in a separate email to python-dev and someone who
> can add you will get to it at some point (probably soon).

Thanks !

Antoine.

ssh-dss 
B3NzaC1kc3MAAACBAJiwbeZEP4oPxn/mpbcjPIfmyqDRoyut/AAE76coOCKB3BouwYJPns4Osas6NjR3m9TErNrvcFcm2jCXYTxbrIQmnz1oLwxzmjPK36AUpXtqOy5GPdFUJiVe7iqEBslwtaPVGweXrYdv7ZaI7G6m1ZJDh03uqP6HjNIA1y3yeJFDFQCxc0R9pwTFUnB4HeHJnx0xE1qg3wAAAIAyxftjIkEAghCBeqbc7W5GRHt2AQ6nczrMCn76pc25+2SkbK750Zk5dAZtIiGkvwNBH2sDdKUzccWkKN7LcyW8ChPLLM1VNVHfgwqQEDbopjd7FkLsOwuQGSxpPoZpTPmewmfJxBJN3kNE5MRVYpzihmqCCoNRi4peMBonuevm4QAAAIEAgCRFJydgXmtk3MiGkX2MyU0DAoAmRzUtJtstYLY0ZqdUvd/0fD4JkpIyZu1N7ROYwzsVCAoU/H6gNGuUFY/NcvfKBUBPZ/yYHECTmstJIWY2X1yVSx59s4lJBZzVUgrP++KTLS+F7n6bil5rsmAaUqg/MoxoMJVLhkvdLvyVPZY=
 antoine.pitrou
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

[Python-Dev] PEP: Consolidating names in the `unittest` module

[Stephen J. Turnbull]

Ben Finney writes:

 > Removal of ``assert*`` names
 > 

 > Arguments in favour of retaining only the ``assert*`` names:
 > 
 > * BDFL preference: The BDFL has stated [#vanrossum-1]_ a preference
 >   for the ``assert*`` names.
 > 
 > * Precedent: The Python standard library currently uses the
 >   ``assert*`` names by a roughly 8:1 majority over the ``fail*``
 >   names. (Counting unit tests in the py3k tree at 2008-07-15
 >   [#pitrou-1]_.)
 > 
 >   An ad-hoc sampling of other projects that use `unittest` also
 >   demonstrates strong preference for use of the ``assert*`` names
 >   [#bennetts-1]_.
 > 
 > * Positive admonition: The ``assert*`` names state the intent of how
 >   the code under test *should* behave, while the ``fail*`` names are
 >   phrased in terms of how the code *should not* behave.

FWIW, I think these are fairly stated.  So fairly that I'm surprised
you haven't been persuaded!  Nitpick: the second point is not
just "precedent", there's an economic reason there too.  Tests in the
standard distribution which use the deprecated style will need to be
converted.  Steven d'Aprano claims this is nontrivial (and thus error-
prone) in some cases.  I haven't seen that claim denied, and it seems
plausible to me.

 > PEP 8 names
 > ---
 > 
 > Although `unittest` (and its predecessor `PyUnit`) are intended to be
 > familiar to users of other xUnit interfaces, there is no attempt at
 > direct API compatibility since the only code that Python's `unittest`
 > interfaces with is other Python code. The module is in the standard
 > library and its names should all conform with PEP 8 [#PEP-8]_.

You should mention Raymond's concern that PEP 8 names are quite a bit
longer.

___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP: Consolidating names in the `unittest` module

[Guido van Rossum]

On Tue, Jul 15, 2008 at 3:20 PM, Stephen J. Turnbull <[EMAIL PROTECTED]> wrote:
>  > * Positive admonition: The ``assert*`` names state the intent of how
>  >   the code under test *should* behave, while the ``fail*`` names are
>  >   phrased in terms of how the code *should not* behave.
>
> FWIW, I think these are fairly stated.  So fairly that I'm surprised
> you haven't been persuaded!  Nitpick: the second point is not
> just "precedent", there's an economic reason there too.  Tests in the
> standard distribution which use the deprecated style will need to be
> converted.  Steven d'Aprano claims this is nontrivial (and thus error-
> prone) in some cases.  I haven't seen that claim denied, and it seems
> plausible to me.

I'd like to see examples of that (this would be Steven's task if he's
serious about his assertion). Since the fail and assert names are
mapped to each other using aliasing I don't see how it could be
nontrivial to map e.g. self.failIf(x) to self.assertFalse(x) -- these
are the same function!

-- 
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Running Py2.6 with the -3 option

[Terry Reedy]

Benjamin Peterson wrote:

On Tue, Jul 15, 2008 at 12:37 PM, Guido van Rossum <[EMAIL PROTECTED]> wrote:

I wonder if it might not be simpler (at least in some cases) to just
disable the warnings for certain modules? I imagine in many cases
fixing up the 2.6 code to suppress -3 warnings would be mere busywork
-- e.g. for code that gets deleted in 3.0 altogether. (Hm, in fact for
such code there's no need to suppress the -3 warnings, as they serve
as a warning to any user of the module that they are using something
that won't survive into 3.0.)


Very true. It might be easiest to just throw (maybe even just temporarily)

if sys.py3kwarning:
warnings.filterwarnings("ignore", category=DeprecationWarning,
module=__name__)

at the top of the offending module.


Is it possible to *first* 'raise' a DeprecationWarning("This module will 
disappear") before turning the rest off?  Exactly 1 seems the right 
number to me for modules that will go.


___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP: Consolidating names and classes in the `unittest` module (updated 2008-07-15)

[Ben Finney]

"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 the
> -> arguments raised in the PEP, but considered from the point of
> -> view of someone new to test frameworks it could be all the more
> -> important.
> 
> Maybe this is an unnecessarily hard line, but if someone doesn't know
> what "assert" does, then they should go look up the keyword -- it's
> part of Python (and present in C, C++, Perl, and PHP as well).  So
> unless the person is new to Python AND testing, they should know it.

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 what the 'assert' statement does.

> While I don't have a strong position on the assert* vs fail*, I
> think consistency and simplicity in test suites is at least as
> important as in code: if you have to work hard to understand and
> debug your test suites, you've done something seriously wrong in
> building your tests.

Yes. While I prefer the 'fail*' names, I would prefer to lose *either*
of 'assert*' or 'fail*' than to retain redundant names in the API.

-- 
 \ “If I had known what it would be like to have it all... I might |
  `\ have been willing to settle for less.” —Jane Wagner, via Lily |
_o__)   Tomlin |
Ben Finney

___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP: Consolidating names and classes in the `unittest` module (updated 2008-07-15)

[Guido van Rossum]

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 what the 'assert' statement does.

The parallel is intentional. They even raise the same exception. Too
bad it doesn't work for you; get over it.

-- 
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Running Py2.6 with the -3 option

[Brett Cannon]

On Tue, Jul 15, 2008 at 3:23 PM, Terry Reedy <[EMAIL PROTECTED]> wrote:
>
>
> Benjamin Peterson wrote:
>>
>> On Tue, Jul 15, 2008 at 12:37 PM, Guido van Rossum <[EMAIL PROTECTED]>
>> wrote:
>>>
>>> I wonder if it might not be simpler (at least in some cases) to just
>>> disable the warnings for certain modules? I imagine in many cases
>>> fixing up the 2.6 code to suppress -3 warnings would be mere busywork
>>> -- e.g. for code that gets deleted in 3.0 altogether. (Hm, in fact for
>>> such code there's no need to suppress the -3 warnings, as they serve
>>> as a warning to any user of the module that they are using something
>>> that won't survive into 3.0.)
>>
>> Very true. It might be easiest to just throw (maybe even just temporarily)
>>
>> if sys.py3kwarning:
>>warnings.filterwarnings("ignore", category=DeprecationWarning,
>> module=__name__)
>>
>> at the top of the offending module.
>
> Is it possible to *first* 'raise' a DeprecationWarning("This module will
> disappear") before turning the rest off?  Exactly 1 seems the right number
> to me for modules that will go.
>

Wouldn't you just add the filter after the DeprecationWarning is
raised to have that behavior?

-Brett
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP: Consolidating names and classes in the `unittest` module (updated 2008-07-15)

[Ben Finney]

"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 imposition.

I understood Terry's statement as meaning that there is no commandment
to use the standard library 'unittest' module at all. If a user
doesn't like the behaviour of a module (such as 'unittest') in the
standard library, they can accept the burden of implementing one that
behaves the way they like.

-- 
 \   “I never forget a face, but in your case I'll be glad to make |
  `\  an exception.” —Groucho Marx |
_o__)  |
Ben Finney

___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP: Consolidating names and classes in the `unittest`module (updated 2008-07-15)

[Ben Finney]

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 nor meaningful in context. The term
"deny" is strongly linked to its antonym, "permit".

Whom is being denied? What have they asked to do that I am denying in
my test? I think in terms of "true or false", or "pass or fail". I'm
making statements about behaviour of the program, not about permitting
or denying something.

-- 
 \“The industrial system is profoundly dependent on commercial |
  `\   television and could not exist in its present form without it.” |
_o__)—John Kenneth Galbraith, _The New Industrial State_, 1967 |
Ben Finney

___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP: Consolidating names and classes in the `unittest` module (updated 2008-07-15)

[Ben Finney]

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, but of API
simplicity.

-- 
 \ “Under democracy one party always devotes its chief energies to |
  `\   trying to prove that the other party is unfit to rule--and both |
_o__)  commonly succeed, and are right.” —Henry L. Mencken |
Ben Finney

___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Proposed unittest changes

[Ben Finney]

"Guido van Rossum" <[EMAIL PROTECTED]> writes:

> It would, however, be a shame if we couldn't agree to *add* a bunch
> of features, for example better reporting when two lists or long
> strings differ.

I intend to phrase such additions in terms of PEP-8-only names, so
this name consolidation seems a natural prerequisite.

-- 
 \   “Are you pondering what I'm pondering?” “Well, I think so |
  `\  Brain, but what if we stick to the seat covers?” —_Pinky and |
_o__)   The Brain_ |
Ben Finney

___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP: Consolidating names in the `unittest` module

[Ben Finney]

"Stephen J. Turnbull" <[EMAIL PROTECTED]> writes:

> FWIW, I think these are fairly stated.  So fairly that I'm surprised
> you haven't been persuaded!

I'm not persuaded because I find the arguments for 'fail*' more
persuasive :-)

I am, however, convinced that the consensus of the community is that
'assert*' is the right choice. The PEP will be revised accordingly.

> Nitpick: the second point is not just "precedent", there's an
> economic reason there too.
[...]

> You should mention Raymond's concern that PEP 8 names are quite a
> bit longer.

Noted both of these, thanks.

-- 
 \  “The best way to get information on Usenet is not to ask a |
  `\   question, but to post the wrong information.” —Aahz |
_o__)  |
Ben Finney

___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

[Python-Dev] PEP: Consolidating names in the `unittest` module (updated 2008-07-16)

[Ben Finney]

Significant changes are resolving to remove the 'fail*' names, giving
recommended name to use for each removed name, and further summary of
related discussion.


:PEP:   XXX
:Title: Consolidating names in the `unittest` module
:Version:   0.3
:Last-Modified: 2008-07-16
:Author:Ben Finney <[EMAIL PROTECTED]>
:Status:Draft
:Type:  Standards Track
:Content-Type:  test/x-rst
:Created:   2008-07-14
:Python-Version:2.7, 3.1
:Post-History:


..  contents::


Abstract


This PEP proposes to consolidate the names that constitute the API of
the standard library `unittest` module, with the goal of removing
redundant names, and conforming with PEP 8.


Motivation
==

The normal use case for the `unittest` module is to subclass its
classes, overriding and re-using its functios and methods. This draws
constant attention to the fact that the existing implementation fails
several current Python standards:

* It does not conform to PEP 8 [#PEP-8]_, requiring users to write
  their own non-PEP-8 conformant names when overriding methods, and
  encouraging extensions to further depart from PEP 8.

* It has many synonyms in its API, which goes against the Zen of
  Python [#PEP-20]_ (specifically, that "there should be one, and
  preferably only one, obvious way to do it").


Specification
=

Remove obsolete names
-

The following module attributes are not documented as part of the API
and are marked as obsolete in the implementation. They will be
removed.

* ``_makeLoader``
* ``getTestCaseNames``
* ``makeSuite``
* ``findTestCases``

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
~~~

``assert_``
  Use ``assert_true``, or an ``assert`` statement.

``assertEquals``
  Use ``assert_equal``.

``assertNotEquals``
  Use ``assert_not_equal``.

``assertAlmostEquals``
  Use ``assert_almost_equal``.

``assertNotAlmostEquals``
  Use ``assert_not_almost_equal``.

``failIf``
  Use ``assert_false``.

``failUnless``
  Use ``assert_true``.

``failIfAlmostEqual``
  Use ``assert_not_almost_equal``.

``failIfEqual``
  Use ``assert_not_equal``.

``failUnlessAlmostEqual``
  Use ``assert_almost_equal``.
  
``failUnlessEqual``
  Use ``assert_equal``.

``failUnlessRaises``
  Use ``assert_raises``.

Conform API with PEP 8
--

The following names are to be introduced, each replacing an existing
name, to make all names in the module conform with PEP 8 [#PEP-8]_.
Each name is shown with the existing name that it replaces.

Where function parameters are to be renamed also, they are shown.
Where function parameters are not to be renamed, they are elided with
the ellipse ("…") symbol.

Module attributes
~

``default_test_loader``
  Replaces ``defaultTestLoader``

``TestResult`` attributes
~

``add_error(…)``
  Replaces ``addError(…)``

``add_result(…)``
  Replaces ``addResult(…)``

``add_success(…)``
  Replaces ``addSuccess(…)``

``should_stop``
  Replaces ``shouldStop``

``start_test(…)``
  Replaces ``startTest(…)``

``stop_test(…)``
  Replaces ``stopTest(…)``

``tests_run``
  Replaces ``testsRun``

``was_successful(…)``
  Replaces ``wasSuccessful(…)``

``TestCase`` attributes
~~~

``__init__(self, method_name='run_test')``
  Replaces ``__init__(self, methodName='runTest')``

``_test_method_doc``
  Replaces ``_testMethodDoc``

``_test_method_name``
  Replaces ``_testMethodName``

``failure_exception``
  Replaces ``failureException``

``count_test_cases(…)``
  Replaces ``countTestCases(…)``

``default_test_result(…)``
  Replaces ``defaultTestResult(…)``

``assert_true(…)``
  Replaces ``assertTrue(…)``

``assert_false(…)``
  Replaces ``assertFalse(…)``

``assert_almost_equal(…)``
  Replaces ``assertAlmostEqual(…)``

``assert_equal(…)``
  Replaces ``assertEqual(…)``

``assert_not_almost_equal(…)``
  Replaces ``assertNotAlmostEqual(…)``

``assert_not_equal(…)``
  Replaces ``assertNotEqual(…)``

``assert_raises(exc_class, callable_obj, *args, **kwargs)``
  Replaces ``assertRaises(excClass, callableObj, *args, **kwargs)``

``run_test(…)``
  Replaces ``runTest(…)``

``setup(…)``
  Replaces ``setUp(…)``

``short_description(…)``
  Replaces ``shortDescription(…)``

``teardown(…)``
  Replaces ``tearDown(…)``

``FunctionTestCase`` attributes
~~~

``__init__(self, test_func, set_up, tear_down, description)``
  Replaces ``__init__(self, testFunc, setUp, tearDown, description)``

``run_test(…)``
  Replaces ``runTest(…)``

``set_up(…)``
  Replaces ``setUp(…)``

``short_description(…)``
  Replaces ``shortDescription(…)``

``tear_down(…)``
  Replaces ``tearDown(…)``

``TestSuite`` attributes


``add_test(…)``
  Replaces ``

Re: [Python-Dev] [Python-3000] Reminder: beta 2's schedule for tomorrow

[Barry Warsaw]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

I realized that the previous schedule really called for a release  
today 7/15 because I'm a bit busy tomorrow night.  In any event, let's  
try to stick to doing it on 7/16.


- -Barry

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (Darwin)

iQCVAwUBSH012XEjvBPtnXfVAQLJiQQAiP+/S1KVuv9ZgzyS7XdQNW2USTcBGkCh
LIQs3Z+ueuZ9MORdwuDnuZmJWpxataYe26UiPKxt8BFJO81x1i7hy4/uvrO4aE+z
doksz9eJtclNWQNAcvgRX2bKM0OBO57egJrqxYFUgqlziELxOT/U2//josdl3jR1
ovOb/C0nWVU=
=LBea
-END PGP SIGNATURE-
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] [Python-3000] Reminder: beta 2's schedule for tomorrow

[Barry Warsaw]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Jul 15, 2008, at 2:38 PM, Brett Cannon wrote:

On Tue, Jul 15, 2008 at 5:32 AM, Barry Warsaw <[EMAIL PROTECTED]>  
wrote:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

A reminder: the second betas of Python 2.6 and 3.0 are schedule for
tomorrow.  I will try to hang out on #python-dev today and will start
looking at the trackers and buildbots.  Hopefully, we're on track  
to get the

releases out!

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.



The new urllib package landed between the last beta and now, but
without fixers. Issue3316 has potential ones, but they have some
tweaks that need to be made before they are release quality. If the
beta goes out 2to3 will not be able to fix imports for urllib and
urllib2. Don't know if that is enough to hold up the release or just
something to put in the release notes that this will be resolved by
the next beta; made it a release blocker to catch your eye, Barry. =)


I knocked this down to a deferred blocker, so I won't let it hold up  
beta2, though I'd /really/ like to get this cleaned up and committed  
in time.  If I get enough deferred blockers though, I might hold  
things up after all.



Oh, and fixers for test.test_support to test.support is not in either,
but this is probably such a small use case outside the core that I am
not sweating bullets for writing a new fixer just for this one case.


Ok.
- -Barry

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (Darwin)

iQCVAwUBSH02pnEjvBPtnXfVAQL1qgP/a2yf6fagOS7Hvbwd08ZhYkaB+GDTcFMy
mo/bJtvrdCRwPm+60q5mZYuMBIz/I7IBSQmSI09IOdEi0RPoXH6Los3LMrt+Aa6v
XgPu7nYcO1vNa/b+6vNvsBAEPfEuaMJsSRpHNJfAWsjF82BsiNEpJ0D5906CAhyW
MrjaPUb47bs=
=/qoQ
-END PGP SIGNATURE-
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP: Consolidating names and classes in the `unittest`module (updated 2008-07-15)

[Greg Ewing]

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. To my eyes there is no
loss of readability when omitting the underscores,
so simplicity argues for leaving them out.

--
Greg
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] unittest's redundant assertions: asserts vs. failIf/Unlesses

[Steven D'Aprano]

On Tue, 15 Jul 2008 06:32:53 pm Stephen J. Turnbull wrote:
> Steven D'Aprano writes:
>  > 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, got it wrong, then corrected
>  > it, and *still* got it wrong, is telling.
>
> It's telling only if you ignore the fact that it's the ad hominem
> fallacy.

The ad hominem fallacy does not mean "somebody pointed out I made a 
silly mistake". It is not a fallacy to reject a person's argument 
because it is hastily or carelessly made.

However, fair is fair -- I too have to accept a slice of humble pie. In 
*my* haste to make my point, I neglected to actually make the point I 
intended to. I went on to write "It's part of the pattern of this 
thread" but didn't explain why. Namely that with so many people trying 
to push their personal preference, and signs of frustration on both 
sides, people are making unsupported statements of opinion as if they 
were facts, and generally getting sloppy. Ironic, yes?

Having communicated poorly, and by doing so giving you offence, I will 
accept an appropriate fish-slapping.


>  > When it comes to assert* versus fail* tests, this is one case
>  > where I don't believe "one obvious way to do it" should apply.
>
> In the context you were talking about, where you don't need to show
> anybody your tests, I don't see any reason why TOOWTDI should apply.
> In a debugging context, I don't see any reason why it should, either.
>
> But here we're talking about the standard unit-testing framework,
> which is used by Python itself.

But I'm using that same framework, so decisions made regarding that 
framework are going to impact me. Terry Reedy says that "stdlib modules 
are suggestions and examples, not commands", which is strictly true but 
I think he discounts just how strong the stdlib's influence is. Perhaps 
large projects, and tiny ones, are free to go their own way, but in my 
experience (such that it is), small projects tend to follow the stdlib.


> So it *is* about communication with 
> other developers, and it *does* make sense to avoid proliferation of
> redundant vocabulary.

Certainly redundant vocabulary has a cost, but it also has a benefit. At 
least for those people (including myself) who frequently think of a 
unit test as a sequence of potential failures rather than expected 
successes. Only if the code "fails to fail" does it pass the test, and 
so I often find fail* tests more suitable. YMMV.



-- 
Steven
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP: Consolidating names and classes in the `unittest` module (updated 2008-07-15)

[Antoine Pitrou]

> 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 assert* variants, which
implies quite clearly that the fail* variants are on the negative
side ;-))

Regards

Antoine.


___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] [Python-3000] Reminder: beta 2's schedule for tomorrow

[Brett Cannon]

On Tue, Jul 15, 2008 at 4:45 PM, Barry Warsaw <[EMAIL PROTECTED]> wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> On Jul 15, 2008, at 2:38 PM, Brett Cannon wrote:
>
>> On Tue, Jul 15, 2008 at 5:32 AM, Barry Warsaw <[EMAIL PROTECTED]> wrote:
>>>
>>> -BEGIN PGP SIGNED MESSAGE-
>>> Hash: SHA1
>>>
>>> A reminder: the second betas of Python 2.6 and 3.0 are schedule for
>>> tomorrow.  I will try to hang out on #python-dev today and will start
>>> looking at the trackers and buildbots.  Hopefully, we're on track to get
>>> the
>>> releases out!
>>>
>>> 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.
>>>
>>
>> The new urllib package landed between the last beta and now, but
>> without fixers. Issue3316 has potential ones, but they have some
>> tweaks that need to be made before they are release quality. If the
>> beta goes out 2to3 will not be able to fix imports for urllib and
>> urllib2. Don't know if that is enough to hold up the release or just
>> something to put in the release notes that this will be resolved by
>> the next beta; made it a release blocker to catch your eye, Barry. =)
>
> I knocked this down to a deferred blocker, so I won't let it hold up beta2,
> though I'd /really/ like to get this cleaned up and committed in time.  If I
> get enough deferred blockers though, I might hold things up after all.
>

Nick is actively working on it, so it might make it in b2.

-Brett
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP: Consolidating names in the `unittest` module

[Steven D'Aprano]

On Wed, 16 Jul 2008 08:13:22 am Guido van Rossum wrote:

> > Tests in the standard distribution which use the deprecated 
> > style will need to be converted.  Steven d'Aprano claims this is
> > nontrivial (and thus error- prone) in some cases.  I haven't seen
> > that claim denied, and it seems plausible to me.
>
> I'd like to see examples of that (this would be Steven's task if he's
> serious about his assertion). Since the fail and assert names are
> mapped to each other using aliasing I don't see how it could be
> nontrivial to map e.g. self.failIf(x) to self.assertFalse(x) -- these
> are the same function!

I have not knowingly claimed that mechanically swapping fail* to assert* 
tests was difficult. The difficulty I refer to is about readability and 
understanding of the code. I often think about tests as sequences of 
possible failures, and as such my unit tests are most naturally written 
as fail*. It is that mental effort of reversing the sense of the tests 
when reading and writing assert* tests that I refer to.

If you want to declare that fail* must go, I'll be disappointed but life 
will go on. But despite the claims of those who have asserted (pun 
intended) that fail* tests are always more difficult to understand, 
that's not the case for everyone.



-- 
Steven
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP: Consolidating names and classes in the `unittest`module (updated 2008-07-15)

[Gerard flanagan]

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 the trailing 's'
from 'equals').


I think clarity, consistency, and discoverability are more important
criteria than saving a few characters in a method name.


Adding in possible positive and negative forms of the proposed new
methods


A major point of this PEP is to *remove* redundant names in the API.




def it_is_a_truth_universally_recognised_that(...):

def we_are_all_feckin_doomed_unless(...):

should be quite sufficient ;-)

entia-non-sunt-multiplicanda-ly y'rs

G.



___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP: Consolidating names in the `unittest` module

[Collin Winter]

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 sides of the
> divide for 'assert*' versus 'fail*' names.
>
>
> :PEP:   XXX
> :Title: Consolidating names in the `unittest` module
> :Version:   0.2
> :Last-Modified: 2008-07-15
> :Author:Ben Finney <[EMAIL PROTECTED]>
> :Status:Draft
> :Type:  Standards Track
> :Content-Type:  test/x-rst
> :Created:   2008-07-14
> :Python-Version:2.7, 3.1
> :Post-History:
>
>
> ..  contents::
>
>
> Abstract
> 
>
> This PEP proposes to consolidate the names that constitute the API of
> the standard library `unittest` module, with the goal of removing
> redundant names, and conforming with PEP 8.
>
>
> Motivation
> ==
>
> The normal use case for the `unittest` module is to subclass its
> classes, overriding and re-using its functios and methods. This draws
> constant attention to the fact that the existing implementation fails
> several current Python standards:
>
> * It does not conform to PEP 8 [#PEP-8]_, requiring users to write
>  their own non-PEP-8 conformant names when overriding methods, and
>  encouraging extensions to further depart from PEP 8.
>
> * It has many synonyms in its API, which goes against the Zen of
>  Python [#PEP-20]_ (specifically, that "there should be one, and
>  preferably only one, obvious way to do it").
>
>
> Specification
> =
>
> Remove obsolete names
> -
>
> The following module attributes are not documented as part of the API
> and are marked as obsolete in the implementation. They will be
> removed.
>
> * ``_makeLoader``
> * ``getTestCaseNames``
> * ``makeSuite``
> * ``findTestCases``
>
> 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``
> * ``assertEquals``
> * ``assertNotEqual``
> * ``assertNotEquals``
> * ``assertAlmostEqual``
> * ``assertAlmostEquals``
> * ``assertNotAlmostEqual``
> * ``assertNotAlmostEquals``
> * ``assertRaises``
> * ``assert_``
> * ``assertTrue``
> * ``assertFalse``
>
> Conform API with PEP 8
> --
>
> The following names are to be introduced, each replacing an existing
> name, to make all names in the module conform with PEP 8 [#PEP-8]_.
> Each name is shown with the existing name that it replaces.
>
> Where function parameters are to be renamed also, they are shown.
> Where function parameters are not to be renamed, they are elided with
> the ellipse ("…") symbol.
>
> Module attributes
> ~
>
> ``default_test_loader``
>  Replaces ``defaultTestLoader``
>
> ``TestResult`` attributes
> ~
>
> ``add_error(…)``
>  Replaces ``addError(…)``
>
> ``add_result(…)``
>  Replaces ``addResult(…)``
>
> ``add_success(…)``
>  Replaces ``addSuccess(…)``
>
> ``should_stop``
>  Replaces ``shouldStop``
>
> ``start_test(…)``
>  Replaces ``startTest(…)``
>
> ``stop_test(…)``
>  Replaces ``stopTest(…)``
>
> ``tests_run``
>  Replaces ``testsRun``
>
> ``was_successful(…)``
>  Replaces ``wasSuccessful(…)``
>
> ``TestCase`` attributes
> ~~~
>
> ``__init__(self, method_name='run_test')``
>  Replaces ``__init__(self, methodName='runTest')``
>
> ``_test_method_doc``
>  Replaces ``_testMethodDoc``
>
> ``_test_method_name``
>  Replaces ``_testMethodName``
>
> ``failure_exception``
>  Replaces ``failureException``
>
> ``count_test_cases(…)``
>  Replaces ``countTestCases(…)``
>
> ``default_test_result(…)``
>  Replaces ``defaultTestResult(…)``
>
> ``fail_if(…)``
>  Replaces ``failIf(…)``
>
> ``fail_if_almost_equal(…)``
>  Replaces ``failIfAlmostEqual(…)``
>
> ``fail_if_equal(…)``
>  Replaces ``failIfEqual(…)``
>
> ``fail_unless(…)``
>  Replaces ``failUnless(…)``
>
> ``fail_unless_almost_equal(…)``
>  Replaces ``failUnlessAlmostEqual(…)``
>
> ``fail_unless_equal(…)``
>  Replaces ``failUnlessEqual(…)``
>
> ``fail_unless_raises(exc_class, callable_obj, *args, **kwargs)``
>  Replaces ``failUnlessRaises(excClass, callableObj, *args, **kwargs)``
>
> ``run_test(…)``
>  Replaces ``runTest(…)``
>
> ``set_up(…)``
>  Replaces ``setUp(…)``
>
> ``short_description(…)``
>  Replaces ``shortDescription(…)``
>
> ``tear_down(…)``
>  Replaces ``tearDown(…)``
>
> ``FunctionTestCase`` attributes
> ~~~
>
> ``__init__(self, test_func, set_up, tear_down, description)``
>  Replaces ``__init__(self, testFunc, setUp, tearDown, description)``
>
> ``run_test(…)``
>  Replaces ``runTest(…)``
>
> ``set_up(…)``
>  Replaces ``setUp(…)``
>
> ``short_description(…)``
>  Replaces ``shortDescription(…)``
>
> ``tear_down(…)``

[Python-Dev] Bug 3139

[Barry Warsaw]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

But 3139 appears important enough to hold up beta 2.

http://bugs.python.org/issue3139
bytearrays are not thread safe

Can we get this fixed by tomorrow?  Does anybody disagree that we  
should hold up the release for this one?  We don't have much time left  
to fix things like this.


- -Barry

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (Darwin)

iQCVAwUBSH0/MXEjvBPtnXfVAQJoHwP8CFYbafuSTbnVdBBydZJ5k8Fb1L4YYVG/
0ee81N4AiQZ5uGQlk4ywAVBycPa+DMWE+cdrkYiGXkPaarhcOd55dfdvL1Ww6OgO
tor2fh2IxT0ee7gO/vgbyv4ybWsxuPH/9W5O+W2hZkHd60NkJCqpiHlMKGz6caOX
+rwbgqaQOU4=
=8lO1
-END PGP SIGNATURE-
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP: Consolidating names and classes in the `unittest` module (updated 2008-07-15)

[Greg Ewing]

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 programmer really find it hard to guess what these
mean?

--
Greg
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP: Consolidating names and classes in the `unittest`module (updated 2008-07-15)

[Greg Ewing]

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 term
"deny" is strongly linked to its antonym, "permit".


"Deny" also has the meaning of claiming that something is
not true (as in "deny an allegation"). When used that way,
it's not an antonym of "permit".

However, that meaning doesn't quite seem to fit here, as
we don't just want to claim that the condition is false,
but *ensure* that it's false. I can't think of a single
word offhand that means that.

--
Greg
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP: Consolidating names in the `unittest` module

[Michael Foord]

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 removed according
to the schedule for modules in PEP 4 [#PEP-4]_.

While deprecated, use of the deprecated attributes should raise a
``DeprecationWarning``, with a message stating which replacement name
should be used.



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?

Michael

Collin Winter
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/fuzzyman%40voidspace.org.uk
  



--
http://www.ironpythoninaction.com/
http://www.voidspace.org.uk/
http://www.trypython.org/
http://www.ironpython.info/
http://www.theotherdelia.co.uk/
http://www.resolverhacks.net/

___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

[Python-Dev] PEP: Frequently-requested additional features for the `unittest` module

[Ben Finney]

:PEP:   XXX
:Title: Frequently-requested additional features for the `unittest` 
module
:Version:   0.3
:Last-Modified: 2008-07-16
:Author:Ben Finney <[EMAIL PROTECTED]>
:Status:Draft
:Type:  Standards Track
:Content-Type:  test/x-rst
:Requires:  PEP XXX (Consolidating names in the `unittest` module)
:Created:   2008-07-14
:Post-History:


..  contents::


Abstract


This PEP proposes frequently-requested additions to the standard
library `unittest` module that are natural extensions of its existing
functionality.


Motivation
==

The `unittest` module is functionally complete. Nevertheless, many
users request and devise extensions to perform functions that are so
common they deserve to be in the standard module.


Specification
=

New condition tests
---

The following test methods will be added to the ``TestCase`` class.
The function signature is part of this specification. The body is to
be treated as a reference implementation only; any functionally
identical implementation also meets this specification.

::

import operator
import re

class TestCase(object):
# …

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)

def assert_in(container, member, msg=None):
op = operator.__contains__
self.assert_compare_true(op, container, member, msg)

def assert_is(first, second, msg=None):
op = operator.is_
self.assert_compare_true(op, first, second, msg)

def assert_less_than(first, second, msg=None):
op = operator.lt
self.assert_compare_true(op, first, second, msg)

def assert_greater_than(first, second, msg=None):
op = operator.gt
self.assert_compare_true(op, first, second, msg)

def assert_less_than_or_equal(first, second, msg=None):
op = operator.le
self.assert_compare_true(op, first, second, msg)

def assert_greater_than_or_equal(first, second, msg=None):
op = operator.ge
self.assert_compare_true(op, first, second, msg)

def assert_members_equal(first, second, msg=None):
self.assert_equal(set(first), set(second), msg)

def assert_sequence_equal(first, second, msg=None):
self.assert_equal(list(first), list(second), msg)

def assert_raises_with_message_regex(
exc_class, message_regex, callable_obj, *args, **kwargs):
exc_name = exc_class.__name__
message_pattern = re.compile(message_regex)
try:
callable_obj(*args, **kwargs)
except exc_class, exc:
exc_message = str(exc)
if not message_pattern.match(exc_message):
msg = (
"%(exc_name)s raised"
" without message matching %(message_regex)r"
" (got message %(exc_message)r)"
) % vars()
raise self.failure_exception(msg)
else:
msg = "%(exc_name)s not raised" % vars()
raise self.failure_exception(msg)

The following test methods are also added. Their implementation in
each case is simply the logical inverse of a corresponding method
above.

::

def assert_compare_false(op, first, second, msg=None):
# Logical inverse of assert_compare_true

def assert_not_in(container, member, msg=None):
# Logical inverse of assert_in

def assert_is_not(first, second, msg=None)
# Logical inverse of assert_is

def assert_not_less_than(first, second, msg=None)
# Logical inverse of assert_less_than

def assert_not_greater_than(first, second, msg=None)
# Logical inverse of assert_greater_than

def assert_not_less_than_or_equal(first, second, msg=None)
# Logical inverse of assert_less_than_or_equal

def assert_not_greater_than_or_equal(first, second, msg=None)
# Logical inverse of assert_greater_than_or_equal

def assert_members_not_equal(first, second, msg=None)
# Logical inverse of assert_members_equal

def assert_sequence_not_equal(first, second, msg=None)
# Logical inverse of assert_sequence_equal

Enhanced failure message for equality tests
---

The equality tests will change their behaviour such that the message
always, even if overridden with a specific message when called,
includes extra information:

* For both ``assert_equal`` and ``assert_not_equal``: the ``repr()``
  output of the objects that were compared.

* For ``assert_equal`` comparisons of ``bas

Re: [Python-Dev] PEP: Frequently-requested additional features for the `unittest` module

[Scott Dial]

Ben Finney wrote:

New condition tests
---

def assert_less_than(first, second, msg=None):
op = operator.lt
self.assert_compare_true(op, first, second, msg)

def assert_greater_than(first, second, msg=None):
op = operator.gt
self.assert_compare_true(op, first, second, msg)

def assert_less_than_or_equal(first, second, msg=None):
op = operator.le
self.assert_compare_true(op, first, second, msg)

def assert_greater_than_or_equal(first, second, msg=None):
op = operator.ge
self.assert_compare_true(op, first, second, msg)

The following test methods are also added. Their implementation in
each case is simply the logical inverse of a corresponding method
above.

def assert_not_less_than(first, second, msg=None)
# Logical inverse of assert_less_than

def assert_not_greater_than(first, second, msg=None)
# Logical inverse of assert_greater_than

def assert_not_less_than_or_equal(first, second, msg=None)
# Logical inverse of assert_less_than_or_equal

def assert_not_greater_than_or_equal(first, second, msg=None)
# Logical inverse of assert_greater_than_or_equal


Why?! Your other PEP is about removing redundant names, and here you 
have introduced 4 of them:


assert_not_less_than = assert_greater_than_or_equal
assert_not_greater_than = assert_less_than_or_equal
assert_not_less_than_or_equal = assert_greater_than
assert_not_greater_than_or_equal = assert_less_than

Besides, ``assert_not_greater_than_or_equal`` is god-awful-long, along 
with the complaints about PEP-8-ifying. I wonder if it would be better 
to abbreviate these names with the *same name* that was used for the 
attribute in the operator module. Let's not reinvent the wheel here..


--
Scott Dial
[EMAIL PROTECTED]
[EMAIL PROTECTED]
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP: Frequently-requested additional features for the `unittest` module

[Ben Finney]

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_less_than_or_equal = assert_greater_than
> assert_not_greater_than_or_equal = assert_less_than

To answer the question: The above tests are logically equivalent, but
the failure message would be different, reporting failure in terms of
what the caller wanted to test.

I se your point though. I'd like to see what others think on this
issue.

> Besides, ``assert_not_greater_than_or_equal`` is god-awful-long,
> along with the complaints about PEP-8-ifying. I wonder if it would
> be better to abbreviate these names with the *same name* that was
> used for the attribute in the operator module. Let's not reinvent
> the wheel here..

Interesting. So you advocate collapsing the above eight tests into the
following four:

assert_lt
assert_gt
assert_le
assert_ge

-- 
 \“I always had a repulsive need to be something more than |
  `\  human.” —David Bowie |
_o__)  |
Ben Finney

___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP: Frequently-requested additional features for the `unittest` module

[Brett Cannon]

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_less_than_or_equal = assert_greater_than
>> assert_not_greater_than_or_equal = assert_less_than
>
> To answer the question: The above tests are logically equivalent, but
> the failure message would be different, reporting failure in terms of
> what the caller wanted to test.
>
> I se your point though. I'd like to see what others think on this
> issue.
>
>> Besides, ``assert_not_greater_than_or_equal`` is god-awful-long,
>> along with the complaints about PEP-8-ifying. I wonder if it would
>> be better to abbreviate these names with the *same name* that was
>> used for the attribute in the operator module. Let's not reinvent
>> the wheel here..
>
> Interesting. So you advocate collapsing the above eight tests into the
> following four:
>
>assert_lt
>assert_gt
>assert_le
>assert_ge

Is any of this really necessary? Isn't this the equivalent of
``assert_(a < b)``? It seems like the only thing you get out of this
is a nicer error message, but ``assert_(a < b, 'not %r <= %s' % (a,
b))`` is not that complex. And do these cases really come up that
often? I would want to see some numbers showing that these are really
necessary (in both usage and people even specifying an error message
in the first place).

-Brett
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP: Frequently-requested additional features for the `unittest` module

[Scott Dial]

Ben Finney wrote:

Scott Dial <[EMAIL PROTECTED]> writes:


Why [introduce redundant test names]?


To answer the question: The above tests are logically equivalent, but
the failure message would be different, reporting failure in terms of
what the caller wanted to test.


I can see how this argument makes sense, and is distinct from the fail* 
vs. assert* discussion. As you say, I'm interested what other think 
about this.



Besides, ``assert_not_greater_than_or_equal`` is god-awful-long,
along with the complaints about PEP-8-ifying. I wonder if it would
be better to abbreviate these names with the *same name* that was
used for the attribute in the operator module. Let's not reinvent
the wheel here..


Interesting. So you advocate collapsing the above eight tests into the
following four:

assert_lt
assert_gt
assert_le
assert_ge


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 
operator is consistent and readable and short, in my opinion.


--
Scott Dial
[EMAIL PROTECTED]
[EMAIL PROTECTED]
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP: Frequently-requested additional features for the `unittest` module

[Ben Finney]

Michael Foord <[EMAIL PROTECTED]> writes:

> The full list of changes proposed […] and not shot down was
> something like:
[…]

>assertLessThan
>assertGreaterThan
>assertLessThanOrEquals
>assertGreaterThanOrEquals
[…]

"Brett Cannon" <[EMAIL PROTECTED]> writes:

> Is any of this really necessary? Isn't this the equivalent of
> ``assert_(a < b)``? It seems like the only thing you get out of this
> is a nicer error message, but ``assert_(a < b, 'not %r <= %s' % (a,
> b))`` is not that complex. And do these cases really come up that
> often? I would want to see some numbers showing that these are
> really necessary (in both usage and people even specifying an error
> message in the first place).

Though I'm the champion of this PEP, I'll have to refer to Michael
Foord for his reasoning (or reference to others' reasoning) on this.

-- 
 \  “The process by which banks create money is so simple that the |
  `\ mind is repelled.” —John Kenneth Galbraith, _Money: Whence It |
_o__)   Came, Where It Went_, 1975 |
Ben Finney

___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP: Consolidating names and classes in the `unittest` module (updated 2008-07-15)

[Ben Finney]

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 already been rebutted, by native
speakers of English. If you don't want to hear "fail is not a negative
word", I can't help you.

This doesn't seem to introduce anything new, so I'll leave the
existing summary of this argument as is in the PEP.

-- 
 \   “Holy unrefillable prescriptions, Batman!” —Robin |
  `\   |
_o__)  |
Ben Finney

___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP: Consolidating names and classes in the `unittest`module (updated 2008-07-15)

[Nick Coghlan]

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 in context. The term
"deny" is strongly linked to its antonym, "permit".


"Deny" also has the meaning of claiming that something is
not true (as in "deny an allegation"). When used that way,
it's not an antonym of "permit".

However, that meaning doesn't quite seem to fit here, as
we don't just want to claim that the condition is false,
but *ensure* that it's false. I can't think of a single
word offhand that means that.


That was the meaning I was going for, but I agree that it doesn't quite 
fit well enough to make it a good idea. There's a reason I put that 
disclaimer at the top of the message :)


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)
  check(x).not_in(y)
  check(x).not_equal(y)

Cheers,
Nick.

--
Nick Coghlan   |   [EMAIL PROTECTED]   |   Brisbane, Australia
---
http://www.boredomandlaziness.org
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP: Consolidating names in the `unittest` module

[Nick Coghlan]

Stephen J. Turnbull wrote:

Ben Finney writes:

 > Removal of ``assert*`` names
 > 

 > Arguments in favour of retaining only the ``assert*`` names:
 > 
 > * BDFL preference: The BDFL has stated [#vanrossum-1]_ a preference

 >   for the ``assert*`` names.
 > 
 > * Precedent: The Python standard library currently uses the

 >   ``assert*`` names by a roughly 8:1 majority over the ``fail*``
 >   names. (Counting unit tests in the py3k tree at 2008-07-15
 >   [#pitrou-1]_.)
 > 
 >   An ad-hoc sampling of other projects that use `unittest` also

 >   demonstrates strong preference for use of the ``assert*`` names
 >   [#bennetts-1]_.
 > 
 > * Positive admonition: The ``assert*`` names state the intent of how

 >   the code under test *should* behave, while the ``fail*`` names are
 >   phrased in terms of how the code *should not* behave.

FWIW, I think these are fairly stated.  So fairly that I'm surprised
you haven't been persuaded!  Nitpick: the second point is not
just "precedent", there's an economic reason there too.  Tests in the
standard distribution which use the deprecated style will need to be
converted.  Steven d'Aprano claims this is nontrivial (and thus error-
prone) in some cases.  I haven't seen that claim denied, and it seems
plausible to me.


I disagree with SdA's statement there: failUnless* maps directly to 
assert* and failIf* maps directly to assertNot*. There are no semantic 
changes whatsoever involved in that remapping, just a change in the 
method names.


Note that if the API is to be rationalised at all, my personal 
preference is to keep assert* and failIf* and get rid of their longer 
counterparts (failUnless* and assertNot*). Alternatively, ditch the 
binary assertion methods entirely, and use a check object to state those 
assertions:


  check(x).almost_equal(y) instead assertAlmostEqual(x, y)

Cheers,
Nick.

--
Nick Coghlan   |   [EMAIL PROTECTED]   |   Brisbane, Australia
---
http://www.boredomandlaziness.org
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP: Frequently-requested additional features for the `unittest` module

[Ben Finney]

Significant changes: Add a new 'TestLoader.load_tests_from_collection'
method, with full reference implementation. This makes the 'run_tests'
reference implementation straightforward.


:PEP:   XXX
:Title: Frequently-requested additional features for the `unittest` 
module
:Version:   0.4
:Last-Modified: 2008-07-16
:Author:Ben Finney <[EMAIL PROTECTED]>
:Status:Draft
:Type:  Standards Track
:Content-Type:  test/x-rst
:Requires:  PEP XXX (Consolidating names in the `unittest` module)
:Created:   2008-07-14
:Post-History:


..  contents::


Abstract


This PEP proposes frequently-requested additions to the standard
library `unittest` module that are natural extensions of its existing
functionality.


Motivation
==

The `unittest` module is functionally complete. Nevertheless, many
users request and devise extensions to perform functions that are so
common they deserve to have a standard implementation.


Specification
=

New condition tests
---

The following test methods will be added to the ``TestCase`` class.
The function signature is part of this specification. The body is to
be treated as a reference implementation only; any functionally
identical implementation also meets this specification.

::

import operator
import re

class TestCase(object):
# …

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)

def assert_in(container, member, msg=None):
op = operator.__contains__
self.assert_compare_true(op, container, member, msg)

def assert_is(first, second, msg=None):
op = operator.is_
self.assert_compare_true(op, first, second, msg)

def assert_less_than(first, second, msg=None):
op = operator.lt
self.assert_compare_true(op, first, second, msg)

def assert_greater_than(first, second, msg=None):
op = operator.gt
self.assert_compare_true(op, first, second, msg)

def assert_less_than_or_equal(first, second, msg=None):
op = operator.le
self.assert_compare_true(op, first, second, msg)

def assert_greater_than_or_equal(first, second, msg=None):
op = operator.ge
self.assert_compare_true(op, first, second, msg)

def assert_members_equal(first, second, msg=None):
self.assert_equal(set(first), set(second), msg)

def assert_sequence_equal(first, second, msg=None):
self.assert_equal(list(first), list(second), msg)

def assert_raises_with_message_regex(
exc_class, message_regex, callable_obj, *args, **kwargs):
exc_name = exc_class.__name__
message_pattern = re.compile(message_regex)
try:
callable_obj(*args, **kwargs)
except exc_class, exc:
exc_message = str(exc)
if not message_pattern.match(exc_message):
msg = (
"%(exc_name)s raised"
" without message matching %(message_regex)r"
" (got message %(exc_message)r)"
) % vars()
raise self.failure_exception(msg)
else:
msg = "%(exc_name)s not raised" % vars()
raise self.failure_exception(msg)

The following test methods are also added. Their implementation in
each case is simply the logical inverse of a corresponding method
above.

::

def assert_compare_false(op, first, second, msg=None):
# Logical inverse of assert_compare_true

def assert_not_in(container, member, msg=None):
# Logical inverse of assert_in

def assert_is_not(first, second, msg=None)
# Logical inverse of assert_is

def assert_not_less_than(first, second, msg=None)
# Logical inverse of assert_less_than

def assert_not_greater_than(first, second, msg=None)
# Logical inverse of assert_greater_than

def assert_not_less_than_or_equal(first, second, msg=None)
# Logical inverse of assert_less_than_or_equal

def assert_not_greater_than_or_equal(first, second, msg=None)
# Logical inverse of assert_greater_than_or_equal

def assert_members_not_equal(first, second, msg=None)
# Logical inverse of assert_members_equal

def assert_sequence_not_equal(first, second, msg=None)
# Logical inverse of assert_sequence_equal

Enhanced failure message for equality tests
---

The equality tests will change their behaviour such that the message
always, even if overridden with a specific message when cal

Re: [Python-Dev] PEP: Consolidating names and classes in the `unittest` module (updated 2008-07-15)

[Terry Reedy]

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 surely constitute an imposition.


I understood Terry's statement as meaning that there is no commandment
to use the standard library 'unittest' module at all. If a user
doesn't like the behaviour of a module (such as 'unittest') in the
standard library, they can accept the burden of implementing one that
behaves the way they like.


I have written the few specialized test functions that I need my current 
project.  I did this after considering (and taking ideas from) py.test. 
 I will also use doctest as a supplement.


I also meant that one who does use something is free to rename it.  I 
commonly import xskjfl as x;-)


___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP: Consolidating names in the `unittest` module

[Terry Reedy]

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 actually is needed, but when it is, 
it should be a unittest-name fixer since previous 3.x code will also 
need fixing.  Since the duplicates are multiples names for the same 
objects, the fixer should be a trivial name substitution.


___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP: Consolidating names and classes in the `unittest`module (updated 2008-07-15)

[Ben Finney]

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)
>   check(x).not_in(y)
>   check(x).not_equal(y)

-1

'check' is even less explicit about what will happen than 'assert'. At
least the latter has existing programming-language connotations of
"fail immediately if not true", which 'check' lacks.

-- 
 \“I used to work in a fire hydrant factory. You couldn't park |
  `\  anywhere near the place.” —Steven Wright |
_o__)  |
Ben Finney

___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Running Py2.6 with the -3 option

[engelbert gruber]

I see mostly ``dict.has_key() not supported in 3.x;`` and sometimes
``DeprecationWarning: callable() not supported in 3.x;`` .

and if someone with commit rights would take i would volunteer to
fix these two on case by case basis, even if it is not my case.

all the best
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com