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

[grubert]

On Wed, 16 Jul 2008, engelbert gruber wrote:


On Wed, Jul 16, 2008 at 7:02 PM, Guido van Rossum <[EMAIL PROTECTED]> wrote:


On Tue, Jul 15, 2008 at 11:50 PM, engelbert gruber
<[EMAIL PROTECTED]> wrote:

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


Good catch, Engelbert.


isnt it that i throw and need someone who catches ?


But why would has_key() need a warning when 2to3 will fix it just fine?


for example, if has_key is the only problem in my module, it is
possible to support py22 to py3 with one source which i think would be
quite handy.


rather naive assumption of me.

anyway i'll file patches on case base.

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

Re: [Python-Dev] Unittest PEP do's and don'ts (BDFL pronouncement)

[Steve Holden]

Guido van Rossum wrote:

On Wed, Jul 16, 2008 at 7:42 PM, Ben Finney <[EMAIL PROTECTED]> wrote:

The result I'm trying to avoid by this is that of having the
externally visible behaviour of functions drift from the promise made
by their names. Either rename the function, or create a new one for
the new functionality.


Oh get over it. This is getting ridiculous. Where did you *get* these
design "principles" you are so fond of? Read the zen of Python and
come back after you've memorized it.

Thank you. I was about to suggest that len() should be renamed 
length_or_raise_exception_if_not_a_container().


But then I did remark (before I stopped adding to this thread's 
interminable length, some aeons ago) that this was getting silly. 
Someone would surely have replied that the proposal had negative 
connotations and the correct name was really 
length_as_long_as_a_container. Or something equally trivial.


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] Proposed unittest changes

[Ben Finney]

"Steven D'Aprano" <[EMAIL PROTECTED]> writes:

> On Tue, 15 Jul 2008 09:26:45 am Raymond Hettinger wrote:
> > From: "Ben Finney" <[EMAIL PROTECTED]>
> >
> > > Right, so I'm putting up a separate PEP just for the renaming.
> > > Should be arriving on this list soon.
> >
> > I would like to work with you or someone else who is interested
> > on an alternative PEP for a separate, simpler test module
> > using the py.test syntax.
> 
> I am interested in this suggestion. I didn't know about py.test.
> 
> I admit to dissatisfaction with unittest (too Java-ish and heavyweight 
> for my tastes). I would love a test suite midway in weight between 
> doctests and unittest, so I will check it out.

I still think 'nose' is a better candidate for this: it appears to
offer what people say they want from 'py.test', yet (unlike 'py.test')
is integrated well with 'unittest'.

-- 
 \ “Pinky, are you pondering what I'm pondering?” “I think so, |
  `\ Brain, but what kind of rides do they have in Fabioland?” |
_o__)   —_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] PEP: Frequently-requested additional features for the `unittest` module

[Scott David Daniels]

Ben Finney wrote:
Scott David Daniels <[EMAIL PROTECTED]> writes:> 

I would rather something more like:

  def assert_compare_true(op, first, second, msg=None):
  if op(first, second):
  return
  raise self.failure_exception(msg)
  if msg is None:
  self.failure_exception("%(first)r %(op)r %(second)"
 % vars())
  self.failure_exception("%(first)r %(op)r %(second): %(msg)"
 % vars())

I'm confused. It appears to me that your version never gets past the
first 'raise' statement, which is unconditional; and the rest seems to
do nothing but instantiate exceptions without using them.


Sorry, I was too hasty last time (had to jet out of the house) and sent
out the unfinished version.  This is what I meant:

 def assert_compare_true(op, first, second, msg=None):
 if op(first, second):
 return
 if msg is None:
 raise self.failure_exception(
"%(first)r %(op)r %(second)" % vars())
 raise self.failure_exception(
"%(first)r %(op)r %(second): %(msg)" % vars())

(1) Displaying args is the whole point, otherwise just use assert_.
This form fosters tests that say what is wrong, and not simply
_that_ something has gone wrong.
The point is a readable test, reducing boilerplate at the
call location.  Something like:
 ...
 self.assert_le(sum(source) // len(source), 5, "Mean OK")

(2) No point to doing string conversion except on failure; slow
__repr__ methods are fine to use if the result is not discarded.

--Scott David Daniels
[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

[Python-Dev] No beta2 tonight

[Barry Warsaw]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

We have green buildbots, yay!  Thanks everyone for that.

However, we still have three release blocker issues that I am not  
comfortable deferring.


3088 test_multiprocessing hangs intermittently on POSIX platforms
3375 _multiprocessing.so build problems
874900 threading module can deadlock after fork

My biggest concern is 3375 and 3088, the latter has a dependency on  
874900.


3375 is very strange since a subsequent 'make' completes just fine.   
This issue happens for me on both OS X 10.5 and Ubuntu 8.04 for py3k.


3088 does not appear to be happening now on OS X or Ubuntu, but the  
issue (and its dependent issue) are not closed, so I'm not sure  
exactly what's going on here.


So we'll give these releases another 24 hours.  Please, if you have  
time see what you can do about resolving these three blockers.  Chat  
with me on #python-dev if you think we should release anyway.  I will  
try to look into 3375, but I'd like to know if anybody else is seeing  
these build failures.


I'll note that I plan to hold the beta3 releases until all release  
blocker and deferred blockers are resolved.


- -Barry

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

iQCVAwUBSH7K+3EjvBPtnXfVAQJPXgQAo+uHlgEEpOqlSYINJuXhTHNRWIQEByAu
RCJZw4jNABKR4Pyero9z2LR31bEWS0Osg8a9DdoeD7bvVmPYyIJCG9bfA3BUwpD8
LtZ1tx9ou/XVGkDD7vQLuTt3hJXSaUvovx4ieeA7OQMiI0Uf3klIny+s2mBFH9IA
COd48C7B/S4=
=tcGt
-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] Proposed unittest changes

[Steven D'Aprano]

On Tue, 15 Jul 2008 09:26:45 am Raymond Hettinger wrote:
> From: "Ben Finney" <[EMAIL PROTECTED]>
>
> > Right, so I'm putting up a separate PEP just for the renaming.
> > Should be arriving on this list soon.
>
> I would like to work with you or someone else who is interested
> on an alternative PEP for a separate, simpler test module
> using the py.test syntax.

I am interested in this suggestion. I didn't know about py.test.

I admit to dissatisfaction with unittest (too Java-ish and heavyweight 
for my tastes). I would love a test suite midway in weight between 
doctests and unittest, so I will check it out.


-- 
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] Unittest PEP do's and don'ts (BDFL pronouncement)

[Ben Finney]

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

> On Wed, Jul 16, 2008 at 7:42 PM, Ben Finney <[EMAIL PROTECTED]> wrote:
> > The result I'm trying to avoid by this is that of having the
> > externally visible behaviour of functions drift from the promise
> > made by their names. Either rename the function, or create a new
> > one for the new functionality.
> 
> Oh get over it. This is getting ridiculous.

Indeed.

> Where did you *get* these design "principles" you are so fond of?

The Zen of Python.

> Read the zen of Python and come back after you've memorized it.

The wonderful thing about the Zen of Python is that I can find support
in it for *all* the contradictory views expresed in these threads.

The Zen needs interpretation by mortals with human judgement in order
to apply its principles.

-- 
 \   "Those who will not reason, are bigots, those who cannot, are |
  `\fools, and those who dare not, are slaves." —“Lord” George |
_o__)Gordon Noel Byron |
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] Unittest PEP do's and don'ts (BDFL pronouncement)

[Guido van Rossum]

On Wed, Jul 16, 2008 at 7:42 PM, Ben Finney <[EMAIL PROTECTED]> wrote:
> The result I'm trying to avoid by this is that of having the
> externally visible behaviour of functions drift from the promise made
> by their names. Either rename the function, or create a new one for
> the new functionality.

Oh get over it. This is getting ridiculous. Where did you *get* these
design "principles" you are so fond of? Read the zen of Python and
come back after you've memorized 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] PEP 3101: floats format 'f' and 'F'

[Guido van Rossum]

On Wed, Jul 16, 2008 at 7:52 PM, Eric Smith
<[EMAIL PROTECTED]> wrote:
> Mark Dickinson wrote:
>>
>> On Wed, Jul 16, 2008 at 4:15 PM, Eric Smith
>> <[EMAIL PROTECTED]> wrote:
>>>
>>> There's no exponent until the number gets large.  I haven't looked up how
>>> big the number has to get.  On my Mac, it's somewhere between 1e50 and
>>> 1e60.
>>
>> I think it's around 1e50, courtesy of the rather oddly-phrased line in
>> unicodeobject.c
>> (this is in py3k) that looks like:
>>
>>if (type == 'f' && (fabs(x) / 1e25) >= 1e25)
>
> I don't know why that test exists.  It comes from Guido in r3417
> (1993-03-16!).  It's from the very first incarnation of formatfloat().
>
> I'd like to remove it, but there's no telling what it would break. Surely
> something written in the last 15+ years depends on it.  But if it were
> removed, then (as Tim points out) only INF and NAN would be in uppercase for
> 'F'.
>
> regrtest.py still works with it removed, except for string_tests.py, which
> is explicitly looking for this behavior, and has this comment:
># The formatfloat() code in stringobject.c and
># unicodeobject.c uses a 120 byte buffer and switches from
># 'f' formatting to 'g' at precision 50, so we expect
># OverflowErrors for the ranges x < 50 and prec >= 67.
>
> The fixed size buffer could be dealt with, but it doesn't seem worth it
> given the potential breakage.
>
> For now, I'll just make 'F' convert to uppercase, and leave the 1e50 issue
> for another release.

It was an attempt to prevent ridiculously long output, with lots of
nonsensical digits suggesting precision that isn't there. Since nobody
in their right mind should use %f for such large numbers anyway,
removing it shouldn't hurt anything, but it might startle users who
try things at the interactive prompt, or who simply have a bug in
their code causing oversized numbers to be produced. So my
recommendation would be to leave it in.

-- 
--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 3101: floats format 'f' and 'F'

[Eric Smith]

Mark Dickinson wrote:

On Wed, Jul 16, 2008 at 4:15 PM, Eric Smith
<[EMAIL PROTECTED]> wrote:

There's no exponent until the number gets large.  I haven't looked up how
big the number has to get.  On my Mac, it's somewhere between 1e50 and 1e60.


I think it's around 1e50, courtesy of the rather oddly-phrased line in
unicodeobject.c
(this is in py3k) that looks like:

if (type == 'f' && (fabs(x) / 1e25) >= 1e25)


I don't know why that test exists.  It comes from Guido in r3417 
(1993-03-16!).  It's from the very first incarnation of formatfloat().


I'd like to remove it, but there's no telling what it would break. 
Surely something written in the last 15+ years depends on it.  But if it 
were removed, then (as Tim points out) only INF and NAN would be in 
uppercase for 'F'.


regrtest.py still works with it removed, except for string_tests.py, 
which is explicitly looking for this behavior, and has this comment:

# The formatfloat() code in stringobject.c and
# unicodeobject.c uses a 120 byte buffer and switches from
# 'f' formatting to 'g' at precision 50, so we expect
# OverflowErrors for the ranges x < 50 and prec >= 67.

The fixed size buffer could be dealt with, but it doesn't seem worth it 
given the potential breakage.


For now, I'll just make 'F' convert to uppercase, and leave the 1e50 
issue for another release.


Eric.
___
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 PEP do's and don'ts (BDFL pronouncement)

[Ben Finney]

Ben Finney <[EMAIL PROTECTED]> writes:

> You're proposing to give "assertRaises" a *new* meaning, without
> changing its name to "assertRaisesAndReturnExceptionIfRaises".

This might be misunderstood, so I'll make it clearer.

The name "assert raises" has a strong (and, per Guido, deliberate)
association with the existing 'assert' statement. So the name makes a
strong promise of what the function will do: raise an exception if the
condition is false, and *have no effect* otherwise.

If the behaviour desired is, instead, to return a value, then that is
an important part of what the function will do and needs to be
reflected in the name. "catch exception" was one suggestion for a
name, another might be "get exception raised".

If the idea is to have a *single* function that does both disparate
things, then the name should definitely state that. That it would
result in an overly long name is a strong indicator that the function
is doing too much and should be split.

The result I'm trying to avoid by this is that of having the
externally visible behaviour of functions drift from the promise made
by their names. Either rename the function, or create a new one for
the new functionality.

-- 
 \“Consider the daffodil. And while you're doing that, I'll be |
  `\  over here, looking through your stuff.” —Jack Handey |
_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] Unittest PEP do's and don'ts (BDFL pronouncement)

[Ben Finney]

Steve Holden <[EMAIL PROTECTED]> writes:

> Yes, but unless I misunderstand you, you don't regard a mass
> renaming of the module's functionality and removal of existing
> aliases as a change to the API.

You slightly misunderstand me. The above changes *are* a change to the
API, by definition. My position is that those changes, which *only*
(and deliberately) change names without changing behaviour, are far
below the threshold that might justify a new module.

> As far as I'm concerned, if I have to alter my code to use the
> updated module you have changed the API. Test code is particularly
> sensitive to such changes.

I agree entirely with this.

-- 
 \ “Smoking cures weight problems. Eventually.” —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] Unittest PEP do's and don'ts (BDFL pronouncement)

[Andrew Bennetts]

Ben Finney wrote:
[...]
> 
> I hope that clarifies it. The name of a thing, in Python especially,
> is very important; in an API, even more so. If the behaviour of the
> function isn't matched by the name, it's a poorly chosen name, a
> poorly designed function, or both.

It doesn't really clarify it for me.  We're both just repeating ourselves,
though.

-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] Unittest PEP do's and don'ts (BDFL pronouncement)

[Steve Holden]

Ben Finney wrote:

Michael Foord <[EMAIL PROTECTED]> writes:


Collecting testcases from the filesystem is a pain. But actually
writing tests (including custom TestCases) using the unittest API is
fine. I find unittest straightforward and readable, I like it.

I don't understand a lot of the criticism comes in for.


For my part, I wanted the redundancies removed and the PEP 8
conformance fixed as a precondition too *any* addition to the unittest
API.

Without those two (and the BDFL's pronouncement at the head of this
thread means they're not an option), I can't see the unittest API
getting anything except increasingly hideous and painful to use.

Yes, but unless I misunderstand you, you don't regard a mass renaming of 
the module's functionality and removal of existing aliases as a change 
to the API. As far as I'm concerned, if I have to alter my code to use 
the updated module you have changed the API. Test code is particularly 
sensitive to such changes.


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 PEP do's and don'ts (BDFL pronouncement)

[Ben Finney]

Andrew Bennetts <[EMAIL PROTECTED]> writes:

> Ben Finney wrote:
> > Andrew Bennetts <[EMAIL PROTECTED]> writes:
> [...]
> > > How is returning None a feature?
> > 
> > A test method having exactly one meaning is a feature. If it's
> > consistent across the API, the API retains a level of simplicity.
> 
> Your reply makes no sense to me.
> 
> I am proposing that it should have exactly one meaning.

You're proposing to give "assertRaises" a *new* meaning, without
changing its name to "assertRaisesAndReturnExceptionIfRaises".

The function name should say *all* that the function does, from the
perspective of the caller. If you're proposing to have the function do
extra things that aren't part of what the name says it will do, then
that deserves either a rename or a new function.

> It seems you have a different meaning of “meaning” than I do,
> which suggests that this conversation is doomed. I hope I don't
> sound hostile, I'm just bewildered. Your argument isn't making any
> sense to me.

I hope that clarifies it. The name of a thing, in Python especially,
is very important; in an API, even more so. If the behaviour of the
function isn't matched by the name, it's a poorly chosen name, a
poorly designed function, or both.

> I can of course keep using TestCase subclasses that override
> assertRaises to be more useful.

Why would you override that function to do something not described by
the name, instead of simply adding a new method that performs this
extra task you want performed?

-- 
 \ “Pinky, are you pondering what I'm pondering?” “I think so, |
  `\ Brain, but isn't a cucumber that small called a gherkin?” |
_o__)   —_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] Unittest PEP do's and don'ts (BDFL pronouncement)

[Raymond Hettinger]

I'd quote “Practicality beats purity”, but I'm not even sure if it
is purity that you have in mind.


From: "Ben Finney" <[EMAIL PROTECTED]>

Close: I'm interested in keeping camel's noses out of tents.


I have no idea what you mean or are trying to accomplish
(unless the camel's nose refers to camelcase).

You could always just fork the unittest module and see if
the masses flock to your version.  That way at least people
will have a choice about whether to accept these new design proclivities.


Raymond 


___
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 PEP do's and don'ts (BDFL pronouncement)

[Fred Drake]

On Jul 16, 2008, at 9:45 PM, Andrew Bennetts wrote:
I am proposing that it should have exactly one meaning.  Callers  
will be free to
ignore the return value if they don't need it, and will see zero  
difference in

behaviour.



Sounds like adding a new method, catchException(...), that returns the  
exception it catches, would be a reasonable compromise.  I can't think  
of any reason that the method that catches-and-returns needs to be the  
existing API, which does something different.


OTOH, I really don't have a problem with doing a try/except/else  
myself if that's what I need.



  -Fred

--
Fred Drake   




___
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 PEP do's and don'ts (BDFL pronouncement)

[Andrew Bennetts]

Ben Finney wrote:
> Andrew Bennetts <[EMAIL PROTECTED]> writes:
[...]
> > How is returning None a feature?
> 
> A test method having exactly one meaning is a feature. If it's
> consistent across the API, the API retains a level of simplicity.

Your reply makes no sense to me.

I am proposing that it should have exactly one meaning.  Callers will be free to
ignore the return value if they don't need it, and will see zero difference in
behaviour.

It seems you have a different meaning of “meaning” than I do, which suggests
that this conversation is doomed.  I hope I don't sound hostile, I'm just
bewildered.  Your argument isn't making any sense to me. 

I can of course keep using TestCase subclasses that override assertRaises to be
more useful.  And I will, because there are no actual downsides that I've seen
any evidence of.  I'd be even happier if the standard library adopted this
improvment, though.

-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] Unittest PEP do's and don'ts (BDFL pronouncement)

[Ben Finney]

Andrew Bennetts <[EMAIL PROTECTED]> writes:

> Ben Finney wrote:
> > Andrew Bennetts <[EMAIL PROTECTED]> writes:
> > 
> > > This one is easily solved by making assertRaises return the
> > > exception it caught.
> > 
> > That breaks one simple feature of the unittest API: that all the
> > test methods will either raise a failure asertion, or return None.
> 
> How is returning None a feature?

A test method having exactly one meaning is a feature. If it's
consistent across the API, the API retains a level of simplicity.

> I've never seen code that somehow depends on assertRaises returning
> None.

I hope never to see code depending on methods named "assert*"
returning something, instead of *only* asserting a condition.

> Further, I have lots of evidence that in practice returning the
> exception instance from assertRaises is not a problem, and is in
> fact quite useful.

I'm sure it's useful. I don't think it belongs in the return value of
such a method.

> I'd quote “Practicality beats purity”, but I'm not even sure if it
> is purity that you have in mind.

Close: I'm interested in keeping camel's noses out of tents.

-- 
 \   “Laugh and the world laughs with you; snore and you sleep |
  `\alone.” —anonymous |
_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] Unittest PEP do's and don'ts (BDFL pronouncement)

[Andrew Bennetts]

Ben Finney wrote:
> Andrew Bennetts <[EMAIL PROTECTED]> writes:
> 
> > This one is easily solved by making assertRaises return the
> > exception it caught.
> 
> That breaks one simple feature of the unittest API: that all the test
> methods will either raise a failure asertion, or return None.

How is returning None a feature?  I've never seen code that somehow depends on
assertRaises returning None.  This “feature” is not documented as being
significant in the unittest module documentation anywhere.  It is not mentioned
anywhere in the *eight* pages of the xUnit Test Patterns book[1] dedicated to
Assertion Methods in their general form.  Where did you get the notion that it
is a feature?

Further, I have lots of evidence that in practice returning the exception
instance from assertRaises is not a problem, and is in fact quite useful.

I'd quote “Practicality beats purity”, but I'm not even sure if it is purity
that you have in mind.  Demanding that assertion methods return None seems like
foolish consistency and dogma.

-Andrew.

[1] _xUnit Test Patterns: Refactoring Test Code_, by Gerard Meszaros.
.
___
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 PEP do's and don'ts (BDFL pronouncement)

[Ben Finney]

Andrew Bennetts <[EMAIL PROTECTED]> writes:

> This one is easily solved by making assertRaises return the
> exception it caught.

That breaks one simple feature of the unittest API: that all the test
methods will either raise a failure asertion, or return None.

-- 
 \   “In case you haven't noticed, [the USA] are now almost as |
  `\ feared and hated all over the world as the Nazis were.” —Kurt |
_o__)   Vonnegut, 2004 |
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] defects submitted by me.

[Guido van Rossum]

Hi Kristjan,

You are doing the right thing. In general, we prefer to have changes
reviewed by a senior committer first. Unfortunately, there is no
guarantee that bugs will get the attention they deserve, since the
senior developers are all pretty busy. Sending email to python-dev is
good, although to really pique folks' interest it would probably be
better to add a 1-2 line summary of each of the items for which you
are hoping to get someone's attention. (And ad the Python version[s]
affected.)

--Guido

On Wed, Jul 16, 2008 at 3:46 PM, Kristján Valur Jónsson
<[EMAIL PROTECTED]> wrote:
> Recently, I have submitted a number of defects (user krisvale)
>
> I do have checkin privileges but since I have been lurking for so long, I
> didn't want to actualhange anything.
>
> Is this the way to proceed?  I notic e that a couple of the defects (3367,
> 3368, 3369) have received attention and are presumabely being worked on, but
> 3327, 3377 and 3378 have not.
>
>
>
> Not that for defect 3377 I have no patch, since I am unclear on where the
> logical error lies.  Also, some of these problem
>
>
>
> Cheers,
>
>
>
> Kristján
>
> ___
> 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/guido%40python.org
>
>



-- 
--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] Unittest PEP do's and don'ts (BDFL pronouncement)

[Andrew Bennetts]

Michael Foord wrote:
> Raymond Hettinger wrote:
[...]
>>
>> If some people want to proceed down the path of "useful additions",
>> I challenge them to think bigger.  Give me some test methods that
>> improve my life.  Don't give me thirty ways to spell something I can
>> already do.
>>
>
> I assert that... the following changes do meet those conditions:
>
> assertRaisesWithMessage - for testing the error messages from library  
> functions, where the error message is part of the API under test (I'm  
> less convinced with the need for a regex matching version myself.)

This one is easily solved by making assertRaises return the exception it caught.
e.g.:

exc = self.assertRaises(AttributeError, getattr, foo, 'bar')
self.assertEqual("'Foo' object has no attribute 'bar'", exc.message)

At least Twisted and bzr have already made this exact change.  It requires no 
new
methods, and is more flexible than the proposed assertRaisesWithMessage.

-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

[Python-Dev] defects submitted by me.

[Kristján Valur Jónsson]

Recently, I have submitted a number of defects (user krisvale)
I do have checkin privileges but since I have been lurking for so long, I 
didn't want to actualhange anything.
Is this the way to proceed?  I notic e that a couple of the defects (3367, 
3368, 3369) have received attention and are presumabely being worked on, but 
3327, 3377 and 3378 have not.

Not that for defect 3377 I have no patch, since I am unclear on where the 
logical error lies.  Also, some of these problem

Cheers,

Kristján
___
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 PEP do's and don'ts (BDFL pronouncement)

[Robert Kern]

Guido van Rossum wrote:

On Wed, Jul 16, 2008 at 2:03 PM, Raymond Hettinger <[EMAIL PROTECTED]> wrote:

From: "Michael Foord" <[EMAIL PROTECTED]>

assertIn / assertNotIn I use very regularly for collection membership

- self.assert_(func(x) in result_set)
+ self.assertIn(func(x), result_set)

Yawn.  The gain is zero.  Actually, it's negative because the second
doesn't read as nicely as the pure python expression.


I disagree. The reason why we have assertEquals(x, y) is that the
error message can show the values of x and y, whereas assert x == y
can't show those. Showing the values can be tremendously useful to
debugging the failure. (Doing an intelligent comparison, e.g. a string
or list "diff" instead of showing the two values, can be even more
useful, and I'd be in favor of that rather than adding new methods
like assertListsEqual.)

(Titus asks if the assert statement could be adjusted to do better
reporting. But that's not going to happen -- it would require a
tremendous amount of compiler support that would have to be
implemented in every Python implementation (last I counted there were
at least five). In addition, python -O removes all asserts from your
code -- that's why we use assertXxx functions in the first place.)


The assert statement itself does not have to be modified. nose and py.test are 
already capable of picking out the variables used in a failing assert expression 
and print them out. For example:



[~]$ cat test_nicefail.py
def test_nicefail():
x = 12
assert x == 10

[~]$ nosetests --detailed-errors test_nicefail.py
F
==
FAIL: test_nicefail.test_nicefail
--
Traceback (most recent call last):
  File 
"/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/site-packages/nose-0.10.3-py2.5.egg/nose/case.py", 
line 182, in runTest

self.test(*self.arg)
  File "/Users/rkern/test_nicefail.py", line 3, in test_nicefail
assert x == 10
AssertionError:
12 = 12
>>  assert 12 == 10


--
Ran 1 test in 0.044s

FAILED (failures=1)


[~]$ py.test test_nicefail.py
== test process starts ===
executable: 
/Library/Frameworks/Python.framework/Versions/2.5/Resources/Python.app/Contents/MacOS/Python 
 (2.5.1-final-0)
using py lib: 
/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/site-packages/py 



test_nicefail.py[1] F

__
___ entrypoint: test_nicefail 

def test_nicefail():
x = 12
E   assert x == 10
>   assert 12 == 10

[/Users/rkern/test_nicefail.py:3]
__
 tests finished: 1 failed in 0.09 seconds 

--
Robert Kern

"I have come to believe that the whole world is an enigma, a harmless enigma
 that is made terrible by our own mad attempt to interpret it as though it had
 an underlying truth."
  -- Umberto Eco

___
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] accepted bytearray items -- integers or numbers?

[Guido van Rossum]

On Wed, Jul 16, 2008 at 4:20 PM, Georg Brandl <[EMAIL PROTECTED]> wrote:
> Guido van Rossum schrieb:
>>
>> On Wed, Jul 16, 2008 at 2:48 PM, Georg Brandl <[EMAIL PROTECTED]> wrote:
>>>
>>> Currently, most mutating bytearray methods only accept integers
>>> as items (in 3k, in 2.6 they also accept single-char strings, for
>>> a reason I can't remember).
>>>
>>> Single-index assignment accepts anything compatible with
>>> operator.index(). This should be made consistent, but in which
>>> direction?
>>
>> I think they should all made to go through operator.index().
>>
>> BTW, looking at the 3.0 code, I was initially a little confused. While
>> the term 'item' generally refers to the value of a list or sequence,
>> several functions in bytearrayobject.c seem to be using it for an
>> argument that can be either an index or a slice. Notably
>> bytes_subscript() and bytes_ass-subscript() have this confusing
>> terminology. This is unrelated but you might want to fix this too.
>
> OK, fixed in trunk and 3k. One consequence is that bytearray("xyz")
> is no error in 2.6 -- I hope this is what was intended in the first place.

Yes, since this is how you spell bytearray(b"xyz") in 2.6. :-)

-- 
--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] Unittest PEP do's and don'ts (BDFL pronouncement)

[Guido van Rossum]

On Wed, Jul 16, 2008 at 3:52 PM, Ben Finney <[EMAIL PROTECTED]> wrote:
> For my part, I wanted the redundancies removed and the PEP 8
> conformance fixed as a precondition too *any* addition to the unittest
> API.

That seems an unproductive attitude towards backwards incompatibility.
I'm glad you see the incompatibility with the way we do business here
though.

-- 
--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: Frequently-requested additional features for the `unittest` module (version 0.5)

[Georg Brandl]

Ben Finney schrieb:

Significant changes: targeting Python 3.1, removal of separate
{lt,gt,le,ge} comparison tests, implementation of enhanced-information
failure message, reference to BDFL pronouncement.

I won't be working on this further; someone else should feel free to
champion this further if they wish.


Note that even if it is abandoned, it should be submitted to [EMAIL PROTECTED]
at some point to become an official PEP.

Georg

___
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] accepted bytearray items -- integers or numbers?

[Georg Brandl]

Guido van Rossum schrieb:

On Wed, Jul 16, 2008 at 2:48 PM, Georg Brandl <[EMAIL PROTECTED]> wrote:

Currently, most mutating bytearray methods only accept integers
as items (in 3k, in 2.6 they also accept single-char strings, for
a reason I can't remember).

Single-index assignment accepts anything compatible with
operator.index(). This should be made consistent, but in which
direction?


I think they should all made to go through operator.index().

BTW, looking at the 3.0 code, I was initially a little confused. While
the term 'item' generally refers to the value of a list or sequence,
several functions in bytearrayobject.c seem to be using it for an
argument that can be either an index or a slice. Notably
bytes_subscript() and bytes_ass-subscript() have this confusing
terminology. This is unrelated but you might want to fix this too.


OK, fixed in trunk and 3k. One consequence is that bytearray("xyz")
is no error in 2.6 -- I hope this is what was intended in the first place.

Georg

___
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 (version 0.5)

[Ben Finney]

Significant changes: targeting Python 3.1, removal of separate
{lt,gt,le,ge} comparison tests, implementation of enhanced-information
failure message, reference to BDFL pronouncement.

I won't be working on this further; someone else should feel free to
champion this further if they wish.


:PEP:   XXX
:Title: Frequently-requested additional features for the `unittest` 
module
:Version:   0.5
: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
:Python-Version:3.1
: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):
fail_detail = "%(first)r %(op)r %(second)r" % vars()
if msg is None:
msg = fail_detail
else:
msg = "%(fail_detail)s: %(msg)s" % 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_members_equal(first, second, msg=None):
op = operator.eq
self.assert_compare_true(op, set(first), set(second), msg)

def assert_sequence_equal(first, second, msg=None):
op = operator.eq
self.assert_compare_true(op, 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_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 comparison tests
-

The comparison 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. This matches the behaviour
  of ``assert_compare_true`` and ``assert_compare_false``, above.

* For ``assert_equal`` comparisons of ``basestring`` instances that
  are multi-line text: the output of ``diff`` comparing the two texts.

* For membership comparisons with ``assert_members_equal`` and
  ``assert_sequence_equal``: the ``repr()`` output of the members that
  were not equal in each collection. (This change is not done for the
  corresponding ``assert_*_not_equal`` tests, which only fail if the
  collection members are equal.)

Simple invocation of test collect

[Python-Dev] PEP: Consolidating names and in the `unittest` module (version 0.4) - REJECTED

[Ben Finney]

Significant changes: now targets only Python 3.1, and recording the
new status (and rationale) as rejected by BDFL pronouncement.

Feel free to mine for ideas.


:PEP:   XXX
:Title: Consolidating names in the `unittest` module
:Version:   0.4
:Last-Modified: 2008-07-17
:Author:Ben Finney <[EMAIL PROTECTED]>
:Status:Rejected
:Type:  Standards Track
:Content-Type:  test/x-rst
:Created:   2008-07-14
:Python-Version: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 functions 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`_, 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 `PEP 20`_.


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`_. 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 ``addTest(…)``

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

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

``TestLoade

Re: [Python-Dev] Unittest PEP do's and don'ts (BDFL pronouncement)

[Ben Finney]

Michael Foord <[EMAIL PROTECTED]> writes:

> Collecting testcases from the filesystem is a pain. But actually
> writing tests (including custom TestCases) using the unittest API is
> fine. I find unittest straightforward and readable, I like it.
> 
> I don't understand a lot of the criticism comes in for.

For my part, I wanted the redundancies removed and the PEP 8
conformance fixed as a precondition too *any* addition to the unittest
API.

Without those two (and the BDFL's pronouncement at the head of this
thread means they're not an option), I can't see the unittest API
getting anything except increasingly hideous and painful to use.

-- 
 \ “Never do anything against conscience even if the state demands |
  `\ it.” —Albert Einstein |
_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] Unittest PEP do's and don'ts (BDFL pronouncement)

[Ben Finney]

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

> Having skimmed much material about proposed changes to the venerable
> unitest module, I'd like to set some boundaries. PEPs that don't
> follow the following rules are very unlikely to be accepted.

Thanks for giving the attention to this topic and producing a
pronouncement.

> 1. The API is not going to be renamed to PEP-8 conformance.
[...]

> 3. I like assertEqual better than failUnlessEqual (and similar for
> all assert* versions in favor of their fail* alias), and I don't
> like that there is both assertEqual and assertEquals. But rule #1
> means we have to live with the aliases. At best we can discourage
> the undesirables by documenting them out of existence.

These two together kill any interest I have in being PEP champion for
unittest changes, or on putting effort into the changes.

Thanks, everyone, for the lively discussion.

-- 
 \  “The way to build large Python applications is to componentize |
  `\ and loosely-couple the hell out of everything.” —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

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

[Terry Reedy]

Tres Seaver wrote:

-BEGIN PGP SIGNED MESSAGE-



If camelCase / duplicated names are such a pain, write a *new* module,
'unittest2', and port Python's tests to use it, thereby leaving the much
larger volume of not-in-Python tests still working.  One might then
remove the 'unittest' module in a later release, packaging it as a
standalone distibution for the projects which still need it.


There was, at one time at least, some degree of consensus for dropping 
the Fail names and keeping the Assert names, which appear to comprise 
75%-80% of usage 'in the wild'.  There seems to less consensus on also 
changing the Assert names from CamelCase to under_score versions.  So I 
was also thinking about a 'unittest2', recommended for new projects and 
gradual changeover of the Python test suite.  'Unittest' could be left 
unchanged but gradually disrecommended, deprecated, and removed (perhaps 
in 4.0 if not before).


___
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 PEP do's and don'ts (BDFL pronouncement)

[Collin Winter]

On Wed, Jul 16, 2008 at 2:03 PM, Raymond Hettinger <[EMAIL PROTECTED]> wrote:
>>> If some people want to proceed down the path of "useful additions",
>>> I challenge them to think bigger.  Give me some test methods that
>>> improve my life.  Don't give me thirty ways to spell something I can
>>> already do.
>
> From: "Michael Foord" <[EMAIL PROTECTED]>
>>
>> I assert that... the following changes do meet those conditions:
>>
>> assertRaisesWithMessage
>
> . . .
>>
>> Changes to assertEquals so that the failure messages are more useful
>
> ...
>>
>> assertIn / assertNotIn I use very regularly for collection membership
>
> - self.assert_(func(x) in result_set)
> + self.assertIn(func(x), result_set)
>
> Yawn.  The gain is zero.  Actually, it's negative because the second
> doesn't read as nicely as the pure python expression.

It's only negative if the method doesn't do anything special. For
example, an assertListEqual() method can tell you *how* the lists
differ, which the pure Python expression can't -- all the Python
expression can say is "yes" or "no". We have methods like this at work
and they're very useful.

That said, I see no reason why these things have to be methods. The
self. method boilerplate is cluttering line-noise in this case.  I can
easily imagine a module of nothing but comparison functions.

Collin Winter

> Think bigger!  No fat APIs.  Do something cool!  Checkout the
> dynamic test creation in test_decimal to see if it can be generalized.
> Give me some cool test runners.  Maybe find a way to automatically
> launch pdb or to dump the locals variables at the time of failure.
> Maybe move the "test_*.py" search into the unittest module.
>
> We want *small* and powerful.  The api for TestCase instances is
> already way too fat.  See an old discussion on the subject at:
>  http://bugs.python.org/issue2578
>
>
>> The run_tests function for running collections of tests. Almost every
>> project I've worked on has had an ad-hoc imnplementation of this, collecting
>> test modules and turning them into a suitable collection for use with
>> unittest.
>
> Now, that's more like it.Propose more cool stuff like this and
> the module really will be improved.
>
>
>> assertIs / assertIsNot also sounds good, but is not something I would miss
>> if they weren't added.
>
> Doh!  We're back to replacing clean expressions using pure python syntax
> with a method name equivalent.  That's a step backwards.
>
>
>
> Raymond
> ___
> 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/collinw%40gmail.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 PEP do's and don'ts (BDFL pronouncement)

[C. Titus Brown]

On Wed, Jul 16, 2008 at 10:37:46PM +0100, Michael Foord wrote:
-> >test_sort2.py :
-> >
-> > def test_me():
-> >seq = [ 5, 4, 1, 3 2 ]
-> >seq.sort()
-> >assert seq == [1, 2, 3, 4, 5]
-> >
-> >The *only value* that unittest adds here is in the 'assertEqual'
-> >statement, which (I think) returns a richer error message than 'assert'.
-> 
-> But if you exclude the import and class definition (two lines), then the 
-> test methods themselves are identical - except with unittest you have 
-> the advantage of the 'assertEquals' error collecting and reporting.
-> 
-> The boilerplate at the end is useful for running the test file in 
-> isolation, but you don't include anything comparable in the second example.

You omit import and class definition (two lines), as well as 'self' in
every function definition.  And don't forget the multiple levels of
indentation -- that's a fair amount of gratuitous typing & boilerplate,
IMO.

With nose and py.test you always have a test runner and you can run the
tests with

nosetests test_sort2.py

which to my mind is better than having it be the default __main__
function, anyway.

-> >If I could run the second program by doing
-> >
-> >unittest.discover_tests('test_sort2.py')
-> >
-> >I would be a very happy man... right now it requires installing nose or
-> >py.test.
-> >
-> What about if you could run all tests in a project (of the first kind) with:
-> 
-> tests = unittest.discover_tests('path/', filter='*test.py')
-> unittest.run_tests(tests)
-> 
-> (or even just the first line).

I would very much like that, although I think some sensible defaults
would let you omit the filter and path in obvious cases (test_*.py and
cwd, basically).

I think the exact test discovery behavior is solved in similar ways by the
py.test and nose folks, and the GCD of these solutions would provide a
good baseline for unittest.  Having *one* Python-general way to name
your test files and test functions/classes that is also compatible
across nose, py.test, and unittest would be a real gain for Python, IMO.

You could even set the default unittest __main__ to run the
discover_tests function, e.g.

python -m unittest [ []]

or some such...

cheers,
--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] Unittest PEP do's and don'ts (BDFL pronouncement)

[Leonardo Santagada]

On 16/07/2008, at 18:24, Guido van Rossum wrote:



Think bigger!  No fat APIs.  Do something cool!  Checkout the
dynamic test creation in test_decimal to see if it can be  
generalized.

Give me some cool test runners.  Maybe find a way to automatically
launch pdb or to dump the locals variables at the time of failure.
Maybe move the "test_*.py" search into the unittest module.


Those ideas are cool too.



all those features are already implemented in py.test and most  
probably also on nose. Why not just port those to unittest? is this  
even being considered?



--
Leonardo Santagada



___
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] accepted bytearray items -- integers or numbers?

[Guido van Rossum]

On Wed, Jul 16, 2008 at 2:48 PM, Georg Brandl <[EMAIL PROTECTED]> wrote:
> Currently, most mutating bytearray methods only accept integers
> as items (in 3k, in 2.6 they also accept single-char strings, for
> a reason I can't remember).
>
> Single-index assignment accepts anything compatible with
> operator.index(). This should be made consistent, but in which
> direction?

I think they should all made to go through operator.index().

BTW, looking at the 3.0 code, I was initially a little confused. While
the term 'item' generally refers to the value of a list or sequence,
several functions in bytearrayobject.c seem to be using it for an
argument that can be either an index or a slice. Notably
bytes_subscript() and bytes_ass-subscript() have this confusing
terminology. This is unrelated but you might want to fix this too.

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

[Python-Dev] accepted bytearray items -- integers or numbers?

[Georg Brandl]

Currently, most mutating bytearray methods only accept integers
as items (in 3k, in 2.6 they also accept single-char strings, for
a reason I can't remember).

Single-index assignment accepts anything compatible with
operator.index(). This should be made consistent, but in which
direction?

Georg

___
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 PEP do's and don'ts (BDFL pronouncement)

[Georg Brandl]

C. Titus Brown schrieb:


Sorry for the second message, but... let's compare:

test_sort.py:
 #! /usr/bin/env python
 import unittest
 class Test(unittest.TestCase):
  def test_me(self):
 seq = [ 5, 4, 1, 3, 2 ]
 seq.sort()
 self.assertEqual(seq, [1, 2, 3, 4, 5])

 if __name__ == '__main__':
unittest.main()

with

test_sort2.py :

 def test_me():
seq = [ 5, 4, 1, 3 2 ]
seq.sort()
assert seq == [1, 2, 3, 4, 5]

The *only value* that unittest adds here is in the 'assertEqual'
statement, which (I think) returns a richer error message than 'assert'.


If you use py.test, it does some magic to find out your test is an
equality comparison and displays both operands' repr().  Don't know about
nose.

Georg

___
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 PEP do's and don'ts (BDFL pronouncement)

[Michael Foord]

C. Titus Brown wrote:

On Wed, Jul 16, 2008 at 02:15:29PM -0700, C. Titus Brown wrote:
-> At this point I might suggest taking a look at the nose and py.test
-> discovery rules and writing a simple test discovery system to find &
-> wrap 'test_' functions/classes and doctests in a unittest wrapper.
-> 
-> Many people use nose and py.test (which use remarkably similar test

-> discovery procedures, note) and the basic algorithm is pretty well
-> worked out.  And, since nose wraps such tests in unittests anyway, it
-> can be made entirely compatible with pre-existing TestRunner
-> derivatives.

Sorry for the second message, but... let's compare:

test_sort.py:
 #! /usr/bin/env python
 import unittest
 class Test(unittest.TestCase):
  def test_me(self):
 seq = [ 5, 4, 1, 3, 2 ]
 seq.sort()
 self.assertEqual(seq, [1, 2, 3, 4, 5])

 if __name__ == '__main__':
unittest.main()

with

test_sort2.py :

 def test_me():
seq = [ 5, 4, 1, 3 2 ]
seq.sort()
assert seq == [1, 2, 3, 4, 5]

The *only value* that unittest adds here is in the 'assertEqual'
statement, which (I think) returns a richer error message than 'assert'.

  


But if you exclude the import and class definition (two lines), then the 
test methods themselves are identical - except with unittest you have 
the advantage of the 'assertEquals' error collecting and reporting.


The boilerplate at the end is useful for running the test file in 
isolation, but you don't include anything comparable in the second example.




If I could run the second program by doing

unittest.discover_tests('test_sort2.py')

I would be a very happy man... right now it requires installing nose or
py.test.

  

What about if you could run all tests in a project (of the first kind) with:

tests = unittest.discover_tests('path/', filter='*test.py')
unittest.run_tests(tests)

(or even just the first line).

With 'discover_tests' recursively globbing the path provided and 
collecting test files as modules.


Michael




cheers,
--titus
  



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

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

[Stephen J. Turnbull]

Ben Finney writes:
 > "Stephen J. Turnbull" <[EMAIL PROTECTED]> writes:
 > 
 > > The intuition that "fail" is a negative word is thus well-founded in
 > > standard usage.
 > 
 > That's not the same thing as "fail" being a negative word in the sense
 > meant by "double negative".

So what?  This whole exercise is about human psychology.  If it were
just a matter of defining things and we're done, it wouldn't matter
how many identifiers we use or how they're spelled, right?

You should treat those perceptions with respect when writing this kind
of PEP, not deny them outright.

___
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 PEP do's and don'ts (BDFL pronouncement)

[Guido van Rossum]

On Wed, Jul 16, 2008 at 2:03 PM, Raymond Hettinger <[EMAIL PROTECTED]> wrote:
> From: "Michael Foord" <[EMAIL PROTECTED]>
>> assertIn / assertNotIn I use very regularly for collection membership
>
> - self.assert_(func(x) in result_set)
> + self.assertIn(func(x), result_set)
>
> Yawn.  The gain is zero.  Actually, it's negative because the second
> doesn't read as nicely as the pure python expression.

I disagree. The reason why we have assertEquals(x, y) is that the
error message can show the values of x and y, whereas assert x == y
can't show those. Showing the values can be tremendously useful to
debugging the failure. (Doing an intelligent comparison, e.g. a string
or list "diff" instead of showing the two values, can be even more
useful, and I'd be in favor of that rather than adding new methods
like assertListsEqual.)

(Titus asks if the assert statement could be adjusted to do better
reporting. But that's not going to happen -- it would require a
tremendous amount of compiler support that would have to be
implemented in every Python implementation (last I counted there were
at least five). In addition, python -O removes all asserts from your
code -- that's why we use assertXxx functions in the first place.)

> Think bigger!  No fat APIs.  Do something cool!  Checkout the
> dynamic test creation in test_decimal to see if it can be generalized.
> Give me some cool test runners.  Maybe find a way to automatically
> launch pdb or to dump the locals variables at the time of failure.
> Maybe move the "test_*.py" search into the unittest module.

Those ideas are cool too.

-- 
--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] Unittest PEP do's and don'ts (BDFL pronouncement)

[C. Titus Brown]

On Wed, Jul 16, 2008 at 02:15:29PM -0700, C. Titus Brown wrote:
-> At this point I might suggest taking a look at the nose and py.test
-> discovery rules and writing a simple test discovery system to find &
-> wrap 'test_' functions/classes and doctests in a unittest wrapper.
-> 
-> Many people use nose and py.test (which use remarkably similar test
-> discovery procedures, note) and the basic algorithm is pretty well
-> worked out.  And, since nose wraps such tests in unittests anyway, it
-> can be made entirely compatible with pre-existing TestRunner
-> derivatives.

Sorry for the second message, but... let's compare:

test_sort.py:
 #! /usr/bin/env python
 import unittest
 class Test(unittest.TestCase):
  def test_me(self):
 seq = [ 5, 4, 1, 3, 2 ]
 seq.sort()
 self.assertEqual(seq, [1, 2, 3, 4, 5])

 if __name__ == '__main__':
unittest.main()

with

test_sort2.py :

 def test_me():
seq = [ 5, 4, 1, 3 2 ]
seq.sort()
assert seq == [1, 2, 3, 4, 5]

The *only value* that unittest adds here is in the 'assertEqual'
statement, which (I think) returns a richer error message than 'assert'.

If I could run the second program by doing

unittest.discover_tests('test_sort2.py')

I would be a very happy man... right now it requires installing nose or
py.test.

cheers,
--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] Unittest PEP do's and don'ts (BDFL pronouncement)

[Michael Foord]

C. Titus Brown wrote:

[snip..]
Paranthetically, wrt unittest, the world seems to be divided into two
kinds of people : those who find the current API uninspiring but ok, and
those who absolutely hate it.  Has anyone said that they *love* the
current unittest API with all of its boilerplate?  If not, then I think
that says something, no?

--titus
  


Collecting testcases from the filesystem is a pain. But actually writing 
tests (including custom TestCases) using the unittest API is fine. I 
find unittest straightforward and readable, I like it.


I don't understand a lot of the criticism comes in for.

Michael

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

Re: [Python-Dev] Unittest PEP do's and don'ts (BDFL pronouncement)

[C. Titus Brown]

On Wed, Jul 16, 2008 at 02:03:29PM -0700, Raymond Hettinger wrote:
-> - self.assert_(func(x) in result_set)
-> + self.assertIn(func(x), result_set)
-> 
-> Yawn.  The gain is zero.  Actually, it's negative because the second
-> doesn't read as nicely as the pure python expression.

People are proposing these craptastic methods because 'assert' doesn't
do good reporting by default.  Maybe we can fix that instead??

-> >The run_tests function for running collections of tests. Almost every 
-> >project I've worked on has had an ad-hoc imnplementation of this, 
-> >collecting test modules and turning them into a suitable collection for 
-> >use with unittest.
-> 
-> Now, that's more like it.Propose more cool stuff like this and
-> the module really will be improved.

At this point I might suggest taking a look at the nose and py.test
discovery rules and writing a simple test discovery system to find &
wrap 'test_' functions/classes and doctests in a unittest wrapper.

Many people use nose and py.test (which use remarkably similar test
discovery procedures, note) and the basic algorithm is pretty well
worked out.  And, since nose wraps such tests in unittests anyway, it
can be made entirely compatible with pre-existing TestRunner
derivatives.

This steers a middle ground between trying to co-opt py.test and nose
entirely (which no one would be happy with) and leaving the existing
(and hideous, IMO) unittest as the only "standard" option.  It also
helps out people who want to take advantage of some of the niftier
py.test/nosetests features during development but *also* want clean
test code that uses a standard library module.

Let me know if I should expand on this proposal...

Paranthetically, wrt unittest, the world seems to be divided into two
kinds of people : those who find the current API uninspiring but ok, and
those who absolutely hate it.  Has anyone said that they *love* the
current unittest API with all of its boilerplate?  If not, then I think
that says something, no?

--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] Unittest PEP do's and don'ts (BDFL pronouncement)

[Guido van Rossum]

On Wed, Jul 16, 2008 at 1:03 PM, Michael Foord
<[EMAIL PROTECTED]> wrote:
> Guido van Rossum wrote:
>> 2. Radical changes to the API are off the table. If a radically
>> different API is to be accepted, the road to such acceptance is not a
>> design-by-committee PEP, but adoption of a 3rd party module with a
>> multi-year track record. If you have radically different ideas about
>> how to do unittesting, by all means implement them and try them out
>> and try to get a large audience to use them. When you are successful
>> in all that, *then* we'll talk about adoption into the standard
>> library.

> I assume this doesn't rule out the addition of [some of..] the new
> convenience test methods?

Correct.

>> 3. I like assertEqual better than failUnlessEqual (and similar for all
>> assert* versions in favor of their fail* alias), and I don't like that
>> there is both assertEqual and assertEquals. But rule #1 means we have
>> to live with the aliases. At best we can discourage the undesirables
>> by documenting them out of existence.

> Presumably new methods should *not* follow PEP8 but be internally consistent
> with the existing API?

Right again.

> Does this mean that new methods should be added with *both* assert* and
> fail* names?

No, I don't see any reason to perpetuate that particular design snafu.
I said "live with the aliases", not "add more of them".

-- 
--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] Unittest PEP do's and don'ts (BDFL pronouncement)

[Raymond Hettinger]

If some people want to proceed down the path of "useful additions",
I challenge them to think bigger.  Give me some test methods that
improve my life.  Don't give me thirty ways to spell something I can
already do.


From: "Michael Foord" <[EMAIL PROTECTED]>

I assert that... the following changes do meet those conditions:

assertRaisesWithMessage

. . .
Changes to assertEquals so that the failure messages are more useful 

...
assertIn / assertNotIn I use very regularly for collection membership 


- self.assert_(func(x) in result_set)
+ self.assertIn(func(x), result_set)

Yawn.  The gain is zero.  Actually, it's negative because the second
doesn't read as nicely as the pure python expression.

Think bigger!  No fat APIs.  Do something cool!  Checkout the
dynamic test creation in test_decimal to see if it can be generalized.
Give me some cool test runners.  Maybe find a way to automatically
launch pdb or to dump the locals variables at the time of failure.
Maybe move the "test_*.py" search into the unittest module.

We want *small* and powerful.  The api for TestCase instances is
already way too fat.  See an old discussion on the subject at:
  http://bugs.python.org/issue2578


The run_tests function for running collections of tests. Almost every 
project I've worked on has had an ad-hoc imnplementation of this, 
collecting test modules and turning them into a suitable collection for 
use with unittest.


Now, that's more like it.Propose more cool stuff like this and
the module really will be improved.


assertIs / assertIsNot also sounds good, but is not something I would 
miss if they weren't added.


Doh!  We're back to replacing clean expressions using pure python syntax
with a method name equivalent.  That's a step backwards.



Raymond
___
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 PEP do's and don'ts (BDFL pronouncement)

[Michael Foord]

Raymond Hettinger wrote:

From: "Michael Foord" <[EMAIL PROTECTED]>
I assume this doesn't rule out the addition of [some of..] the new 
convenience test methods?


In Kent Beck's book on Test Driven Development, he complains that most 
unittest implementations spawned from his original work have grown far 
too complicated and would be better served by sticking to a simple 
framework for writing and running tests.


Accordlingly, if a new test method gets added, it needs to add some 
signficant new capability.  IMO, little "convenience" methods like

self.assertLessThan() do not meet the criterion.  Polluting the module
with more methods makes it harder to fit into your head and does
little to simplify the task of writing mountains of tests.

If some people want to proceed down the path of "useful additions",
I challenge them to think bigger.  Give me some test methods that
improve my life.  Don't give me thirty ways to spell something I can
already do.



I assert that... the following changes do meet those conditions:

assertRaisesWithMessage - for testing the error messages from library 
functions, where the error message is part of the API under test (I'm 
less convinced with the need for a regex matching version myself.)


Changes to assertEquals so that the failure messages are more useful 
(telling you which member failed the comparison for collections and 
showing a diff for long strings). This improves rather than adds.


assertIn / assertNotIn I use very regularly for collection membership 
tests (although personally I find member, container to be a more 
memorable order for the arguments - assert this is in that. The 
comparison with assertRaises in the PEP is wrong - those parameters are 
ordered so that the arbitrary number of arguments immediately follow the 
callable they belong to.)


The run_tests function for running collections of tests. Almost every 
project I've worked on has had an ad-hoc imnplementation of this, 
collecting test modules and turning them into a suitable collection for 
use with unittest.


These are the most important changes in my opinion.

assertIs / assertIsNot also sounds good, but is not something I would 
miss if they weren't added.


Michael



Raymond



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

Re: [Python-Dev] Unittest PEP do's and don'ts (BDFL pronouncement)

[Raymond Hettinger]

From: "Michael Foord" <[EMAIL PROTECTED]>
I assume this doesn't rule out the addition of [some of..] the new 
convenience test methods?


In Kent Beck's book on Test Driven Development, he complains that most 
unittest implementations spawned from his original work have grown far 
too complicated and would be better served by sticking to a simple 
framework for writing and running tests.


Accordlingly, if a new test method gets added, it needs to add some 
signficant new capability.  IMO, little "convenience" methods like

self.assertLessThan() do not meet the criterion.  Polluting the module
with more methods makes it harder to fit into your head and does
little to simplify the task of writing mountains of tests.

If some people want to proceed down the path of "useful additions",
I challenge them to think bigger.  Give me some test methods that
improve my life.  Don't give me thirty ways to spell something I can
already do.


Raymond
___
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 PEP do's and don'ts (BDFL pronouncement)

[Michael Foord]

Guido van Rossum wrote:

Having skimmed much material about proposed changes to the venerable
unitest module, I'd like to set some boundaries. PEPs that don't
follow the following rules are very unlikely to be accepted.

1. The API is not going to be renamed to PEP-8 conformance. This
notwithstanding the purported outcome of earlier discussions. The
renaming will cause too much grief for 3rd party developers; tracking
down why unittests fail is hard enough without also having to consider
changes to the unittest infrastructure itself. It's not the end of the
world if some standard API doesn't follow the style guide.
  


I'm glad to see a pronouncement.


2. Radical changes to the API are off the table. If a radically
different API is to be accepted, the road to such acceptance is not a
design-by-committee PEP, but adoption of a 3rd party module with a
multi-year track record. If you have radically different ideas about
how to do unittesting, by all means implement them and try them out
and try to get a large audience to use them. When you are successful
in all that, *then* we'll talk about adoption into the standard
library.
  


I assume this doesn't rule out the addition of [some of..] the new 
convenience test methods?



3. I like assertEqual better than failUnlessEqual (and similar for all
assert* versions in favor of their fail* alias), and I don't like that
there is both assertEqual and assertEquals. But rule #1 means we have
to live with the aliases. At best we can discourage the undesirables
by documenting them out of existence.

  
Presumably new methods should *not* follow PEP8 but be internally 
consistent with the existing API?


Does this mean that new methods should be added with *both* assert* and 
fail* names?


Michael

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

Re: [Python-Dev] Unittest PEP do's and don'ts (BDFL pronouncement)

[Benjamin Peterson]

On Wed, Jul 16, 2008 at 2:57 PM, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> Having skimmed much material about proposed changes to the venerable
> unitest module, I'd like to set some boundaries. PEPs that don't
> follow the following rules are very unlikely to be accepted.

So basically, discussion is open for additions and improvements?
Great, I love it!



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

[Python-Dev] Unittest PEP do's and don'ts (BDFL pronouncement)

[Guido van Rossum]

Having skimmed much material about proposed changes to the venerable
unitest module, I'd like to set some boundaries. PEPs that don't
follow the following rules are very unlikely to be accepted.

1. The API is not going to be renamed to PEP-8 conformance. This
notwithstanding the purported outcome of earlier discussions. The
renaming will cause too much grief for 3rd party developers; tracking
down why unittests fail is hard enough without also having to consider
changes to the unittest infrastructure itself. It's not the end of the
world if some standard API doesn't follow the style guide.

2. Radical changes to the API are off the table. If a radically
different API is to be accepted, the road to such acceptance is not a
design-by-committee PEP, but adoption of a 3rd party module with a
multi-year track record. If you have radically different ideas about
how to do unittesting, by all means implement them and try them out
and try to get a large audience to use them. When you are successful
in all that, *then* we'll talk about adoption into the standard
library.

3. I like assertEqual better than failUnlessEqual (and similar for all
assert* versions in favor of their fail* alias), and I don't like that
there is both assertEqual and assertEquals. But rule #1 means we have
to live with the aliases. At best we can discourage the undesirables
by documenting them out of existence.

-- 
--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 in the `unittest` module

[Michael Foord]

Tres Seaver wrote:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

M.-A. Lemburg wrote:
  

On 2008-07-16 02:20, Collin Winter wrote:


On Tue, Jul 15, 2008 at 6:58 AM, Ben Finney <[EMAIL PROTECTED]> wrote:
  

Significant updates include removing all reference to the
(already-resolved) 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


+1 for doing this in 3.1.

-1 for Python 2.7.

The main reason is that there's just too much 2.x code out there
using the API names you are suggesting to change and/or remove
from the module.

Since this is a major change in the unit test API, I'd also like
to suggest that you use a new module name.

This is both a precaution to prevent tests failing due to not having
been upgraded and a way for old code to continue working by adding
the old unittest module on sys.path.

Please note that the required renaming of the methods in existing
tests is not going to be as straight forward as you may think,
since you may well rename method calls into the tested application
rather than just the unit test class method calls if you're not
careful.



  


Do you have production code methods called 'assertEquals' and the like? 
It sounds pretty unlikely to me.


Michael


+1.  I had just groped my way to that counter-proposal myself, for
exactly your reasons.


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

iD8DBQFIfk+W+gerLs4ltQ4RApZlAJ47NVKXxbL/oaYyVZEUgRnnvajm+wCgyOO2
4GbVo2D1eWYcJvpx1yf8bLs=
=2HV6
-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/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

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

[Tres Seaver]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

M.-A. Lemburg wrote:
> On 2008-07-16 02:20, Collin Winter wrote:
>> On Tue, Jul 15, 2008 at 6:58 AM, Ben Finney <[EMAIL PROTECTED]> wrote:
>>> Significant updates include removing all reference to the
>>> (already-resolved) new-style class issue, 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
> 
> +1 for doing this in 3.1.
> 
> -1 for Python 2.7.
> 
> The main reason is that there's just too much 2.x code out there
> using the API names you are suggesting to change and/or remove
> from the module.
> 
> Since this is a major change in the unit test API, I'd also like
> to suggest that you use a new module name.
> 
> This is both a precaution to prevent tests failing due to not having
> been upgraded and a way for old code to continue working by adding
> the old unittest module on sys.path.
> 
> Please note that the required renaming of the methods in existing
> tests is not going to be as straight forward as you may think,
> since you may well rename method calls into the tested application
> rather than just the unit test class method calls if you're not
> careful.

+1.  I had just groped my way to that counter-proposal myself, for
exactly your reasons.


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

iD8DBQFIfk+W+gerLs4ltQ4RApZlAJ47NVKXxbL/oaYyVZEUgRnnvajm+wCgyOO2
4GbVo2D1eWYcJvpx1yf8bLs=
=2HV6
-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)

[Tres Seaver]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Ben Finney wrote:
> "Stephen J. Turnbull" <[EMAIL PROTECTED]> writes:
> 
>> Terry Reedy writes:
>>
>>  > For the community as a whole, all stdlib modules are suggestions
>>  > and examples, not commands.
>>
>> Well, even if "standard" is too strong a 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.

One might argue that making gratutiously backward-incompatible changes
to the existing 'unittest' module should fall under that heading:
stability in that package is going to be crucial for projects which have
any hope of making it across the 2-to-3 gulf, and they won't all get
there at once.

If camelCase / duplicated names are such a pain, write a *new* module,
'unittest2', and port Python's tests to use it, thereby leaving the much
larger volume of not-in-Python tests still working.  One might then
remove the 'unittest' module in a later release, packaging it as a
standalone distibution for the projects which still need it.


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

iD8DBQFIfk2/+gerLs4ltQ4RAjd7AJ4iRGnOp+Udw9Jth/VtdMJhJWL50QCePUEY
O1fn7KSSIfIGr0HbIX2xl74=
=s0m/
-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 3101: floats format 'f' and 'F'

[Eric Smith]

Guido van Rossum wrote:


It shares code with %-formatting.  Change that, too?  I couldn't find any
occurrences of %F in the stdlib.  Not that that's the entire universe, of
course.

The change is slightly less elegant if I don't change %-formatting, but
still doable, especially if the betas don't get cut today.


Fine with me to change %F as well -- after all that's where the
misunderstanding comes from. (More and more I'm beginning to think it
was my mistake. :-)


I added this as 
http://mail.python.org/pipermail/python-dev/2008-July/081242.html


I should be able to get it checked in today.

Eric.

___
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 3101: floats format 'f' and 'F'

[Tim Peters]

[Guido]
> My best guess as to why 'F' is the same as 'f' is that somebody
> (could've been me :-) thought, like several others in this thread,
> that %f never prints an exponent. I agree that making it emit an 'E'
> when an exponent is used is the right thing to do. Do it now!

The C standard doesn't allow for %f (or %F) to produce an exponent.
That appears to be a Python innovation.  People should try their
examples under their native C compiler instead (best I can tell, the
idea that %f/%F can produce an exponent came only from running Python
examples, never from running C examples).

For example,

"""
#include 

int main() {
printf("%f\n", 1e300);
}
"""

Under the Cygwin gcc, that displays (the admittedly atrocious, but
that's why people shouldn't use %f inappropriately to begin with ;-)):

1525047602552044202487044690

0.00

As far as C is concerned, the only difference between %f and %F is:

The F conversion specifier  produces INF, INFINITY, or NAN instead of inf,
infinity, or nan, respectively
___
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]

On Wed, Jul 16, 2008 at 7:02 PM, Guido van Rossum <[EMAIL PROTECTED]> wrote:

> On Tue, Jul 15, 2008 at 11:50 PM, engelbert gruber
> <[EMAIL PROTECTED]> wrote:
>> I see mostly ``dict.has_key() not supported in 3.x;`` and sometimes
>> ``DeprecationWarning: callable() not supported in 3.x;`` .
>
> Good catch, Engelbert.
>
> But why would has_key() need a warning when 2to3 will fix it just fine?

for example, if has_key is the only problem in my module, it is
possible to support py22 to py3 with one source which i think would be
quite handy.

and for this the warning is great.
___
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 3101: floats format 'f' and 'F'

[Guido van Rossum]

On Wed, Jul 16, 2008 at 10:30 AM, Eric Smith
<[EMAIL PROTECTED]> wrote:
> Guido van Rossum wrote:
>>
>> On Wed, Jul 16, 2008 at 7:35 AM, Eric Smith
>> <[EMAIL PROTECTED]> wrote:
>>>
>>> Does anyone know why 'F' is the same as 'f'?  Wouldn't it make more sense
>>> to
>>> either drop it, or make it convert the exponent to upper case (like 'E'
>>> and
>>> 'G')?  Compatibility with %-formatting is the only reason I can think of
>>> to
>>> keep up, but I get the sense we've given up on an automatic conversion
>>> from
>>> %-formatting to str.format().  Plus, I can find no uses of '%F' in the
>>> standard library.
>>
>> My best guess as to why 'F' is the same as 'f' is that somebody
>> (could've been me :-) thought, like several others in this thread,
>> that %f never prints an exponent. I agree that making it emit an 'E'
>> when an exponent is used is the right thing to do. Do it now!
>>
>
> It shares code with %-formatting.  Change that, too?  I couldn't find any
> occurrences of %F in the stdlib.  Not that that's the entire universe, of
> course.
>
> The change is slightly less elegant if I don't change %-formatting, but
> still doable, especially if the betas don't get cut today.

Fine with me to change %F as well -- after all that's where the
misunderstanding comes from. (More and more I'm beginning to think it
was my mistake. :-)

-- 
--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 3101: floats format 'f' and 'F'

[Eric Smith]

Guido van Rossum wrote:

On Wed, Jul 16, 2008 at 7:35 AM, Eric Smith
<[EMAIL PROTECTED]> wrote:

Does anyone know why 'F' is the same as 'f'?  Wouldn't it make more sense to
either drop it, or make it convert the exponent to upper case (like 'E' and
'G')?  Compatibility with %-formatting is the only reason I can think of to
keep up, but I get the sense we've given up on an automatic conversion from
%-formatting to str.format().  Plus, I can find no uses of '%F' in the
standard library.


My best guess as to why 'F' is the same as 'f' is that somebody
(could've been me :-) thought, like several others in this thread,
that %f never prints an exponent. I agree that making it emit an 'E'
when an exponent is used is the right thing to do. Do it now!



It shares code with %-formatting.  Change that, too?  I couldn't find 
any occurrences of %F in the stdlib.  Not that that's the entire 
universe, of course.


The change is slightly less elegant if I don't change %-formatting, but 
still doable, especially if the betas don't get cut today.


___
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 3101: floats format 'f' and 'F'

[Guido van Rossum]

On Wed, Jul 16, 2008 at 7:35 AM, Eric Smith
<[EMAIL PROTECTED]> wrote:
> Does anyone know why 'F' is the same as 'f'?  Wouldn't it make more sense to
> either drop it, or make it convert the exponent to upper case (like 'E' and
> 'G')?  Compatibility with %-formatting is the only reason I can think of to
> keep up, but I get the sense we've given up on an automatic conversion from
> %-formatting to str.format().  Plus, I can find no uses of '%F' in the
> standard library.

My best guess as to why 'F' is the same as 'f' is that somebody
(could've been me :-) thought, like several others in this thread,
that %f never prints an exponent. I agree that making it emit an 'E'
when an exponent is used is the right thing to do. Do it now!

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

[Guido van Rossum]

On Tue, Jul 15, 2008 at 11:50 PM, engelbert gruber
<[EMAIL PROTECTED]> wrote:
> I see mostly ``dict.has_key() not supported in 3.x;`` and sometimes
> ``DeprecationWarning: callable() not supported in 3.x;`` .

Good catch, Engelbert.

But why would has_key() need a warning when 2to3 will fix it just fine?

-- 
--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] Proposed unittest changes

[Ron Adam]

Ben Finney wrote:

Ron Adam <[EMAIL PROTECTED]> writes:


+1 for a simpler testing module.


I've no objection.


Just letting you know there is interest in a lighter weight testing
suite.


'doctest' is a very simple testing module, that is a very useful tool.


Looking at the unittest discussions, it doesn't look like it is
getting easier to use, but more complex.


How so?

One PEP proposed this week specifies to do nothing but conform
'unittest' with the standard library guidelines, and remove redundant
names. That surely makes it simpler to use.


No complaint here.  It's a good place to start.



Another PEP specifies to add helper methods that simplify a number of
common cases.


In my opinion adding 19 more methods makes it more complex.

I'd rather see more focus on handling test failures in general without the 
need for so many special helper functions.





What is it you see making unittest "more complex to use"?


More methods and method signatures to learn and remember.


  assert_true(…)

  assert_false(…)

  assert_almost_equal(…)

  assert_equal(…)

  assert_not_almost_equal(…)

  assert_not_equal(…)

  assert_raises(exc_class, callable_obj, *args, **kwargs)

  assert_compare_true(op, first, second, msg=None)

  assert_in(container, member, msg=None)

  assert_is(first, second, msg=None)

  assert_less_than(first, second, msg=None)

  assert_greater_than(first, second, msg=None)

  assert_less_than_or_equal(first, second, msg=None)

  assert_greater_than_or_equal(first, second, msg=None)

  assert_members_equal(first, second, msg=None)

  assert_sequence_equal(first, second, msg=None)

  assert_raises_with_message_regex(exc_class, message_regex,
   callable_obj, *args, **kwargs)

  assert_compare_false(op, first, second, msg=None)

  assert_not_in(container, member, msg=None)

  assert_is_not(first, second, msg=None)

  assert_not_less_than(first, second, msg=None)

  assert_not_greater_than(first, second, msg=None)

  assert_not_less_than_or_equal(first, second, msg=None)

  assert_not_greater_than_or_equal(first, second, msg=None)

  assert_members_not_equal(first, second, msg=None)

  assert_sequence_not_equal(first, second, msg=None)



That comes to 26 variations of assert.



There are really only a small set of basic conditions to test for.

 correct values
 incorrect values
 unexpected exceptions
 correct exceptions
 incorrect exceptions
 missing exceptions


I think the unittest module could better handle testing of exceptions and 
distinguishing exception produced by test code from the code being tested. 
 That was painfully clear (to me) when we where fixing all the Python 3000 
tests.




Py.test looks very interesting, especially the test discovery parts.
I also agree we don't need special methods for every variation of
assertedness.


My main complaint about 'py.test' is that it's yet-another-framework.
We already have 'doctest' and 'unittest', and they play together
reasonably well.


I love doctest.  Because it is very different in how it works, I don't 
think it competes with more formal testing methods.




'nose' http://somethingaboutorange.com/mrl/projects/nose/> looks
better for consideration, especially since it integrates well with
'unittest'.


Thanks for the link!  I'll give 'nose' a try next time I write tests.


I've been thinking that a few decorators may go a long way to making
writing tests easy. It also reduces the level of indentation needed.


There are a number of these already in 'nose'.


Yes, I looked at the decorator and think it is very nice and simple to use.


If something like "nose" was a submodule of unittest, unittest may be able 
to use some of it's parts.  Maybe gradually the more java like unittest 
classes and methods could be depreciated?



Cheers,
   Ron













___
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

[M.-A. Lemburg]

On 2008-07-16 15:12, Ben Finney wrote:

"M.-A. Lemburg" <[EMAIL PROTECTED]> writes:


On 2008-07-16 14:02, Michael Foord wrote:

M.-A. Lemburg wrote:

Note that PEP 4 targets deprecating use of whole modules, not
single APIs, or - like in your case - more or less the complete
existing API of a module.

Which PEP is usually referenced for the deprecation of individual
APIs?

PEP 5 could be used for that.


That seems an even worse fit; it speaks of changing language features,
not library modules. At least PEP 4 talks about when to raise
DeprecationWarning.


Right and the methods described there are usually also applied
to language changes and API changes.

I just wanted to make clear that your "...see PEP 4 for how to handle
backwards compatibility..." statement doesn't apply to the changes
described in your PEP. However, it does point at a possible compromise
which would make the transition easier on everyone.


Adding several 10s of deprecation warnings to the unittest module is
not going to make life easier for anyone. Adding just a single one
on import and following PEP 4 is.


I don't see how the first "is not going to make life easier" if the
second somehow is. Is a programmer going to be helpless in the face of
some DeprecationWarnings but not others?


Using the first method (changing the API names), you force
developers to change existing code, which results in testing
the test code. Lots of work with no real benefit.

With the second method, they can use the new names with new test code
(which then imports the new module). They don't have to test
their existing tests for obscure search&replace errors.


If you do want to apply major changes to a module without changing
the name, then this could be done as part of the 2.x -> 3.x
transition.


This has already been rejected
http://mail.python.org/pipermail/python-dev/2008-April/078485.html>


I wasn't suggesting to apply to the change to 3.0, but instead
suggesting that if you want to implement such a major API change,
this should be done only on the 3.x branch and be dealt with in the
2to3 tool.


I'm inclined to agree that it's not right for 2.x. I'll revise the PEP
accordingly.


Thanks,
--
Marc-Andre Lemburg
eGenix.com

Professional Python Services directly from the Source  (#1, Jul 16 2008)
>>> Python/Zope Consulting and Support ...http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ...http://python.egenix.com/


 Try mxODBC.Zope.DA for Windows,Linux,Solaris,MacOSX for free ! 


   eGenix.com Software, Skills and Services GmbH  Pastor-Loeh-Str.48
D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg
   Registered at Amtsgericht Duesseldorf: HRB 46611
___
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 3101: floats format 'f' and 'F'

[Mark Dickinson]

On Wed, Jul 16, 2008 at 4:15 PM, Eric Smith
<[EMAIL PROTECTED]> wrote:
> There's no exponent until the number gets large.  I haven't looked up how
> big the number has to get.  On my Mac, it's somewhere between 1e50 and 1e60.

I think it's around 1e50, courtesy of the rather oddly-phrased line in
unicodeobject.c
(this is in py3k) that looks like:

if (type == 'f' && (fabs(x) / 1e25) >= 1e25)

In any case, I agree that the current 'F' is strange.  Even after
having read the
relevant line of PEP 3101 several times in the past, part of my brain still
believes that something formatted with 'F' should have all letters appearing
in upper case.

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] PEP 3101: floats format 'f' and 'F'

[Mark Dickinson]

On Wed, Jul 16, 2008 at 4:14 PM, Daniel Stutzbach
<[EMAIL PROTECTED]> wrote:
> There's no exponent for small-magnitude numbers, but still an exponent
> for large-magnitude numbers:
>
 '%f' % (10**100)
> '1e+100'

So there is!  Thanks for the correction.

Mark
___
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 Wed, Jul 16, 2008 at 5:21 AM, Michael Foord
<[EMAIL PROTECTED]> wrote:
> Terry Reedy wrote:
>>
>>
>> Michael Foord wrote:
>>>
>>> Collin Winter wrote:
>>
 Is any provision being made for a 2to3 fixer/otherwise-automated
 transition for the changes you propose here?

>>>
>>> As the 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.
>
> Can 2to3 fixers be used for 2to2 and 3to3 translation then?

The intention is for the infrastructure behind 2to3 to be generally
reusable for other Python source-to-source translation tools, be that
2to2 or 3to3. That hasn't fully materialized yet, but it's getting
there.

Collin
___
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 3101: floats format 'f' and 'F'

[Eric Smith]

Mark Dickinson wrote:

On Wed, Jul 16, 2008 at 3:35 PM, Eric Smith
<[EMAIL PROTECTED]> wrote:

Does anyone know why 'F' is the same as 'f'?  Wouldn't it make more sense to
either drop it, or make it convert the exponent to upper case


What exponent?  Isn't the point of 'f' formatting that there is no exponent?


There's no exponent until the number gets large.  I haven't looked up 
how big the number has to get.  On my Mac, it's somewhere between 1e50 
and 1e60.


$ ./python.exe
Python 3.0b1+ (py3k:64984:64985, Jul 15 2008, 20:17:06)
[GCC 4.0.1 (Apple Inc. build 5465)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> '%f' % 1e100
'1e+100'
>>> '%F' % 1e100
'1e+100'
>>> '%f' % 1.2
'1.20'

str.format() works the same.


In C, the only difference seems to be that a NaN or infinity formatted with '%F'
is turned into "NAN" or "INF" instead of "nan" or "inf".


Not so in Python.
>>> '%f' % float('nan')
'nan'
>>> '%F' % float('nan')
'nan'


But it is the case with 'e':
>>> '%e' % float('nan')
'nan'
>>> '%E' % float('nan')
'NAN'
___
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:03 PM, Michael Foord
<[EMAIL PROTECTED]> wrote:
> Collin Winter wrote:
>>
>> On Tue, Jul 15, 2008 at 6:58 AM, Ben Finney <[EMAIL PROTECTED]>
>> wrote:
>>>
>>> Backwards Compatibility
>>> ===
>>>
>>> The names to be obsoleted should be deprecated and 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?

IMO some kind of automated transition tool is needed -- anyone who has
the time to convert their codebase by hand (for some definition of "by
hand" that involves sed) doesn't have enough to do.

Collin
___
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 3101: floats format 'f' and 'F'

[Daniel Stutzbach]

On Wed, Jul 16, 2008 at 10:07 AM, Mark Dickinson <[EMAIL PROTECTED]> wrote:
> On Wed, Jul 16, 2008 at 3:35 PM, Eric Smith
> <[EMAIL PROTECTED]> wrote:
>> Does anyone know why 'F' is the same as 'f'?  Wouldn't it make more sense to
>> either drop it, or make it convert the exponent to upper case
>
> What exponent?  Isn't the point of 'f' formatting that there is no exponent?

There's no exponent for small-magnitude numbers, but still an exponent
for large-magnitude numbers:

>>> '%f' % (10**100)
'1e+100'

-- 
Daniel Stutzbach, Ph.D. President, Stutzbach Enterprises LLC
___
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 3101: floats format 'f' and 'F'

[Mark Dickinson]

On Wed, Jul 16, 2008 at 3:35 PM, Eric Smith
<[EMAIL PROTECTED]> wrote:
> Does anyone know why 'F' is the same as 'f'?  Wouldn't it make more sense to
> either drop it, or make it convert the exponent to upper case

What exponent?  Isn't the point of 'f' formatting that there is no exponent?

In C, the only difference seems to be that a NaN or infinity formatted with '%F'
is turned into "NAN" or "INF" instead of "nan" or "inf".

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

[Python-Dev] PEP 3101: floats format 'f' and 'F'

[Eric Smith]

Does anyone know why 'F' is the same as 'f'?  Wouldn't it make more 
sense to either drop it, or make it convert the exponent to upper case 
(like 'E' and 'G')?  Compatibility with %-formatting is the only reason 
I can think of to keep up, but I get the sense we've given up on an 
automatic conversion from %-formatting to str.format().  Plus, I can 
find no uses of '%F' in the standard library.


And really, if you could write something to automatically convert 
%-formatting to str.format(), you'd be able to make 'F' to 'f', anyway.


I know it's a nit, but I'm reviewing the documentation and it sticks out.
___
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

[Nick Coghlan]

Ben Finney wrote:

Do you perhaps mean something like this::

def assert_compare_true(op, first, second, msg=None):
fail_detail = "%(first)r %(op)r %(second)r" % vars()
if msg is None:
msg = fail_detail
else:
msg = "%(fail_detail)s: %(msg)s" % vars()
if not op(first, second):
raise self.failure_exception(msg)

If so, that sems to be in line with the "Enhanced failure message"
principle exercised elsewhere in the same PEP, i.e. that the failure
message should *always* contain certain information, even if a message
is specified by the caller.


I was going to suggest the same thing, so this sounds like a good idea 
to me. The other point I was going to make is that repr(operator.lt) is 
actually "". It may be better to just make a 
general method for asserting that an operation gives an expected result 
and gives the name of the operation and the details of the arguments and 
expected result if anything goes wrong:


def assert_op(op, *args, msg=None, expected=True):
fail_detail = "%r%r != %r" % (op.__name__, arg, expect)
if msg is None:
msg = fail_detail
else:
msg = "%s: %s" % (msg, fail_detail)
if op(*args) != expected:
raise self.failure_exception(msg)


One downside I can see is that, in optimising for this common case, it
makes the function useless to someone who wants to specify their own
failure message exactly, without the specific extra information in
that specific format.


If you don't want the extra details in the error messages then you can 
just use the basic self.assert_ method - the only advantage to use the 
other assertion methods is they provide additional details in the 
assertion error. (except assert_raises, where it provides the try/catch 
block as well)


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)

[Rodrigo Bernardo Pimentel]

On Wed, Jul 16 2008 at 10:54:26AM BRT, Ben Finney <[EMAIL PROTECTED]> wrote:
> Rodrigo Bernardo Pimentel <[EMAIL PROTECTED]> writes:
> 
> > On Tue, Jul 15 2008 at 07:38:59PM BRT, Ben Finney <[EMAIL PROTECTED]> wrote:
> > > The "consistency" argument leads to the PEP 8 names. The removal
> > > of redundant names is not made in the name of consistency, but of
> > > API simplicity.
> > 
> > Isn't this *enourmous* discussion a clear sign that a lot of people
> > *won't* find a trimmed-down API simpler?
> 
> The majority of this discussion hasn't been about whether or not to
> trim the API, so I'd have to answer no. Instead, it shows that people
> have different ideas of how it should be done.

Ok, I've oversimplified my sentence. In more words, what I meant was that I
don't think the benefits of getting rid of assert* or fail* methods are very
clear (thus my "+1" on Tres's suggestion of leaving both), and it doesn't
seem to me like we're progressing in the direction of reaching an agreement
(though there has been great exposition of arguments). I mean, the benefits
of removing fail* seem clear for some people, but are strongly opposed by
others, and even the benefits of removing assert* seem clear for some
(IIRC).

All this lead to my previous sentence, which should read: isn't this
*enourmous* discussion a clear sign that a lot of people *won't* find an API
without fail* (or assert*) simpler? I agree there's trimming to be done, of
course. I'm just saying that there's clearly no agreement on this particular
point of whether to remove fail* completely, so maybe we should take it as
as indication that it might not actually simplify the API (in the sense of
how comfortable people are with using it).

> > If assert* to fail* mapping is consistent, then voilá, simple,
> > everyone can remember method names (+1 for PEP-8 renaming), everyone
> > is free to think of each test as they please.
> 
> Thanks for the feedback.

No problem! It's great to be in a community where these things are so openly
discussed :)


rbp
-- 
Rodrigo Bernardo Pimentel <[EMAIL PROTECTED]> | GPG: <0x0DB14978>
___
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]

Rodrigo Bernardo Pimentel <[EMAIL PROTECTED]> writes:

> On Tue, Jul 15 2008 at 07:38:59PM BRT, Ben Finney <[EMAIL PROTECTED]> wrote:
> > The "consistency" argument leads to the PEP 8 names. The removal
> > of redundant names is not made in the name of consistency, but of
> > API simplicity.
> 
> Isn't this *enourmous* discussion a clear sign that a lot of people
> *won't* find a trimmed-down API simpler?

The majority of this discussion hasn't been about whether or not to
trim the API, so I'd have to answer no. Instead, it shows that people
have different ideas of how it should be done.

> If assert* to fail* mapping is consistent, then voilá, simple,
> everyone can remember method names (+1 for PEP-8 renaming), everyone
> is free to think of each test as they please.

Thanks for the feedback.

-- 
 \  “Pity the meek, for they shall inherit the earth.” —Donald |
  `\  Robert Perry Marquis |
_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)

[Rodrigo Bernardo Pimentel]

On Tue, Jul 15 2008 at 07:38:59PM BRT, Ben Finney <[EMAIL PROTECTED]> wrote:
> Tres Seaver <[EMAIL PROTECTED]> writes:
> 
> > I would keep both by preference, rather than insist on a "foolish
> > consistency."

+1

> The "consistency" argument leads to the PEP 8 names. The removal of
> redundant names is not made in the name of consistency, but of API
> simplicity.

Isn't this *enourmous* discussion a clear sign that a lot of people *won't*
find a trimmed-down API simpler? If assert* to fail* mapping is consistent,
then voilá, simple, everyone can remember method names (+1 for PEP-8
renaming), everyone is free to think of each test as they please.


rbp
-- 
Rodrigo Bernardo Pimentel <[EMAIL PROTECTED]> | GPG: <0x0DB14978>
___
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 David Daniels <[EMAIL PROTECTED]> writes:

> I would rather something more like:
> 
>   def assert_compare_true(op, first, second, msg=None):
>   if op(first, second):
>   return
>   raise self.failure_exception(msg)
>   if msg is None:
>   self.failure_exception("%(first)r %(op)r %(second)"
>  % vars())
>   self.failure_exception("%(first)r %(op)r %(second): %(msg)"
>  % vars())

I'm confused. It appears to me that your version never gets past the
first 'raise' statement, which is unconditional; and the rest seems to
do nothing but instantiate exceptions without using them.

Do you perhaps mean something like this::

def assert_compare_true(op, first, second, msg=None):
fail_detail = "%(first)r %(op)r %(second)r" % vars()
if msg is None:
msg = fail_detail
else:
msg = "%(fail_detail)s: %(msg)s" % vars()
if not op(first, second):
raise self.failure_exception(msg)

If so, that sems to be in line with the "Enhanced failure message"
principle exercised elsewhere in the same PEP, i.e. that the failure
message should *always* contain certain information, even if a message
is specified by the caller.

One downside I can see is that, in optimising for this common case, it
makes the function useless to someone who wants to specify their own
failure message exactly, without the specific extra information in
that specific format.

What do others think of this?

-- 
 \“Holy contributing to the delinquency of minors, 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: Frequently-requested additional features for the `unittest` module

[Ben Finney]

Michael Foord <[EMAIL PROTECTED]> writes:

> I'm inclined to agree. It was part of a set of additions suggested
> by Guido. From here I think (as part of the unittest extensions that
> google maintains):
> 
> http://mail.python.org/pipermail/python-dev/2008-April/078702.html
> 
> I've used tests like that when implementing numeric objects, which
> has been several times - but only a tiny proportion of the tests
> I've written.
> 
> I wouldn't be sorry not to include them.

Okay. I'll revise the PEP to remove all these lt, gt, le, ge
comparison tests, and note that they are supported entirely by
``assert_compare_true`` and ``assert_compare_false`` with a specific
comparison operator.

-- 
 \ “Many are stubborn in pursuit of the path they have chosen, few |
  `\ in pursuit of the goal.” —Friedrich Nietzsche |
_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] Reminder: beta 2's schedule for tomorrow

[Barry Warsaw]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Jul 15, 2008, at 8:32 AM, Barry Warsaw wrote:

If there is anything you need a decision on, please follow up to  
this thread.  I'm inundated with email so I can't watch every thread  
on the mailing lists.  Or ping me on #python-dev.


I'm not currently optimistic that we can release today.

As I see it we have several problems serious enough to delay a  
release.  First, we have no green 2.6 or 3.0 buildbots


http://www.python.org/dev/buildbot/stable/

It looks like few of the buildbots for 2.6 are actually online, but  
still, the 3.0 buildbots are all failing.


We still have, and have had for a long time now, serious problems with  
the multiprocessing module:


http://bugs.python.org/[EMAIL 
PROTECTED],id,activity,versions,status&@sort=activity&@filter=priority,status&@pagesize=50&@startwith=0&priority=1&status=1&@dispname=Showstoppers

I noticed today that _multiprocessing.so has build problems on OS X  
10.5 and Ubuntu 8.04.  I opened a separate issue about that so as not  
to get lost in the other bug about test_multiprocessing hanging.  As  
evidenced by the thread for issue 3088, lots of people have put a lot  
of work into this module, but unfortunately we're still not there.   
These seem serious enough to me to hold up the release, especially  
since we have only one more beta left.


Speaking of which, we have a number of deferred blockers:

http://bugs.python.org/[EMAIL 
PROTECTED],id,activity,status&@sort=activity&@group=priority&@filter=priority,status&@pagesize=50&@startwith=0&priority=6&status=1&@dispname=Deferred%20Blockers

These will not block beta 2, but they /will/ block beta 3, so they  
really need some attention.


Please everyone, if you have only a little bit of time to work on  
Python, I hope you will attack the release critical and deferred  
blocker issues, and work on turning the buildbots green.  These are  
the top priorities in order to get 2.6 and 3.0 out on time.  And just  
as added incentive, our October 1st goal is being noted by downstream  
vendors.  I've been told that "Apple is willing to take the new Python  
if it is GM on schedule by Oct 1st, but may not if it is delayed"  
though you should not infer anything about Apple's schedule from this.


Still, we won't sacrifice quality in order to hit the October 1st  
goal.  After beta 2, I start getting mean. :)


- -Barry

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

iQCVAwUBSH31HHEjvBPtnXfVAQIH+AQAtkRJo0uhvZ300jq0YSR6ezUU0tMHJwmd
pwLWwZWDqPyh3/ohKwrajdGm5hYS8gOnTo+k2XEEJjQJdLMTblzZ3ArsGfhXHqbV
GPeKK/6BYT6SOD75ubINq+jSsu6Pvjsadbk/cp/x53WwHL8kX40D0YQBhp3KQRrz
zgFmfVFPcys=
=3SDN
-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 in the `unittest` module

[Ben Finney]

"M.-A. Lemburg" <[EMAIL PROTECTED]> writes:

> On 2008-07-16 14:02, Michael Foord wrote:
> > M.-A. Lemburg wrote:
> >> Note that PEP 4 targets deprecating use of whole modules, not
> >> single APIs, or - like in your case - more or less the complete
> >> existing API of a module.
> >
> > Which PEP is usually referenced for the deprecation of individual
> > APIs?
> 
> PEP 5 could be used for that.

That seems an even worse fit; it speaks of changing language features,
not library modules. At least PEP 4 talks about when to raise
DeprecationWarning.

> Adding several 10s of deprecation warnings to the unittest module is
> not going to make life easier for anyone. Adding just a single one
> on import and following PEP 4 is.

I don't see how the first "is not going to make life easier" if the
second somehow is. Is a programmer going to be helpless in the face of
some DeprecationWarnings but not others?

> If you do want to apply major changes to a module without changing
> the name, then this could be done as part of the 2.x -> 3.x
> transition.

This has already been rejected
http://mail.python.org/pipermail/python-dev/2008-April/078485.html>.

I'm inclined to agree that it's not right for 2.x. I'll revise the PEP
accordingly.

-- 
 \ “First they came for the verbs, and I said nothing, for verbing |
  `\weirds language. Then, they arrival for the nouns and I speech |
_o__)   nothing, for I no verbs.” —Peter Ellis |
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

[Scott David Daniels]

Ben Finney wrote:
...


def assert_compare_true(op, first, second, msg=None):
if msg is None:
msg = "%(first)r %(op)r %(second)" % vars()
if not op(first, second):
raise self.failure_exception(msg)


I would rather something more like:

  def assert_compare_true(op, first, second, msg=None):
  if op(first, second):
  return
  raise self.failure_exception(msg)
  if msg is None:
  self.failure_exception("%(first)r %(op)r %(second)"
 % vars())
  self.failure_exception("%(first)r %(op)r %(second): %(msg)"
 % vars())


--Scott David Daniels
[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] Proposed unittest changes

[Ben Finney]

Ron Adam <[EMAIL PROTECTED]> writes:

> +1 for a simpler testing module.

I've no objection.

> Just letting you know there is interest in a lighter weight testing
> suite.

'doctest' is a very simple testing module, that is a very useful tool.

> Looking at the unittest discussions, it doesn't look like it is
> getting easier to use, but more complex.

How so?

One PEP proposed this week specifies to do nothing but conform
'unittest' with the standard library guidelines, and remove redundant
names. That surely makes it simpler to use.

Another PEP specifies to add helper methods that simplify a number of
common cases.

What is it you see making unittest "more complex to use"?

> Py.test looks very interesting, especially the test discovery parts.
> I also agree we don't need special methods for every variation of
> assertedness.

My main complaint about 'py.test' is that it's yet-another-framework.
We already have 'doctest' and 'unittest', and they play together
reasonably well.

'nose' http://somethingaboutorange.com/mrl/projects/nose/> looks
better for consideration, especially since it integrates well with
'unittest'.

> I've been thinking that a few decorators may go a long way to making
> writing tests easy. It also reduces the level of indentation needed.

There are a number of these already in 'nose'.

-- 
 \“I fly Air Bizarre. You buy a combination one-way round-trip |
  `\ticket. Leave any Monday, and they bring you back the previous |
_o__) Friday. That way you still have the weekend.” —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)

[Antoine Pitrou]

Ben Finney  benfinney.id.au> writes:
> > * http://www.thefreedictionary.com/fail
> > "To prove deficient or lacking; perform ineffectively or inadequately; To be
> > unsuccessful"
> 
> Yes. It's a verb, not a negative modifer. To use it with a negative
> like "not" is not creating a "double negative".

Ok, let's stop it there. I'm tired of trying to point the obvious.



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

"M.-A. Lemburg" <[EMAIL PROTECTED]> writes:

> The PEP doesn't mention changing the module name and deprecating
> the old one.

Right. The intention is to have a PEP-8-conformant 'unittest' module,
not an entirely new module.

> Instead it wants to deprecate all the old names (and cites PEP 4 for
> this), but keeping the module name.

Yes, because all the existing documented API is retained as is, just
with new names that conform with PEP 8.

> Note that PEP 4 targets deprecating use of whole modules, not single
> APIs, or - like in your case - more or less the complete existing
> API of a module.

This is true, I tried to be specific about what was to be done to
deprecate individual attributes, and could only find PEP 4. Is there a
better reference for deprecation of Python features?

> Given the scope of the changes, you are really creating a completely
> new API and as a result should also get a new module name.

I disagree. The API is not "completely new"; it has exactly the same
functionality and expected behaviour, just with a different set of
names.

> Developers who don't feel like changing 1+ tests can then
> continue to use the old module and start using the new module for
> new projects.

I agree with Michael Foord that an extensively-used standard library
module is an argument in favour of re-working that module to be in
line with the standard library guidelines.

The change is, as has been pointed out elsewhere, a replacement of one
set of names with another, retaining exactly the same expected
behaviour. It's not on the scale of deprecating usage of an entire
module.

-- 
 \ “I went to the museum where they had all the heads and arms |
  `\  from the statues that are in all the other museums.” —Steven |
_o__)   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 in the `unittest` module

[M.-A. Lemburg]

On 2008-07-16 14:02, Michael Foord wrote:

M.-A. Lemburg wrote:

On 2008-07-16 10:14, Ben Finney wrote:

"M.-A. Lemburg" <[EMAIL PROTECTED]> writes:


Since this is a major change in the unit test API, I'd also like
to suggest that you use a new module name.

This is both a precaution to prevent tests failing due to not having
been upgraded and a way for old code to continue working by adding
the old unittest module on sys.path.


Do you have a specific argument against the provisions already stated
in the PEP for backward compatibility? They seem to address your
concerns already.


The PEP doesn't mention changing the module name and deprecating
the old one. Instead it wants to deprecate all the old names (and cites
PEP 4 for this), but keeping the module name.

Note that PEP 4 targets deprecating use of whole modules, not single
APIs, or - like in your case - more or less the complete existing API
of a module.


Which PEP is usually referenced for the deprecation of individual APIs?


PEP 5 could be used for that.

Adding several 10s of deprecation warnings to the unittest module
is not going to make life easier for anyone. Adding just a single
one on import and following PEP 4 is.

If you do want to apply major changes to a module without changing
the name, then this could be done as part of the 2.x -> 3.x transition.
The 2.x branch is not the right place for such breakage.


Given the scope of the changes, you are really creating a completely
new API and as a result should also get a new module name. You can then
deprecate use of the old "unittest" module name and point users to the
new one.


You propose that we duplicate the entire module with a new name, 
maintaining both in parallel but with different method names?


No, I'm proposing to apply all the name changes to a new module
and deprecate the old one. unittest will then go unmaintained
until it is removed.


That doesn't sound wise to me.



Developers who don't feel like changing 1+ tests can then continue
to use the old module and start using the new module for new projects.



So we shouldn't bring the API inline with PEP 8 because it is widely used?


I didn't say that. However, if it's not required, then breaking
a complete module API isn't necessary - "practicality beats purity".

Instead add a new module with all the changes and have developers
gradually migrate to the new code.

Even if it causes some pain (and the methods won't be removed for 
several years if we follow the normal deprecation schedule), the fact 
that the API is widely used would seem to be an argument in favor of 
making it follow the Python style guidelines.


So you're saying that because many people use the code, we should be
more inclined to make their life harder. That's an interesting
argument :-)

--
Marc-Andre Lemburg
eGenix.com

Professional Python Services directly from the Source  (#1, Jul 16 2008)
>>> Python/Zope Consulting and Support ...http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ...http://python.egenix.com/


 Try mxODBC.Zope.DA for Windows,Linux,Solaris,MacOSX for free ! 


   eGenix.com Software, Skills and Services GmbH  Pastor-Loeh-Str.48
D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg
   Registered at Amtsgericht Duesseldorf: HRB 46611
___
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

[Michael Foord]

Brett Cannon wrote:

On Tue, Jul 15, 2008 at 7:05 PM, Ben Finney <[EMAIL PROTECTED]> wrote:
  

Scott Dial <[EMAIL PROTECTED]> writes:



Why [introduce redundant test names]?

assert_not_less_than = assert_greater_than_or_equal
assert_not_greater_than = assert_less_than_or_equal
assert_not_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).
  


I'm inclined to agree. It was part of a set of additions suggested by 
Guido. From here I think (as part of the unittest extensions that google 
maintains):


http://mail.python.org/pipermail/python-dev/2008-April/078702.html

I've used tests like that when implementing numeric objects, which has 
been several times - but only a tiny proportion of the tests I've written.


I wouldn't be sorry not to include them.

Michael




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

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

[Ben Finney]

Antoine Pitrou <[EMAIL PROTECTED]> writes:

> * http://www.thefreedictionary.com/fail
> "To prove deficient or lacking; perform ineffectively or inadequately; To be
> unsuccessful"

Yes. It's a verb, not a negative modifer. To use it with a negative
like "not" is not creating a "double negative".

-- 
 \  “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] PEP: Consolidating names and classes in the `unittest` module (updated 2008-07-15)

[Ben Finney]

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

> The intuition that "fail" is a negative word is thus well-founded in
> standard usage.

That's not the same thing as "fail" being a negative word in the sense
meant by "double negative".

That is, "not fail" is not a double negative; nor is "fail if X is not
inside Y" a double negative. The use of "fail" in those phrases is a
action, a verb, not a "negative".

So, this issue of avoiding "fail" in order to "avoid double negatives"
has no basis in the use of "fail" in unittest.

-- 
 \  “It was half way to Rivendell when the drugs began to take |
  `\hold” —Hunter S. Tolkien, _Fear and Loathing in Barad-Dûr_ |
_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 in the `unittest` module

[Michael Foord]

Terry Reedy wrote:



Michael Foord wrote:

Collin Winter wrote:



Is any provision being made for a 2to3 fixer/otherwise-automated
transition for the changes you propose here?
  


As the deprecation is intended for 2.X and 3.X - is 2to3 fixer needed?


A fixer will only be needed when it 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.


Can 2to3 fixers be used for 2to2 and 3to3 translation then?

Michael




___
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

Re: [Python-Dev] Proposed unittest changes

[Ron Adam]

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.
I wrote a recipe (somewhat rough and incomplete) that shows how
easily this could be done:

http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/572194

Raymond


+1 for a simpler testing module.

Just letting you know there is interest in a lighter weight testing suite.

Looking at the unittest discussions, it doesn't look like it is getting 
easier to use, but more complex. Py.test looks very interesting, especially 
the test discovery parts.  I also agree we don't need special methods for 
every variation of assertedness.



I've been thinking that a few decorators may go a long way to making 
writing tests easy.  It also reduces the level of indentation needed.


Ron








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

M.-A. Lemburg wrote:

On 2008-07-16 10:14, Ben Finney wrote:

"M.-A. Lemburg" <[EMAIL PROTECTED]> writes:


Since this is a major change in the unit test API, I'd also like
to suggest that you use a new module name.

This is both a precaution to prevent tests failing due to not having
been upgraded and a way for old code to continue working by adding
the old unittest module on sys.path.


Do you have a specific argument against the provisions already stated
in the PEP for backward compatibility? They seem to address your
concerns already.


The PEP doesn't mention changing the module name and deprecating
the old one. Instead it wants to deprecate all the old names (and cites
PEP 4 for this), but keeping the module name.

Note that PEP 4 targets deprecating use of whole modules, not single
APIs, or - like in your case - more or less the complete existing API
of a module.


Which PEP is usually referenced for the deprecation of individual APIs?



Given the scope of the changes, you are really creating a completely
new API and as a result should also get a new module name. You can then
deprecate use of the old "unittest" module name and point users to the
new one.


You propose that we duplicate the entire module with a new name, 
maintaining both in parallel but with different method names?


That doesn't sound wise to me.



Developers who don't feel like changing 1+ tests can then continue
to use the old module and start using the new module for new projects.



So we shouldn't bring the API inline with PEP 8 because it is widely used?

Even if it causes some pain (and the methods won't be removed for 
several years if we follow the normal deprecation schedule), the fact 
that the API is widely used would seem to be an argument in favor of 
making it follow the Python style guidelines.


Michael

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

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

[M.-A. Lemburg]

On 2008-07-16 10:14, Ben Finney wrote:

"M.-A. Lemburg" <[EMAIL PROTECTED]> writes:


Since this is a major change in the unit test API, I'd also like
to suggest that you use a new module name.

This is both a precaution to prevent tests failing due to not having
been upgraded and a way for old code to continue working by adding
the old unittest module on sys.path.


Do you have a specific argument against the provisions already stated
in the PEP for backward compatibility? They seem to address your
concerns already.


The PEP doesn't mention changing the module name and deprecating
the old one. Instead it wants to deprecate all the old names (and cites
PEP 4 for this), but keeping the module name.

Note that PEP 4 targets deprecating use of whole modules, not single
APIs, or - like in your case - more or less the complete existing API
of a module.

Given the scope of the changes, you are really creating a completely
new API and as a result should also get a new module name. You can then
deprecate use of the old "unittest" module name and point users to the
new one.

Developers who don't feel like changing 1+ tests can then continue
to use the old module and start using the new module for new projects.

--
Marc-Andre Lemburg
eGenix.com

Professional Python Services directly from the Source  (#1, Jul 16 2008)
>>> Python/Zope Consulting and Support ...http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ...http://python.egenix.com/


 Try mxODBC.Zope.DA for Windows,Linux,Solaris,MacOSX for free ! 


   eGenix.com Software, Skills and Services GmbH  Pastor-Loeh-Str.48
D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg
   Registered at Amtsgericht Duesseldorf: HRB 46611
___
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]

Ben Finney  benfinney.id.au> writes:
> 
> This "fail is a negative word" has already been rebutted, by native
> speakers of English.

Well, Stephen's and Greg's own answers notwithstanding, if you really want an
authoritative answer, the best would be to open a dictionary and contrast the
given definitions...

* http://www.thefreedictionary.com/fail
"To prove deficient or lacking; perform ineffectively or inadequately; To be
unsuccessful"

* http://www.thefreedictionary.com/assert
"To state or express positively"

But perhaps there is enough of this fail/assert discussion now :-)

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)

[Stephen J. Turnbull]

Ben Finney writes:

 > This "fail is a negative word" has already been rebutted, by native
 > speakers of English.

Not successfully, it hasn't.  Steven d'Aprano describes one style of
testing as "the test passes if it fails to fail in each of a sequence
of cases."  That is perfectly good English, which makes no sense if
"fail" completely lacks the semantics of negation.  The intuition that
"fail" is a negative word is thus well-founded in standard usage.

By the way, a native speaker is a person who has no need to understand
how his language works; he just uses it.  Being a native speaker
doesn't qualify one as an authority on her language.
___
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]

"M.-A. Lemburg" <[EMAIL PROTECTED]> writes:

> Since this is a major change in the unit test API, I'd also like
> to suggest that you use a new module name.
> 
> This is both a precaution to prevent tests failing due to not having
> been upgraded and a way for old code to continue working by adding
> the old unittest module on sys.path.

Do you have a specific argument against the provisions already stated
in the PEP for backward compatibility? They seem to address your
concerns already.

-- 
 \   “If you don't know what your program is supposed to do, you'd |
  `\ better not start writing it.” —Edsger W. Dijkstra |
_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 in the `unittest` module

[M.-A. Lemburg]

On 2008-07-16 02:20, Collin Winter wrote:

On Tue, Jul 15, 2008 at 6:58 AM, Ben Finney <[EMAIL PROTECTED]> wrote:

Significant updates include removing all reference to the
(already-resolved) new-style class issue, adding footnotes and
references, and a Rationale summary of discussion on both 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


+1 for doing this in 3.1.

-1 for Python 2.7.

The main reason is that there's just too much 2.x code out there
using the API names you are suggesting to change and/or remove
from the module.

Since this is a major change in the unit test API, I'd also like
to suggest that you use a new module name.

This is both a precaution to prevent tests failing due to not having
been upgraded and a way for old code to continue working by adding
the old unittest module on sys.path.

Please note that the required renaming of the methods in existing
tests is not going to be as straight forward as you may think,
since you may well rename method calls into the tested application
rather than just the unit test class method calls if you're not
careful.


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.


--
Marc-Andre Lemburg
eGenix.com

Professional Python Services directly from the Source  (#1, Jul 16 2008)
>>> Python/Zope Consulting and Support ...http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ...http://python.egenix.com/


 Try mxODBC.Zope.DA for Windows,Linux,Solaris,MacOSX for free ! 


   eGenix.com Software, Skills and Services GmbH  Pastor-Loeh-Str.48
D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg
   Registered at Amtsgericht Duesseldorf: HRB 46611
___
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:

> This is a textbook example of a bikeshed discussion. The names (and
> now syntax!) of assertions are the most cosmetic issue there is with
> the unittest module, yet I see over *200* messages about it.

I've found it much more insightful than you seem to. I'm sorry it
hasn't been of more interest to you, but please don't discount the
value of this discussion for the rest of us.

> Deeper, but important issues, such as how to raise structured
> exceptions that a GUI test runner could usefully display and
> introspect, are ignored. I can list lots of others.

I look forward to you writing, promoting, and championing the PEP
document(s) for these issues that you consider important.

-- 
 \  “Some forms of reality are so horrible we refuse to face them, |
  `\ unless we are trapped into it by comedy. To label any subject |
_o__)unsuitable for comedy is to admit defeat.” —Peter Sellers |
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

[Ben Finney]

Scott Dial <[EMAIL PROTECTED]> writes:

> I would argue to go even further:
> 
> assertEqual = assert_eq
> assertAlmostEqual = assert_almost_eq
> assertNotEqual = assert_ne
> assertNotAlmostEqual = assert_almost_ne
> 
> I'm not sure if there are others, but using the same abbreviations
> from operator is consistent and readable and short, in my opinion.

This doesn't seem to be a good fit for either of "Consolidate names in
unittest API" (which seeks to make the renames meet standards, not
find better names), nor "Frequently-requested additions to unittest"
(which seeks *only* to add functionality, not change existing names).

-- 
 \  “An expert is a man who has made all the mistakes which can be |
  `\ made in a very narrow field.” —Niels Bohr |
_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)

[Andrew Bennetts]

Nick Coghlan wrote:
[...]
>
> What did you think of the "check" idea at the end of the email?
>
> Test assertions:
>   check(x).almost_equal(y)
>   check(x).is_(y)
>   check(x).in_(y)
>   check(x).equals(y)
>
> Test negative assertions:
>   check(x).not_almost_equal(y)
>   check(x).is_not(y)
>   check(x).not_in(y)
>   check(x).not_equal(y)

Wow.

This is a textbook example of a bikeshed discussion.  The names (and now
syntax!) of assertions are the most cosmetic issue there is with the unittest
module, yet I see over *200* messages about it.

Deeper, but important issues, such as how to raise structured exceptions that a
GUI test runner could usefully display and introspect, are ignored.  I can list
lots of others.

For assertions, just flip a coin already (or a roll a d20, perhaps...).  Can we
perhaps devote this considerable energy to significant improvements, please?

-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