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) ne
-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, addin
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 mod
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 de
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 rem
"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
"M.-A. Lemburg" <[EMAIL PROTECTED]> writes:
> The PEP doesn't mention changing the module name and deprecating
> the old one.
Right. The intention is to have a PEP-8-conformant 'unittest' module,
not an entirely new module.
> Instead it wants to deprecate all the old names (and cites PEP 4 for
>
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 t
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 actual
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 upgrade
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 co
"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
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 side
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
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
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
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
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
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
"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
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,
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
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
23 matches
Mail list logo