date:20080714


Ben Finney wrote:

Steve Holden <[EMAIL PROTECTED]> writes:


Michael Foord wrote:

Adding the following new asserts:

   assertIn(member, container, msg=None)
   assertNotIn (member, container, msg=None)
   assertIs (first, second, msg=None)
   assertNotIs   (first, second, msg=None)

Please, let's call this one "assertIsNot". I know it's valid Python
to say

  if a not is b:

but it's a much less natural way of expressing the condition, and
(for all I know) might even introduce an extra negation operation.
"is not" is, I believe, treated as a single operator.


Dang. You're exactly right.

The problem is, that makes it quite inconsistent with other "not" uses
(such as "assert_not_equal", "assert_not_in", etc.) I would really
prefer that all these "not" uses be gramatically consistent for
predictability. Is this a case where "assert_is_not" should exist
alongside "assert_not_is"?


If we can flip the word order in the language syntax, we can sure as 
heck flip it in a method name :)


Cheers,
Nick.

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

Re: [Python-Dev] Proposed unittest changes


Michael Foord wrote:

Ben Finney wrote:

Howdy Michael,

I'm interested in the changes you're proposing for Python's 'unittest' 
module. I am (like, I suspect, many Python coders) maintaining my own 
set of extensions to the module across many projects, so I'd really 
like to see many of the improvements you discuss actually in the 
standard library.


What assistance can I offer to help on this issue?

  
I intend to start working on them in August, after I have finished my 
current writing commitments.


Would it be worth Ben collating your current notes into a draft PEP 
targeting 2.7/3.1?


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] xmlrpclib.{True, False} (was Re: Assignment to None)

2008-07-14 Thread Hrvoje Nikšić

On Mon, 2008-06-16 at 22:27 +0200, M.-A. Lemburg wrote:
> On 2008-06-15 16:47, Georg Brandl wrote:
> > Thomas Lee schrieb:
> >> Georg Brandl wrote:
> >>> Remember that it must still be possible to write (in 2.6)
> >>>
> >>> True = 0
> >>> assert not True
> >>
> >> Ah of course. Looks like I should just avoid optimizations of 
> >> Name("True") and Name("False") all together. That's a shame!
> > 
> > We can of course decide to make assignment to True and False
> > illegal in 2.7 :)
> 
> Raising a run-time exception would be fine, but not a SyntaxError at
> compile time - this would effectively make it impossible to keep
> code compatible to Python 2.1.

Maybe it wouldn't.  Something like:

try:
True, False
except NameError:
globals()['True'] = 1
globals()['False']

should still work for compatibility.  It would break *existing* code
that tries to be compatible with old releases, but that is unavoidable
in making something illegal that was previously legal.  In this case,
the price is justified by being able to optimize access to None, True,
and False without having to resort to dirty tricks such as
"none=None" (previously None=None) in functions.  It should also enable
the compiler to optimize "while True:" the way it optimizes "while 1:".

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

Re: [Python-Dev] AMD64-W2k8 buildbot wedged


Martin v. Löwis wrote:

http://bugs.python.org/issue3026 comes to mind.

And I would rather use a little bit different wording: The ones
truncating size_t/ssize_t do matter, unless  you know in advance that
you will always deal with data lesser than 2GiB.


I thought Nick's comment was in the context of the buildbots hanging
in the multiprocessing tests, which I know has only data smaller than
2GiB.


Ah, sorry about the confusion - my chain of thought was a little more 
convoluted than that. The wedged buildbot caused the compile to fail 
after a checkin of mine, which lead to me looking at that buildbot's 
compile log, which had all sorts of warnings which I had never seen 
before because my development machine is a 32-bit Linux box.


Given that I thought all those warnings had been cleared out when 
Py_ssize_t was first added, I was a little surprised by the quantity of 
them.


Cheers,
Nick.

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

Re: [Python-Dev] Proposed unittest changes

Nick Coghlan <[EMAIL PROTECTED]> writes:

> Ben Finney wrote:
> > The problem is, that makes it quite inconsistent with other "not"
> > uses (such as "assert_not_equal", "assert_not_in", etc.) I would
> > really prefer that all these "not" uses be gramatically consistent
> > for predictability. Is this a case where "assert_is_not" should
> > exist alongside "assert_not_is"?
> 
> If we can flip the word order in the language syntax, we can sure as
> heck flip it in a method name :)

To be clear, I take it you're in favour of the following names (with
no aliases):

assert_equalassert_not_equal
assert_is   assert_is_not
assert_in   assert_not_in
assert_almost_equal assert_not_almost_equal

and so on; i.e. that 'assert_is_not' breaks the obvious pattern set by
the others, in the interest of matching Python's 'is not' grammar.

-- 
 \   “Instead of having ‘answers’ on a math test, they should just |
  `\   call them ‘impressions’, and if you got a different |
_o__)   ‘impression’, so what, can't we all be brothers?” —Jack Handey |
Ben Finney

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

Re: [Python-Dev] Proposed unittest changes

2008-07-14 Thread Steve Holden


Ben Finney wrote:

Nick Coghlan <[EMAIL PROTECTED]> writes:


Ben Finney wrote:

The problem is, that makes it quite inconsistent with other "not"
uses (such as "assert_not_equal", "assert_not_in", etc.) I would
really prefer that all these "not" uses be gramatically consistent
for predictability. Is this a case where "assert_is_not" should
exist alongside "assert_not_is"?

If we can flip the word order in the language syntax, we can sure as
heck flip it in a method name :)


To be clear, I take it you're in favour of the following names (with
no aliases):

assert_equalassert_not_equal
assert_is   assert_is_not
assert_in   assert_not_in
assert_almost_equal assert_not_almost_equal

and so on; i.e. that 'assert_is_not' breaks the obvious pattern set by
the others, in the interest of matching Python's 'is not' grammar.

Well, I'd have said "in the interest of reading correctly in English", 
though I have to acknowledge this may not be an issue for many Python 
users whose first language not is English. "assert_not_is" is just 
dissonant to my ears.


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

Nick Coghlan <[EMAIL PROTECTED]> writes:

> Would it be worth Ben collating your current notes into a draft PEP
> targeting 2.7/3.1?

I'll do it and we'll find out.

-- 
 \ “A fine is a tax for doing wrong. A tax is a fine for doing |
  `\ well.” —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] Proposed unittest changes


Steve Holden wrote:

Ben Finney wrote:

To be clear, I take it you're in favour of the following names (with
no aliases):

assert_equalassert_not_equal
assert_is   assert_is_not
assert_in   assert_not_in
assert_almost_equal assert_not_almost_equal

and so on; i.e. that 'assert_is_not' breaks the obvious pattern set by
the others, in the interest of matching Python's 'is not' grammar.

Well, I'd have said "in the interest of reading correctly in English", 
though I have to acknowledge this may not be an issue for many Python 
users whose first language not is English. "assert_not_is" is just 
dissonant to my ears.


The two reasons aren't that far apart, given that Python's grammar uses 
"is not" because it makes more sense in English. One thing to remember 
is that the word 'is' is actually implied in all of the contracted 
phrases above other than those already including it explicitly.


"x is equal to y"
"x is not equal to y"
"x is y"
"x is not y"
"x is in y"
"x is not in y"
"x is almost equal to y"
"x is not almost equal to y"

As for which phrasing I personally prefer, unit tests and method names 
are areas where I'm quite happy to paint the bike shed the same colour 
as the house :)


Cheers,
Nick.

P.S. Deciphering that somewhat strained metaphor: I don't have a strong 
preference with regards to the unit test method names. While I tend to 
go with the assert* variants when left to my own devices, I have no 
problem sticking to the fail* variants when updating a test that uses 
them. Camel-case vs underscores in method names isn't something that 
particularly worries me either.


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

Re: [Python-Dev] Proposed unittest changes

Steve Holden <[EMAIL PROTECTED]> writes:

> Ben Finney wrote:
> > and so on; i.e. that 'assert_is_not' breaks the obvious pattern
> > set by the others, in the interest of matching Python's 'is not'
> > grammar.
> 
> Well, I'd have said "in the interest of reading correctly in English",
> though I have to acknowledge this may not be an issue for many Python
> users whose first language not is English. "assert_not_is" is just
> dissonant to my ears.

I'd count this as another (minor) point in favour of making the
'fail*' methods canonical: the names are consistent *and* gramatically
sensible:

fail_if_equal   fail_unless_equal
fail_if_is  fail_unless_is
fail_if_in  fail_unless_in
fail_if_almost_equalfail_unless_almost_equal

-- 
 \ “We are not gonna be great; we are not gonna be amazing; we are |
  `\   gonna be *amazingly* amazing!” —Zaphod Beeblebrox, _The |
_o__)Hitch-Hiker's Guide To The Galaxy_, Douglas Adams |
Ben Finney

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

Re: [Python-Dev] Proposed unittest changes

Michael Foord <[EMAIL PROTECTED]> writes:

> The full list of changes proposed (feel free to start - but ping me or
> the list) and not shot down was something like:
[…]

Thanks. I'm working these into another draft PEP that I hope to have
up in a day or two.

-- 
 \ “[W]e are still the first generation of users, and for all that |
  `\  we may have invented the net, we still don't really get it.” |
_o__)   —Douglas Adams |
Ben Finney

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

Re: [Python-Dev] Proposed unittest changes


Michael Foord <[EMAIL PROTECTED]> writes:


The full list of changes proposed (feel free to start - but ping me or
the list) and not shot down was something like:

[…]

Thanks. I'm working these into another draft PEP that I hope to have
up in a day or two.



Given all of the language changes in 2.6 and 3.0, I would think
that it is dangerous to make any changes at all to the unittest API.
That module is the one anchor in a sea of change.


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


Raymond Hettinger wrote:

Michael Foord <[EMAIL PROTECTED]> writes:


The full list of changes proposed (feel free to start - but ping me or
the list) and not shot down was something like:

[…]

Thanks. I'm working these into another draft PEP that I hope to have
up in a day or two.



Given all of the language changes in 2.6 and 3.0, I would think
that it is dangerous to make any changes at all to the unittest API.
That module is the one anchor in a sea of change.

As proposed the changes don't remove or rename anything - so there will 
be no code breakage, just additional test methods.


However, as we're into the beta phase I don't think these changes can 
make 2.6 / 3.0 anyway.


Michael




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/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] urllib.quote and unquote - Unicode issues

2008-07-14 Thread Bill Janssen

>> Clearly the unquote is str->bytes,  You can't pass a Unicode string 
>> back
>> as the result of unquote *without* passing in an encoding specifier,
>> because the character set is application-specific.
> So for unquote you're suggesting that it always return a bytes object
> UNLESS an encoding is specified? As in:
> >> urllib.parse.unquote('h%C3%BCllo')
> b'h\xc3\xbcllo'

Yes, that's correct.  That's what the RFC says we have to do.

> I would object to that on two grounds. Firstly, I wouldn't expect or
> desire a bytes object. The vast majority of uses for unquote will be
> to get a character string out, not bytes. Secondly, there is a
> mountain of code (including about 12 modules in the standard library)
> which call unquote and don't give the user the encoding option, so
> it's best if we pick a default that is what the majority of users will
> expect. I argue that that's UTF-8.

Unfortunately, despite your expectations or desires, the spec doesn't
allow us that luxury.  It's bytes out, and they may even be in a
non-standard (not registered with IANA) encoding.  There's no way to
safely and correctly turn that sequence of bytes into a string.  If
other modules have been mis-using the interface, they are buggy and
should be fixed.  There's a lot of buggy stdlib code in Python around
the older Web standards.

I think it would be great to have another function, unquote_to_string,
which took an extra "encoding" parameter, and returned a string.  It
would also be OK to add a keyword parameter to "unquote", I think,
which provides an encoding, and causes unquote to return a string.
But the standard behavior has to be to return bytes.

> I'd prefer having a separate unquote_raw function which is
> str->bytes, and the unquote function performs the same role as it
> always have, which is str->str.

Actually, it was originally bytes->bytes, because there was no notion
of Unicode strings when it was added.  It perhaps got misunderstood
during the addition of Unicode support to Python; many people have had
trouble wrapping their heads around all this, myself included.

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

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

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


..  contents::


Abstract


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


Motivation
==

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

* It does not use new-style classes, preventing e.g. straightforward
  use of ``super`` for calling the fixture set-up and tear-down
  methods.

* 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 the Zen of
  Python (specifically, that "there should be one, and preferably only
  one, obvious way to do it").


Specification
=

Use new-style classes throughout


The following classes will inherit explicitly from the built-in
`object` type, to make all classes in the module part of the new-style
type hierarchy.

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

Remove obsolete names
-

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

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

Remove redundant names
--

The following attribute names exist only as synonyms for other names.
They are to be removed, leaving only one name for each attribute in
the API.

``TestCase`` attributes
~~~

* ``assertEqual``
* ``assertEquals``
* ``assertNotEqual``
* ``assertNotEquals``
* ``assertAlmostEqual``
* ``assertAlmostEquals``
* ``assertNotAlmostEqual``
* ``assertNotAlmostEquals``
* ``assertRaises``
* ``assert_``
* ``assertTrue``
* ``assertFalse``

Conform API with PEP 8
--

The following names are to be introduced, each replacing an existing
name, to make all names in the module conform with PEP 8. 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
~

``_make_loader(prefix, sort_using, suite_class)``
  Replaces ``_makeLoader (prefix, sortUsing, suiteClass)``

``find_test_cases(module, prefix, sort_using, suite_class)``
  Replaces ``findTestCases(module, prefix, sortUsing, suiteClass)``

``get_test_case_names(test_case_class, prefix, sort_using)``
  Replaces ``getTestCaseNames(testCaseClass, prefix, sortUsing)``

``make_suite(test_case_class, prefix, sort_using, suite_class)``
  Replaces ``makeSuite(testCaseClass, prefix, sortUsing, suiteClass)``

``default_test_loader``
  Replaces ``defaultTestLoader``

``TestResult`` atributes


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

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

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

``should_stop``
  Replaces ``shouldStop``

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

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

``tests_run``
  Replaces ``testsRun``

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

``TestCase`` attributes
~~~

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

``_test_method_doc``
  Replaces ``_testMethodDoc``

``_test_method_name``
  Replaces ``_testMethodName``

``failure_exception``
  Replaces ``failureException``

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

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

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

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

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

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

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

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

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

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

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

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

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

``FunctionTestCase`` at

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

On Mon, Jul 14, 2008 at 8:25 AM, Ben Finney <[EMAIL PROTECTED]> wrote:
> Use new-style classes throughout
> 
>
> The following classes will inherit explicitly from the built-in
> `object` type, to make all classes in the module part of the new-style
> type hierarchy.
>
> * ``TestResult``
> * ``TestCase``
> * ``TestSuite``
> * ``TestLoader``
> * ``_WritelnDecorator``
> * ``TextTestRunner``
> * ``TestProgram``

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



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

Re: [Python-Dev] Proposed unittest changes

Michael Foord <[EMAIL PROTECTED]> writes:

> As proposed the changes don't remove or rename anything - so there
> will be no code breakage, just additional test methods.

Right, so I'm putting up a separate PEP just for the renaming. Should
be arriving on this list soon.

> However, as we're into the beta phase I don't think these changes
> can make 2.6 / 3.0 anyway.

Definitely agreed.

-- 
 \“You can be a victor without having victims.” —Harriet Woods |
  `\   |
_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] Proposed unittest changes

"Raymond Hettinger" <[EMAIL PROTECTED]> writes:

> Given all of the language changes in 2.6 and 3.0, I would think that
> it is dangerous to make any changes at all to the unittest API. That
> module is the one anchor in a sea of change.

Agreed. I'm not proposing to have the unittest API change at all in
Python 2.6 or 3.0. These changes, even the first deprecations, would
not be suitable for anything earlier than 2.7 and 3.1.

-- 
 \“When in doubt tell the truth. It will confound your enemies |
  `\   and astound your friends.” —Mark Twain, _Following the Equator_ |
_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's redundant assertions: asserts vs. failIf/Unlesses

2008-07-14 Thread Steven D'Aprano

On Mon, 14 Jul 2008 09:54:16 am Steve Holden wrote:
> > Python may be Guido's language, and if he wants to use his
> > dictatorial powers to say that tests must be written as positive
> > assertions because that's the way he likes it, that's his
> > prerogative. But let's not pretend that this particular bike shed
> > colour has any objectively rational reason, or that the change
> > won't force some people to have to change the way they think about
> > tests.
>
> But sometimes even the wrong decision is better than no decision, and
> I suspect most if us can agree that it's better if everyone thinks
> about tests the same way.

There's a term for what happens when everybody in a community or group 
thinks about a subject the same way.

http://en.wikipedia.org/wiki/Groupthink


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

[Python-Dev] git repositories for trunk and py3k

2008-07-14 Thread Neil Schemenauer

Hi,

In case anyone is interested, I have git repositories for both the
trunk and the py3k branch of the Python source code.  They are
up-to-date and so using them with git-svn would be much faster than
starting from scratch.

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

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

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


Ben Finney wrote:

[snip..]

Remove redundant names
--

The following attribute names exist only as synonyms for other names.
They are to be removed, leaving only one name for each attribute in
the API.

``TestCase`` attributes
~~~

* ``assertEqual``
* ``assertEquals``
* ``assertNotEqual``
* ``assertNotEquals``
* ``assertAlmostEqual``
* ``assertAlmostEquals``
* ``assertNotAlmostEqual``
* ``assertNotAlmostEquals``
* ``assertRaises``
* ``assert_``
* ``assertTrue``
* ``assertFalse``

  
Although you may prefer the 'failIf' and 'failUnless' names, the 
consensus in the *last* discussion was that the 'assert*' names were to 
be preferred.


I protest the removal of the assert names - and in the absence of likely 
consensus (and barring a dictat of course) I suggest this part of the 
proposal be excised.


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

2008-07-14 Thread Antoine Pitrou

Ben Finney  benfinney.id.au> writes:
> The following attribute names exist only as synonyms for other names.
> They are to be removed, leaving only one name for each attribute in
> the API.

Just for information, here is the current distribution of the two synonym kinds:
(on py3k)

$ grep "self.assert" Lib/test/test_*.py | wc -l
14972
$ grep "self.fail" Lib/test/test_*.py | wc -l
1807

If no rational argument prevails, at least we have data on the past and current
habits of the python-dev community.

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

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

> On Mon, Jul 14, 2008 at 8:25 AM, Ben Finney <[EMAIL PROTECTED]> wrote:
> > Use new-style classes throughout
> > 
> >
> > The following classes will inherit explicitly from the built-in
> > `object` type, to make all classes in the module part of the new-style
> > type hierarchy.
> >
> > * ``TestResult``
> > * ``TestCase``
> > * ``TestSuite``
> > * ``TestLoader``
> > * ``_WritelnDecorator``
> > * ``TextTestRunner``
> > * ``TestProgram``
> 
> They already do. __metaclass__ = type is found in unittest.py.

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

-- 
 \   “I love to go down to the schoolyard and watch all the little |
  `\   children jump up and down and run around yelling and screaming. |
_o__) They don't know I'm only using blanks.” —Emo Philips |
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

On Mon, Jul 14, 2008 at 6:18 PM, Ben Finney <[EMAIL PROTECTED]> wrote:
> "Benjamin Peterson" <[EMAIL PROTECTED]> writes:
>
>> On Mon, Jul 14, 2008 at 8:25 AM, Ben Finney <[EMAIL PROTECTED]> wrote:
>> > Use new-style classes throughout
>> > 
>> >
>> > The following classes will inherit explicitly from the built-in
>> > `object` type, to make all classes in the module part of the new-style
>> > type hierarchy.
>> >
>> > * ``TestResult``
>> > * ``TestCase``
>> > * ``TestSuite``
>> > * ``TestLoader``
>> > * ``_WritelnDecorator``
>> > * ``TextTestRunner``
>> > * ``TestProgram``
>>
>> They already do. __metaclass__ = type is found in unittest.py.
>
> Not in the copy I have. Is that in 3.x only, or in 2.x also?

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


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

Re: [Python-Dev] Proposed unittest changes


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

On Mon, Jul 14, 2008 at 6:26 PM, Raymond Hettinger <[EMAIL PROTECTED]> wrote:.
>
> I would like to work with you or someone else who is interested
> on an alternative PEP for a separate, simpler test module
> using the py.test syntax.  That is much simpler to learn and use.
> Instead of self.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:

Bringing the total amount of test modules in the stdlib to 3. OWTDI indeed.

Anyway, I don't think something like needs to be (re)written. nose[1]
is already an excellent implementation of this that I would like to
see in the stdlib.

[1] http://www.somethingaboutorange.com/mrl/projects/nose/



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

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

2008-07-14 Thread Steven D'Aprano

On Mon, 14 Jul 2008 04:27:40 pm Stephen J. Turnbull wrote:

> FWIW, I meant 10 != not not 10.

>>> 10 != not not 10
  File "", line 1
10 != not not 10
^
SyntaxError: invalid syntax

With respect, I think that the fact that you made an analogy with Python 
code that you hadn't tested, got it wrong, then corrected it, and 
*still* got it wrong, is telling. Its part of the pattern of this 
thread. People have repeatedly and consistently asserted that their 
particular favourite bike-shed colour is not just more attractive than 
any other colour, but supposedly objectively and logically better than 
any other colours. It's that second part that I object to.

When it comes to assert* versus fail* tests, this is one case where I 
don't believe "one obvious way to do it" should apply. A similar, and I 
hope uncontroversial, case is the greater-than and less-than operators. 
It would be frankly silly to declare that Python code should always use 
x < y and never y > x on the basis that there should be "one obvious 
way". Sometimes a particular test is most naturally written as g-t, and 
sometimes as l-t, and sometimes the choice between them is just 
arbitrary.

I believe that assert* and fail* tests are the same: while the choice is 
often arbitrary, sometimes a test is naturally written as an assert and 
sometimes as a fail. My own tests often look like this:

fail_if_spam()
fail_unless_ham()
assert_parrot()
fail_if_spanish_inquisition()

because the specific parrot test is best written as an assertion rather 
than a fail. And frankly, I simply don't believe that this imposes an 
undue mental cost on people who might read my code.

It's certainly true that I could invert the nature of the tests:

assert_not_spam()
assert_ham()
assert_parrot()
assert_not_spanish_inquisition()

just for the sake of consistency (and that would be a good thing 
*why*?), but only at the cost of inverting the code inside the test, 
which may or may not be a simple thing to do.

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

2008-07-14 Thread Antoine Pitrou


Hi,

> I think some variant
> of py.test could be done that is compatable with unittest
> and the did not have the "magic" present in earlier versions of py.test.

It already exists:
http://www.somethingaboutorange.com/mrl/projects/nose/

Regards

Antoine.


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

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

Significant updates are to the preamble (Python-Version field), the
sections "Use new-style classes throughout", "Module attributes", and
a new Rationale section "Removal of ``assert*`` names".


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


..  contents::


Abstract


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


Motivation
==

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

* It does not use new-style classes, preventing e.g. straightforward
  use of ``super`` for calling the fixture set-up and tear-down
  methods.

* 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 the Zen of
  Python (specifically, that "there should be one, and preferably only
  one, obvious way to do it").


Specification
=

Use new-style classes throughout


The following classes are currently implemented as classic
("old-style") classes, with no metaclass.

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

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

__metaclass__ = type

Remove obsolete names
-

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

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

Remove redundant names
--

The following attribute names exist only as synonyms for other names.
They are to be removed, leaving only one name for each attribute in
the API.

``TestCase`` attributes
~~~

* ``assertEqual``
* ``assertEquals``
* ``assertNotEqual``
* ``assertNotEquals``
* ``assertAlmostEqual``
* ``assertAlmostEquals``
* ``assertNotAlmostEqual``
* ``assertNotAlmostEquals``
* ``assertRaises``
* ``assert_``
* ``assertTrue``
* ``assertFalse``

Conform API with PEP 8
--

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

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

Module attributes
~

``default_test_loader``
  Replaces ``defaultTestLoader``

``TestResult`` attributes
~

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

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

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

``should_stop``
  Replaces ``shouldStop``

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

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

``tests_run``
  Replaces ``testsRun``

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

``TestCase`` attributes
~~~

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

``_test_method_doc``
  Replaces ``_testMethodDoc``

``_test_method_name``
  Replaces ``_testMethodName``

``failure_exception``
  Replaces ``failureException``

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

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

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

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

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

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

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

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

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

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

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

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

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

``FunctionTestCase`` attributes
~~~

``__init__(self, test_fun

Re: [Python-Dev] Proposed unittest changes


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.  


However, to provide readable output for errors in even simple tests 
(like a == b) py.test does magic with stack frames and code objects - in 
order to discover the objects being compared.


As this relies on what are essentially implementation details of the 
Python interpreter it means that some implementations (specifically 
IronPython which doesn't have Python stack frames and only a minimal 
representation of frame objects) will never be able to run it.


I think it would be a bad idea to move *Python testing* itself over to a 
framework like this.


I personally find unittest pretty readable, the feature most lacking is 
autodiscovery of tests which nose does seem to provide very well 
although I haven't used it yet.


Michael


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


Raymond Hettinger wrote:

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

Right, so I'm putting up a separate PEP just for the renaming. Should
be arriving on this list soon.


I would like to work with you or someone else who is interested
on an alternative PEP for a separate, simpler test module
using the py.test syntax.  That is much simpler to learn and use.
Instead of self.assertIsNot and whatnot, you write:
  assert a is not b
No need for tons of word-by-word spellings on things we already
have syntax for.  Almost anyone who has used py.test can attest
its syntax is much more natural, easy to learn, easy to both
read and write, and is much lighter weight.  I think some variant
of py.test could be done that is compatable with unittest
and the did not have the "magic" present in earlier versions of py.test.


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


assert a == b

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


Michael


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

2008-07-14 Thread Jonathan Lange

On Tue, Jul 15, 2008 at 9:43 AM, Michael Foord
<[EMAIL PROTECTED]> wrote:
> I personally find unittest pretty readable, the feature most lacking is
> autodiscovery of tests which nose does seem to provide very well although I
> haven't used it yet.

FWIW, Twisted's 'trial' has done this since about 2003, and works with
stdlib unit tests. I'd be happy to submit the discovery code to
Python.

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


From: "Michael Foord" <[EMAIL PROTECTED]>
However, to provide readable output for errors in even simple tests 
(like a == b) py.test does magic with stack frames and code objects - in 
order to discover the objects being compared.


Don't have to go that route.  Can use plain python assert failures with a 
stacktrace.
Or can trigger pdb, or let the user specify a mode that calls some more advanced
test runner or test reporter with introspection.  This can be done without 
making
everything hard.


I think it would be a bad idea to move *Python testing* itself over to a 
framework like this.


Don't want to convert the python testing.
Would like to offer a lighter-weight alternative to our users.


I personally find unittest pretty readable, the feature most lacking is 
autodiscovery of tests which nose does seem to provide very well 
although I haven't used it yet.


It takes about one day of using py.test to realize have much
cleaner and more readable its syntax is.  Also, writing the
tests is *much* more pleasant.  It has the same clean, clear
joy as writing regular python code.  By comparison, the code
using unittest.py is javaesque.   I've written tons of test with
unittest.py and and find it to be joyless.

I realize there is a matter of taste involved but if you talk to
any regular users of py.test, they will *all* attest to the
syntax being much more readable, lightweight, and pleasant
to use.  It encourages writing tests.

That being said, I think there are less magical, much simpler
ways to implement it.  I think Holger is working on it as we speak.


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

On Mon, Jul 14, 2008 at 6:43 PM, Michael Foord
<[EMAIL PROTECTED]> wrote:
>
> However, to provide readable output for errors in even simple tests (like a
> == b) py.test does magic with stack frames and code objects - in order to
> discover the objects being compared.

Maybe what we need to do then is make the assert statement more
powerful. I like the idea of having it call a builtin called
__assert__ which is called by the assert statement. The AST for the
node could be attached.



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

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

On Mon, Jul 14, 2008 at 6:42 PM, Ben Finney <[EMAIL PROTECTED]> wrote:
> Specification
> =
>
> Use new-style classes throughout
> 
>
> The following classes are currently implemented as classic
> ("old-style") classes, with no metaclass.
>
> * ``TestResult``
> * ``TestCase``
> * ``TestSuite``
> * ``TestLoader``
> * ``_WritelnDecorator``
> * ``TextTestRunner``
> * ``TestProgram``
>
> The `unittest` module will gain the following attribute, to set the
> default metaclass for classes in the module and thus make all classes
> in the module part of the new-style type hierarchy::
>
>__metaclass__ = type

It's already done.

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



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

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

2008-07-14 Thread Brett Cannon

On Mon, Jul 14, 2008 at 3:43 PM, Neil Schemenauer <[EMAIL PROTECTED]> wrote:
> Hi,
>
> In case anyone is interested, I have git repositories for both the
> trunk and the py3k branch of the Python source code.  They are
> up-to-date and so using them with git-svn would be much faster than
> starting from scratch.
>
> If anyone is interested, I will find a place to host them.  They are
> each about 150 MB in size.
>

Would you mind putting the time in, Neil, to have them hosted on a
python.org machine like the bzr branches and have them auto-updated?

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

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

2008-07-14 Thread Barry Warsaw


-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Jul 14, 2008, at 6:43 PM, Neil Schemenauer wrote:


In case anyone is interested, I have git repositories for both the
trunk and the py3k branch of the Python source code.  They are
up-to-date and so using them with git-svn would be much faster than
starting from scratch.

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


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

- -Barry

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

iQCVAwUBSHv+A3EjvBPtnXfVAQI0zwP9H0lZMvWxwncqg1BmI+df0WTh7+SOsxO2
RHky3TzqkY7wBXXwHPe5d7duWzflsXjB6ljH0AoR7icMs31h5ZUZhGVU/vSYouqk
KhHqCHjnXlnY0qOySthblboih/Uw9ApR9akEsKAxQrzUATbZF93dS5RJg4QjpMn3
HJ06MUTt5y0=
=bm3R
-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

Benjamin Peterson wrote:

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

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

On Mon, Jul 14, 2008 at 8:25 AM, Ben Finney <[EMAIL PROTECTED]> wrote:

Use new-style classes throughout

The following classes will inherit explicitly from the built-in
`object` type, to make all classes in the module part of the new-style
type hierarchy.

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

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

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

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

import unittest
isinstance(unittest.TestCase, object)

True

That proves nothing:

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

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

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

. .

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

Am I the only one who finds this sort of excessive pep-8 underscoring to be
horrorific?

Nobody I know spells setup and teardown as two words. I dread using the module with these new names. Underscores are not fun to
type. They create a weird_mental_pause when reading them.

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

fail_if_almost_equal

Another thought is that test suite code is going to get seriously crunched when the new, longer method names meet the 78/80 column
pep 8 restrictions.

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

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

* Explicit is better than implicit:

Don't forgot the opposing forces:

Beautiful is better than ugly.
Readability counts.

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

Use new-style classes throughout

This makes sense for 3.1 but of course we already get that automatically for
3.0 ;-)

For 2.7, it doesn't make as much sense. Since 2.2 came out, there have been many discussions on changing standard library code to
use new-style classes. There was always some concern about subtle changes in semantics and for the most part these requests were
denied. I think this reason applies with even more force to the unittest module. Any risk that we subtlely break someone's
test-suite is a small disaster. The 2.6 and 2.7 unittests need to be absolutely stable if they are to serve as a transition tool
(providing a baseline the 3.0/3.1 is expected to match).

Also, are there any expected benefits from making this change in 2.7? What
will the module do differently?

It seems like a risky change for zero-benefit.

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

Raymond Hettinger wrote:

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

. .

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

Am I the only one who finds this sort of excessive pep-8 underscoring 
to be horrorific?

Nobody I know spells setup and teardown as two words. I dread using 
the module with these new names. Underscores are not fun to type. They 
create a weird_mental_pause when reading them.

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

+1

setUp and tearDown should become setup and teardown.

fail_if_almost_equal

Another thought is that test suite code is going to get seriously 
crunched when the new, longer method names meet the 78/80 column pep 8 
restrictions.

Well... "assert_not_equal"  is slightly shorter, "assert_notequal" 
slightly more so. Still one char longer than the original though.

class TestMisc(unittest.test_case):
   def lost_four_spaces_here_already(self):
   self.fail_if_almost_equal('were already on the 34th column before'
 'writing anything substantive',
 self.testedobject.tested_method(arg1, 
arg2 +
 arg3, 
arg4)

   # Imagine typing and line wrapping dozens more tests like this

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

* Explicit is better than implicit:

Don't forgot the opposing forces:

Beautiful is better than ugly.
Readability counts.

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

Use new-style classes throughout

This makes sense for 3.1 but of course we already get that 
automatically for 3.0 ;-)

For 2.7, it doesn't make as much sense.  Since 2.2 came out, there 
have been many discussions on changing standard library code to use 
new-style classes.  There was always some concern about subtle changes 
in semantics and for the most part these requests were denied.  I 
think this reason applies with even more force to the unittest 
module.  Any risk that we subtlely break someone's test-suite is a 
small disaster.  The 2.6 and 2.7 unittests need to be absolutely 
stable if they are to serve as a transition tool (providing a baseline 
the 3.0/3.1 is expected to match).

Also, are there any expected benefits from making this change in 2.7?  
What will the module do differently?

It would allow you to use properties in testcases. Not sure if there is 
a usecase for this though.

It looks like Benjamin Peterson is right, in Python 2.5 TestCase already 
appears to be a new style class:

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

>>>

It seems like a risky change for zero-benefit.

Looks like that part of the PEP is unnecessary.

Michael

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

2008-07-14 Thread Jonathan Lange

On Tue, Jul 15, 2008 at 12:06 PM, Raymond Hettinger <[EMAIL PROTECTED]> wrote:
>> ``set_up(…)``
>>  Replaces ``setUp(…)``
>
> . .
>>
>> ``tear_down(…)``
>>  Replaces ``tearDown(…)``
>
> Am I the only one who finds this sort of excessive pep-8 underscoring to be
> horrorific?
>
> Nobody I know spells setup and teardown as two words. I dread using the
> module with these new names.
>

Hi,

My name's Jonathan, and I spell "set up" as "set up" and "tear down"
as "tear down".

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

Yes, guessability via consistency is the important thing here.

>
>> fail_if_almost_equal
>
> Another thought is that test suite code is going to get seriously crunched
> when the new, longer method names meet the 78/80 column pep 8 restrictions.
>
> class TestMisc(unittest.test_case):
>   def lost_four_spaces_here_already(self):
>   self.fail_if_almost_equal('were already on the 34th column before'
> 'writing anything substantive',
> self.testedobject.tested_method(arg1, arg2 +
> arg3, arg4)
>   # Imagine typing and line wrapping dozens more tests like this
>
> Are there any ideas for some short, pithy, mnemonic names that are
> self-explantory and not full of underscores; something that wouldn't suck to
> type hundreds of times in a good test module?  IMO, the current names are
> already too long.
>

Well, "assert_" is strictly shorter than "fail_unless_".

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

I find underscores easier to read—I suspect this will vary from person
to person. Typing isn't an issue since I use an auto-complete function
in my editor.

jml
___
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)


It looks like Benjamin Peterson is right, in Python 2.5 TestCase already 
appears to be a new style class:


Yep.  I stand corrected.  It looks like that changed five years ago (rev 28064).  Not sure how that slipped through but it doesn't 
seem to have caused any problems.



Raymond 


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

2008-07-14 Thread Janzert


Raymond Hettinger wrote:

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

. .

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


Am I the only one who finds this sort of excessive pep-8 underscoring to 
be horrorific?


Nobody I know spells setup and teardown as two words. I dread using the 
module with these new names. Underscores are not fun to type. They 
create a weird_mental_pause when reading them.




+1

And Merriam-Webster agrees,

http://www.merriam-webster.com/dictionary/setup
http://www.merriam-webster.com/dictionary/teardown

Janzert


___
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

2008-07-14 Thread Guido van Rossum

On Mon, Jul 14, 2008 at 5:13 PM, Raymond Hettinger <[EMAIL PROTECTED]> wrote:
> It takes about one day of using py.test to realize have much
> cleaner and more readable its syntax is.  Also, writing the
> tests is *much* more pleasant.  It has the same clean, clear
> joy as writing regular python code.  By comparison, the code
> using unittest.py is javaesque.   I've written tons of test with
> unittest.py and and find it to be joyless.

I, too, have written tons of tests with unittest.py (and Google's
extensions, which follow the same style), and reviewed even more. I
agree that this is pretty joyless, but I'm not at all sure that the
unittest API is the reason. It seems to me that a main problem with
writing test code is and will always remain due to the need to use
mocks, stubs and other similar techniques (e.g. dependency injection).
Typical test code that I've written or reviewed spends more time
setting up the input conditions for testing than it spends checking
the results. Ten lines of mocking code to one self.assertEqual() call
seems typical.

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


Guido van Rossum wrote:

On Mon, Jul 14, 2008 at 5:13 PM, Raymond Hettinger <[EMAIL PROTECTED]> wrote:
  

It takes about one day of using py.test to realize have much
cleaner and more readable its syntax is.  Also, writing the
tests is *much* more pleasant.  It has the same clean, clear
joy as writing regular python code.  By comparison, the code
using unittest.py is javaesque.   I've written tons of test with
unittest.py and and find it to be joyless.



I, too, have written tons of tests with unittest.py (and Google's
extensions, which follow the same style), and reviewed even more. I
agree that this is pretty joyless, but I'm not at all sure that the
unittest API is the reason. It seems to me that a main problem with
writing test code is and will always remain due to the need to use
mocks, stubs and other similar techniques (e.g. dependency injection).
Typical test code that I've written or reviewed spends more time
setting up the input conditions for testing than it spends checking
the results. Ten lines of mocking code to one self.assertEqual() call
seems typical.

  
Maybe Python needs a good mocking module in the standard library. There 
are plenty, but we use a particularly nice one at Resolver Systems [1]. :-)


It auto-creates attributes as mocks, allowing you to assert calls made 
to all of its children along with convenience methods like 
'assert_called_with' and has a companion decorator that patches class / 
module level attributes just for the duration of the test.


As we're changing more of our tests over to use these we're finding it 
reduces the volume and complexity of our test code.


Michael Foord

[1] Based on http://code.google.com/p/mock/ although there is some 
outstanding code to sync back to the project.


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


From: "Michael Foord" <[EMAIL PROTECTED]>
Maybe Python needs a good mocking module in the standard library. There 
are plenty, but we use a particularly nice one at Resolver Systems [1]. :-)


-1

This comes up occassionally and gets shot down.
http://bugs.python.org/issue708125

Mock objects mean different things to different people.
Some expect more simulated behavior and others want less.
It's rare to find agreement about general purpose mock objects and frameworks.
Mock libraries create their own complexities and burdens on a programmer's 
memory.
It's often easier to create a small special case mock object
than to remember how to configure a general purpose one.
And, afaict, there is no fan club for some particular python mock
object library -- it seems to only come up in general discussions
about possibilities for growing the unittest module, and almost
never comes up in the context of solving a real problem that
hasn't already be addressed in some other way.


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

2008-07-14 Thread C. Titus Brown

On Mon, Jul 14, 2008 at 09:37:30PM -0700, Raymond Hettinger wrote:
-> From: "Michael Foord" <[EMAIL PROTECTED]>
-> >Maybe Python needs a good mocking module in the standard library. There 
-> >are plenty, but we use a particularly nice one at Resolver Systems [1]. :-)
-> 
-> -1
-> 
-> This comes up occassionally and gets shot down.
-> http://bugs.python.org/issue708125
-> 
-> Mock objects mean different things to different people.
-> Some expect more simulated behavior and others want less.
-> It's rare to find agreement about general purpose mock objects and 
-> frameworks.
-> Mock libraries create their own complexities and burdens on a programmer's 
-> memory.
-> It's often easier to create a small special case mock object
-> than to remember how to configure a general purpose one.
-> And, afaict, there is no fan club for some particular python mock
-> object library -- it seems to only come up in general discussions
-> about possibilities for growing the unittest module, and almost
-> never comes up in the context of solving a real problem that
-> hasn't already be addressed in some other way.

Also see:

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

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

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