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
On 2008-07-16 02:20, Collin Winter wrote:
On Tue, Jul 15, 2008 at 6:58 AM, Ben Finney [EMAIL PROTECTED] wrote:
Significant updates include removing all reference to the
(already-resolved) new-style class issue, adding footnotes and
references, and a Rationale summary of discussion on both sides
M.-A. Lemburg [EMAIL PROTECTED] writes:
Since this is a major change in the unit test API, I'd also like
to suggest that you use a new module name.
This is both a precaution to prevent tests failing due to not having
been upgraded and a way for old code to continue working by adding
the
On 2008-07-16 10:14, Ben Finney wrote:
M.-A. Lemburg [EMAIL PROTECTED] writes:
Since this is a major change in the unit test API, I'd also like
to suggest that you use a new module name.
This is both a precaution to prevent tests failing due to not having
been upgraded and a way for old code
M.-A. Lemburg wrote:
On 2008-07-16 10:14, Ben Finney wrote:
M.-A. Lemburg [EMAIL PROTECTED] writes:
Since this is a major change in the unit test API, I'd also like
to suggest that you use a new module name.
This is both a precaution to prevent tests failing due to not having
been upgraded
Terry Reedy wrote:
Michael Foord wrote:
Collin Winter wrote:
Is any provision being made for a 2to3 fixer/otherwise-automated
transition for the changes you propose here?
As the deprecation is intended for 2.X and 3.X - is 2to3 fixer needed?
A fixer will only be needed when it
On 2008-07-16 14:02, Michael Foord wrote:
M.-A. Lemburg wrote:
On 2008-07-16 10:14, Ben Finney wrote:
M.-A. Lemburg [EMAIL PROTECTED] writes:
Since this is a major change in the unit test API, I'd also like
to suggest that you use a new module name.
This is both a precaution to prevent
M.-A. Lemburg [EMAIL PROTECTED] writes:
On 2008-07-16 14:02, Michael Foord wrote:
M.-A. Lemburg wrote:
Note that PEP 4 targets deprecating use of whole modules, not
single APIs, or - like in your case - more or less the complete
existing API of a module.
Which PEP is usually
On Tue, Jul 15, 2008 at 6:03 PM, Michael Foord
[EMAIL PROTECTED] wrote:
Collin Winter wrote:
On Tue, Jul 15, 2008 at 6:58 AM, Ben Finney [EMAIL PROTECTED]
wrote:
Backwards Compatibility
===
The names to be obsoleted should be deprecated and removed according
to the
On Wed, Jul 16, 2008 at 5:21 AM, Michael Foord
[EMAIL PROTECTED] wrote:
Terry Reedy wrote:
Michael Foord wrote:
Collin Winter wrote:
Is any provision being made for a 2to3 fixer/otherwise-automated
transition for the changes you propose here?
As the deprecation is intended for 2.X and
On 2008-07-16 15:12, Ben Finney wrote:
M.-A. Lemburg [EMAIL PROTECTED] writes:
On 2008-07-16 14:02, Michael Foord wrote:
M.-A. Lemburg wrote:
Note that PEP 4 targets deprecating use of whole modules, not
single APIs, or - like in your case - more or less the complete
existing API of a
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
M.-A. Lemburg wrote:
On 2008-07-16 02:20, Collin Winter wrote:
On Tue, Jul 15, 2008 at 6:58 AM, Ben Finney [EMAIL PROTECTED] wrote:
Significant updates include removing all reference to the
(already-resolved) new-style class issue, adding
Tres Seaver wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
M.-A. Lemburg wrote:
On 2008-07-16 02:20, Collin Winter wrote:
On Tue, Jul 15, 2008 at 6:58 AM, Ben Finney [EMAIL PROTECTED] wrote:
Significant updates include removing all reference to the
(already-resolved)
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
Ben Finney writes:
Removal of ``assert*`` names
Arguments in favour of retaining only the ``assert*`` names:
* BDFL preference: The BDFL has stated [#vanrossum-1]_ a preference
for the ``assert*`` names.
* Precedent: The Python standard library
On Tue, Jul 15, 2008 at 3:20 PM, Stephen J. Turnbull [EMAIL PROTECTED] wrote:
* Positive admonition: The ``assert*`` names state the intent of how
the code under test *should* behave, while the ``fail*`` names are
phrased in terms of how the code *should not* behave.
FWIW, I think
Stephen J. Turnbull [EMAIL PROTECTED] writes:
FWIW, I think these are fairly stated. So fairly that I'm surprised
you haven't been persuaded!wink
I'm not persuaded because I find the arguments for 'fail*' more
persuasive :-)
I am, however, convinced that the consensus of the community is
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:
On Wed, 16 Jul 2008 08:13:22 am Guido van Rossum wrote:
Tests in the standard distribution which use the deprecated
style will need to be converted. Steven d'Aprano claims this is
nontrivial (and thus error- prone) in some cases. I haven't seen
that claim denied, and it seems plausible
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
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
Stephen J. Turnbull wrote:
Ben Finney writes:
Removal of ``assert*`` names
Arguments in favour of retaining only the ``assert*`` names:
* BDFL preference: The BDFL has stated [#vanrossum-1]_ a preference
for the ``assert*`` names.
* Precedent:
22 matches
Mail list logo
