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

I see mostly ``dict.has_key() not supported in 3.x;`` and sometimes ``DeprecationWarning: callable() not supported in 3.x;`` . and if someone with commit rights would take i would volunteer to fix these two on case by case basis, even if it is not my case. all the best ___

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

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

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

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 wh

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

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 metho

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

Significant changes: Add a new 'TestLoader.load_tests_from_collection' method, with full reference implementation. This makes the 'run_tests' reference implementation straightforward. :PEP: XXX :Title: Frequently-requested additional features for the `unittest` module :Version:

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

Stephen J. Turnbull wrote: Ben Finney writes: > Removal of ``assert*`` names > > Arguments in favour of retaining only the ``assert*`` names: > > * BDFL preference: The BDFL has stated [#vanrossum-1]_ a preference > for the ``assert*`` names. > > * Prec

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

Greg Ewing wrote: Ben Finney wrote: Nick Coghlan <[EMAIL PROTECTED]> writes: > the shortest > possible way of writing negative assertions (i.e. asserting that > something is not the case) is to treat them as denials and use the > single word 'deny'. This, to me, is neither intuitive nor meanin

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

Antoine Pitrou <[EMAIL PROTECTED]> writes: > (and don't tell me "fail" is not a negative word, because you just > used the phrase "positive admonition" to refer to the assert* > variants, which implies quite clearly that the fail* variants are on > the negative side ;-)) This "fail is a negative

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

Michael Foord <[EMAIL PROTECTED]> writes: > The full list of changes proposed […] and not shot down was > something like: […] >assertLessThan >assertGreaterThan >assertLessThanOrEquals >assertGreaterThanOrEquals […] "Brett Cannon" <[EMAIL PROTECTED]> writes: > Is any of this rea

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

Ben Finney wrote: Scott Dial <[EMAIL PROTECTED]> writes: Why [introduce redundant test names]? To answer the question: The above tests are logically equivalent, but the failure message would be different, reporting failure in terms of what the caller wanted to test. I can see how this argum

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

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_equa

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

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

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

Ben Finney wrote: New condition tests --- def assert_less_than(first, second, msg=None): op = operator.lt self.assert_compare_true(op, first, second, msg) def assert_greater_than(first, second, msg=None): op = operator.gt

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

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

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

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 depreca

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

Ben Finney wrote: Nick Coghlan <[EMAIL PROTECTED]> writes: > the shortest > possible way of writing negative assertions (i.e. asserting that > something is not the case) is to treat them as denials and use the > single word 'deny'. This, to me, is neither intuitive nor meaningful in context. Th

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

Richard Thomas wrote: I've been told by a couple of non-programmers that "failUnless" is more intuitive than "assert" if only for the reason that its unclear what "assert" might do. But test frameworks are for use by programmers, not non-programmers. Given that it's a test framework, would a p

[Python-Dev] Bug 3139

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 But 3139 appears important enough to hold up beta 2. http://bugs.python.org/issue3139 bytearrays are not thread safe Can we get this fixed by tomorrow? Does anybody disagree that we should hold up the release for this one? We don't have much tim

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

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

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

Ben Finney wrote: Nick Coghlan <[EMAIL PROTECTED]> writes: One option for rationalising the API would be to merely keep the shortest version of each phrase (i.e. use assert* instead of fail_unless* for the positive tests and fail_if* instead of assert_not* for the negative tests, and always drop

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

On Wed, 16 Jul 2008 08:13:22 am Guido van Rossum wrote: > > Tests in the standard distribution which use the deprecated > > style will need to be converted. Steven d'Aprano claims this is > > nontrivial (and thus error- prone) in some cases. I haven't seen > > that claim denied, and it seems pl

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

On Tue, Jul 15, 2008 at 4:45 PM, Barry Warsaw <[EMAIL PROTECTED]> wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > On Jul 15, 2008, at 2:38 PM, Brett Cannon wrote: > >> On Tue, Jul 15, 2008 at 5:32 AM, Barry Warsaw <[EMAIL PROTECTED]> wrote: >>> >>> -BEGIN PGP SIGNED MESSAGE- >>

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

> So far I have "precedent and tradition" and "positive admonition looks > better" in support of preferring the 'assert*' names. Are there any > others? Avoiding double negatives. (and don't tell me "fail" is not a negative word, because you just used the phrase "positive admonition" to refer to

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

On Tue, 15 Jul 2008 06:32:53 pm Stephen J. Turnbull wrote: > Steven D'Aprano writes: > > On Mon, 14 Jul 2008 04:27:40 pm Stephen J. Turnbull wrote: > > > FWIW, I meant 10 != not not 10. > > > > > >>> 10 != not not 10 > > > > File "", line 1 > > 10 != not not 10 > > ^ > >

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

Jonathan Lange wrote: My name's Jonathan, and I spell "set up" as "set up" and "tear down" as "tear down". In English, it depends on how they're being used. As nouns they're single words, as verbs they're two words. As function names, they could be read either way, so it comes down to readabi

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

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Jul 15, 2008, at 2:38 PM, Brett Cannon wrote: On Tue, Jul 15, 2008 at 5:32 AM, Barry Warsaw <[EMAIL PROTECTED]> wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 A reminder: the second betas of Python 2.6 and 3.0 are schedule for tomorrow.

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

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 I realized that the previous schedule really called for a release today 7/15 because I'm a bit busy tomorrow night. In any event, let's try to stick to doing it on 7/16. - -Barry -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (Darwin) iQ

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

Significant changes are resolving to remove the 'fail*' names, giving recommended name to use for each removed name, and further summary of related discussion. :PEP: XXX :Title: Consolidating names in the `unittest` module :Version: 0.3 :Last-Modified: 2008

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

"Stephen J. Turnbull" <[EMAIL PROTECTED]> writes: > FWIW, I think these are fairly stated. So fairly that I'm surprised > you haven't been persuaded! I'm not persuaded because I find the arguments for 'fail*' more persuasive :-) I am, however, convinced that the consensus of the community is th

Re: [Python-Dev] Proposed unittest changes

"Guido van Rossum" <[EMAIL PROTECTED]> writes: > It would, however, be a shame if we couldn't agree to *add* a bunch > of features, for example better reporting when two lists or long > strings differ. I intend to phrase such additions in terms of PEP-8-only names, so this name consolidation seem

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

Tres Seaver <[EMAIL PROTECTED]> writes: > FWIW: Zope2: 16878 'assert*', 2892 'fail*'. Thanks. > I would keep both by preference, rather than insist on a "foolish > consistency." The "consistency" argument leads to the PEP 8 names. The removal of redundant names is not made in the name of cons

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

Nick Coghlan <[EMAIL PROTECTED]> writes: > A somewhat odd thought that occurred to me is that the shortest > possible way of writing negative assertions (i.e. asserting that > something is not the case) is to treat them as denials and use the > single word 'deny'. -1 This, to me, is neither intu

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

"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

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

On Tue, Jul 15, 2008 at 3:23 PM, Terry Reedy <[EMAIL PROTECTED]> wrote: > > > Benjamin Peterson wrote: >> >> On Tue, Jul 15, 2008 at 12:37 PM, Guido van Rossum <[EMAIL PROTECTED]> >> wrote: >>> >>> I wonder if it might not be simpler (at least in some cases) to just >>> disable the warnings for cer

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

On Tue, Jul 15, 2008 at 3:34 PM, Ben Finney <[EMAIL PROTECTED]> wrote: > That's exactly the problem with the 'assert*' names: The test methods > of TestCase *don't* do the same thing as the Python 'assert' > statement, and aren't meant to. The association is confusing, even > (especially?) if one k

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

"C. Titus Brown" <[EMAIL PROTECTED]> writes: > On Tue, Jul 15, 2008 at 03:00:30PM +0100, Richard Thomas wrote: > -> I've been told by a couple of non-programmers that "failUnless" > -> is more intuitive than "assert" if only for the reason that its > -> unclear what "assert" might do. This is simi

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

Benjamin Peterson wrote: On Tue, Jul 15, 2008 at 12:37 PM, Guido van Rossum <[EMAIL PROTECTED]> wrote: I wonder if it might not be simpler (at least in some cases) to just disable the warnings for certain modules? I imagine in many cases fixing up the 2.6 code to suppress -3 warnings would be

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

On Tue, Jul 15, 2008 at 3:20 PM, Stephen J. Turnbull <[EMAIL PROTECTED]> wrote: > > * Positive admonition: The ``assert*`` names state the intent of how > > the code under test *should* behave, while the ``fail*`` names are > > phrased in terms of how the code *should not* behave. > > FWIW,

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

Ben Finney writes: > Removal of ``assert*`` names > > Arguments in favour of retaining only the ``assert*`` names: > > * BDFL preference: The BDFL has stated [#vanrossum-1]_ a preference > for the ``assert*`` names. > > * Precedent: The Python standard lib

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

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

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

Benjamin Peterson <[EMAIL PROTECTED]> wrote: > Can we push branches? The git-daemon is setup as read-only. If you have write access to the SVN repository then you can push back changes using git-svn. That's quite a nice way to work, IMHO and provides an easy path for people who are used to Subver

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

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

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

On Tue, Jul 15, 2008 at 1:04 PM, Neil Schemenauer <[EMAIL PROTECTED]> wrote: > On Mon, Jul 14, 2008 at 09:31:47PM -0400, Barry Warsaw wrote: >> Neil, we should try to host them on code.python.org. > > I was hoping to get a sense of the interest. Oh well, if you build > it they might come. ;-) I've

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

On Tue, Jul 15, 2008 at 3:04 PM, Neil Schemenauer <[EMAIL PROTECTED]> wrote: > On Mon, Jul 14, 2008 at 09:31:47PM -0400, Barry Warsaw wrote: >> Neil, we should try to host them on code.python.org. > > I was hoping to get a sense of the interest. Oh well, if you build > it they might come. ;-) I've

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

On Mon, Jul 14, 2008 at 09:31:47PM -0400, Barry Warsaw wrote: > Neil, we should try to host them on code.python.org. I was hoping to get a sense of the interest. Oh well, if you build it they might come. ;-) I've written draft instructions, temporarily at .

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

On 15-Jul-08, at 6:05 AM, Andrew Bennetts wrote: Ben Finney wrote: "Stephen J. Turnbull" <[EMAIL PROTECTED]> writes: That measured only usage of unittest *within the Python standard library*. Is that the only body of unittest-using code we need consider? Three more data points then: bzr: 13

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

On Tue, Jul 15, 2008 at 5:32 AM, Barry Warsaw <[EMAIL PROTECTED]> wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > A reminder: the second betas of Python 2.6 and 3.0 are schedule for > tomorrow. I will try to hang out on #python-dev today and will start > looking at the trackers and bu

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

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Andrew Bennetts wrote: > Ben Finney wrote: >> "Stephen J. Turnbull" <[EMAIL PROTECTED]> writes: >> >>> Ben Finney writes: >>> >>> > Removal of ``assert*`` names >>> > >>> > >>> > There is no overwhelming consensus on w

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

On Tue, Jul 15, 2008 at 12:37 PM, Guido van Rossum <[EMAIL PROTECTED]> wrote: > > I wonder if it might not be simpler (at least in some cases) to just > disable the warnings for certain modules? I imagine in many cases > fixing up the 2.6 code to suppress -3 warnings would be mere busywork > -- e.g

Re: [Python-Dev] ctypes assertion failure

Tim Golden schrieb: > This problem was raised on the comtypes-users list > as it prevents comtypes from being imported on Python 2.6 > at the moment. > > http://bugs.python.org/issue3258 > > I'll try to find the time to step through to code to work out > what's going on, but it's inside the innar

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

On Fri, Jul 11, 2008 at 1:16 PM, Brett Cannon <[EMAIL PROTECTED]> wrote: > No, we should eat our own dog food and transition the code over. If > anything it will help with code maintenance between 2.x and 3.x. Agreed. It would be annoying to users trying to clear their own code of -3 warnings if t

Re: [Python-Dev] Proposed unittest changes

http://lists.idyll.org/pipermail/testing-in-python/2007-November/000406.html & associated thread, for those interested in the variety of mock libraries... That might be a good beginning for an updateable wiki page on mock libraries. ___ Python-De

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

Stephen J. Turnbull wrote: Yes, for the purposes of this PEP. We already know that many people want various different things. You want fail* /rather than/ assert*, but Steven d'Aprono wants /both/, and I prefer assert* /exclusively/. I don't see why we all shouldn't be satisfied[1], so the c

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 follo

Re: [Python-Dev] Proposed unittest changes

On Mon, Jul 14, 2008 at 11:55 PM, somebody wrote: > I'm surprised nobody (that I've noticed) has brought up the point yet that [...] Not picking on whoever wrote that specifically, but if there's anything that surprises me, it's how many people have voiced opinions already (including many of them

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

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

Re: [Python-Dev] Mercurial mirrors

On 15/07/2008, Antoine Pitrou <[EMAIL PROTECTED]> wrote: > Paul Moore gmail.com> writes: > > > > Personally, I use convert, because it's more robust on WIndows (there > > were a few commits with case clashes which hgsvn can't get past on a > > Windows box). > > If the convert extension is finally

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

Nick Coghlan <[EMAIL PROTECTED]> writes: > While true, that doesn't change the fact that fail_if_almost_equal is > an undesirably long method name. fail_if_near ? ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinf

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

On Tue, Jul 15, 2008 at 03:00:30PM +0100, Richard Thomas wrote: -> On Tue, Jul 15, 2008 at 2:48 PM, Ben Finney <[EMAIL PROTECTED]> wrote: -> > So far I have "precedent and tradition" and "positive admonition looks -> > better" in support of preferring the 'assert*' names. Are there any -> > others?

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

Nick Coghlan wrote: One option for rationalising the API would be to merely keep the shortest version of each phrase (i.e. use assert* instead of fail_unless* for the positive tests and fail_if* instead of assert_not* for the negative tests, and always drop the trailing 's' from 'equals'). Disc

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

On Tue, Jul 15, 2008 at 2:48 PM, Ben Finney <[EMAIL PROTECTED]> wrote: > So far I have "precedent and tradition" and "positive admonition looks > better" in support of preferring the 'assert*' names. Are there any > others? I've been told by a couple of non-programmers that "failUnless" is more in

Re: [Python-Dev] Mercurial mirrors

Paul Moore gmail.com> writes: > > Personally, I use convert, because it's more robust on WIndows (there > were a few commits with case clashes which hgsvn can't get past on a > Windows box). If the convert extension is finally usable for incremental mirroring, then it's good news. I don't want t

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

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 name

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

On Tue, 15 Jul 2008 08:54:25 pm Jeroen Ruigrok van der Werven wrote: > Some greps on random Python projects give me a 4-10:1 ratio for > assert* versus fail*. Without knowing what those "random" projects are, or what the grep was, it's impossible to interpret that statistic. For example, is it b

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

Andrew Bennetts <[EMAIL PROTECTED]> writes: > Ben Finney wrote: > > "Stephen J. Turnbull" <[EMAIL PROTECTED]> writes: > > > Message-ID: <[EMAIL PROTECTED]> > > > From: Antoine Pitrou <[EMAIL PROTECTED]> > > > > That measured only usage of unittest *within the Python standard > > library*. Is that

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

On Tue, Jul 15, 2008 at 5:04 AM, Ben Finney <[EMAIL PROTECTED]> wrote: > "Benjamin Peterson" <[EMAIL PROTECTED]> writes: >> >> Line 94-95 in unittest.py (trunk): >> # All classes defined herein are 'new-style' classes, allowing use of >> 'super()' >> __metaclass__ = type > > Hmm, you're right; I s

Re: [Python-Dev] Mercurial mirrors

On 15/07/2008, Antoine Pitrou <[EMAIL PROTECTED]> wrote: > Paul Moore gmail.com> writes: > > > > If we're setting up a variety of DVCS systems there, I'd be willing to > > set up Mercurial repos (I have my own local one, just trunk at the > > moment but py3k would be easy enough to add). > > Using

Re: [Python-Dev] Proposed unittest changes

On Tue, 15 Jul 2008 04:55:59 pm Thomas Lotze wrote: > I'm surprised nobody (that I've noticed) has brought up the point yet > that test code is a lot easier to read if it makes positive > assertions. Please don't claim that your subjective opinion is an objective fact. > When reading failure c

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

On Tue, Jul 15, 2008 at 8:32 AM, Barry Warsaw <[EMAIL PROTECTED]> wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > A reminder: the second betas of Python 2.6 and 3.0 are schedule for > tomorrow. I will try to hang out on #python-dev today and will start > looking at the trackers and bu

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

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

Re: [Python-Dev] Mercurial mirrors

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

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

On Tue, Jul 15, 2008 at 1:32 PM, Barry Warsaw <[EMAIL PROTECTED]> wrote: > If there is anything you need a decision on, please follow up to this > thread. I'm inundated with email so I can't watch every thread on the > mailing lists. Or ping me on #python-dev. Can I request permission to check i

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

Ben Finney wrote: > "Stephen J. Turnbull" <[EMAIL PROTECTED]> writes: > > > Ben Finney writes: > > > > > Removal of ``assert*`` names > > > > > > > > > There is no overwhelming consensus on whether to remove the > > > ``assert*`` names or the ``fail*`` names; >

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

Nick Coghlan <[EMAIL PROTECTED]> writes: > Ben Finney wrote: > > What makes that happen in the case where a class declares no > > superclass? Is there an invisible enforced "__metaclass__ = type" > > for every module? Where can I read about this change? > > The magic is actually in 2.x, not in 3.

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

Nick Coghlan <[EMAIL PROTECTED]> writes: > fail_if_almost_equal is an undesirably long method name. I disagree. It says what the method does, as precisely as necessary to distinguish it from other methods of the class. It is as long as it needs to be to say that while still being readable and PEP

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

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

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

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Jul 15, 2008, at 6:41 AM, Paul Moore wrote: On 15/07/2008, Barry Warsaw <[EMAIL PROTECTED]> wrote: In case anyone is interested, I have git repositories for both the trunk and the py3k branch of the Python source code. They are up-to-date and s

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

Ben Finney writes: > > Message-ID: <[EMAIL PROTECTED]> > > From: Antoine Pitrou <[EMAIL PROTECTED]> > > That measured only usage of unittest *within the Python standard > library*. Is that the only body of unittest-using code we need > consider? Yes, for the purposes of this PEP. We alrea

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

Ben Finney wrote: Eric Smith <[EMAIL PROTECTED]> writes: Ben Finney wrote: "Benjamin Peterson" <[EMAIL PROTECTED]> writes: Line 94-95 in unittest.py (trunk): # All classes defined herein are 'new-style' classes, allowing use of 'super()' __metaclass__ = type Hmm, you're right; I see that in

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

Ben Finney wrote: self.fail_if_almost_equal('were already on the 34th column before' 'writing anything substantive', self.testedobject.tested_method(arg1, arg2 +

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

On 15/07/2008, Raymond Hettinger <[EMAIL PROTECTED]> wrote: > > ``set_up(…)`` > > Replaces ``setUp(…)`` > > > . . > > ``tear_down(…)`` > > Replaces ``tearDown(…)`` > > > > Am I the only one who finds this sort of excessive pep-8 underscoring to be > horrorific? No. > Nobody I know spells setup

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

-On [20080715 12:35], Ben Finney ([EMAIL PROTECTED]) wrote: >That measured only usage of unittest *within the Python standard >library*. Is that the only body of unittest-using code we need >consider? Some greps on random Python projects give me a 4-10:1 ratio for assert* ve

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

On 15/07/2008, Barry Warsaw <[EMAIL PROTECTED]> wrote: > > In case anyone is interested, I have git repositories for both the > > trunk and the py3k branch of the Python source code. They are > > up-to-date and so using them with git-svn would be much faster than > > starting from scratch. > > > >

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

"Stephen J. Turnbull" <[EMAIL PROTECTED]> writes: > Ben Finney writes: > > > Removal of ``assert*`` names > > > > > > There is no overwhelming consensus on whether to remove the > > ``assert*`` names or the ``fail*`` names; > > 7 to 1 is overwhelming in my book

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

Eric Smith <[EMAIL PROTECTED]> writes: > Ben Finney wrote: > > "Benjamin Peterson" <[EMAIL PROTECTED]> writes: > >> Line 94-95 in unittest.py (trunk): > >> # All classes defined herein are 'new-style' classes, allowing use of > >> 'super()' > >> __metaclass__ = type > > > > Hmm, you're right; I s

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

"Raymond Hettinger" <[EMAIL PROTECTED]> writes: > > ``set_up(…)`` > > Replaces ``setUp(…)`` > . . > > ``tear_down(…)`` > > Replaces ``tearDown(…)`` > > Am I the only one who finds this sort of excessive pep-8 > underscoring to be horrorific? > > Nobody I know spells setup and teardown as two w

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

Ben Finney wrote: "Benjamin Peterson" <[EMAIL PROTECTED]> writes: On Mon, Jul 14, 2008 at 6:42 PM, Ben Finney <[EMAIL PROTECTED]> wrote: The `unittest` module will gain the following attribute, to set the default metaclass for classes in the module and thus make all classes in the module part

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

"Benjamin Peterson" <[EMAIL PROTECTED]> writes: > On Mon, Jul 14, 2008 at 6:42 PM, Ben Finney <[EMAIL PROTECTED]> wrote: > > The `unittest` module will gain the following attribute, to set the > > default metaclass for classes in the module and thus make all classes > > in the module part of the n

Re: [Python-Dev] Proposed unittest changes

Michael Foord wrote: Raymond Hettinger wrote: From: "Ben Finney" <[EMAIL PROTECTED]> Right, so I'm putting up a separate PEP just for the renaming. Should be arriving on this list soon. I would like to work with you or someone else who is interested on an alternative PEP for a separate, simpl

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

Ben Finney writes: > Removal of ``assert*`` names > > > There is no overwhelming consensus on whether to remove the > ``assert*`` names or the ``fail*`` names; 7 to 1 is overwhelming in my book. See Message-ID: <[EMAIL PROTECTED]> From: Antoine Pitrou <[EMAIL P

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

Raymond Hettinger writes: > Nobody I know spells setup and teardown as two words. I set up a house of cards. When I'm done, I'm done with setup. Similarly for "tear down" and "teardown". The two word forms are verbs, the one word forms are nouns. I don't think it's worth a column to make that

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

Steven D'Aprano writes: > On Mon, 14 Jul 2008 04:27:40 pm Stephen J. Turnbull wrote: > > > FWIW, I meant 10 != not not 10. > > >>> 10 != not not 10 > File "", line 1 > 10 != not not 10 > ^ > SyntaxError: invalid syntax > > With respect, I think that the fact that you

Re: [Python-Dev] Proposed unittest changes

Thomas Lotze wrote: Ben Finney wrote: I'd count this as another (minor) point in favour of making the 'fail*' methods canonical: the names are consistent *and* gramatically sensible: -1 I'm surprised nobody (that I've noticed) has brought up the point yet that test code is a lot easier to re