Bad: doctests.
On Tue, May 14, 2013 at 5:08 AM, Steven D'Aprano wrote:
> On 14/05/13 16:51, Gregory P. Smith wrote:
> [...]
>
> This sounds like a feature request for doctest. doctest could be educated
>> about enums and automatically compare to the integer value for such cases.
>>
>
> Please
On 14/05/13 16:51, Gregory P. Smith wrote:
[...]
This sounds like a feature request for doctest. doctest could be educated
about enums and automatically compare to the integer value for such cases.
Please no. Enums are not special enough to break the rules.
Good: "Doctests look at the object'
On Sun, May 12, 2013 at 4:49 PM, Raymond Hettinger <
raymond.hettin...@gmail.com> wrote:
>
> * will enums break doctests or any existing user code
>
Those are already broken by design. We shouldn't be limited just because
someone wrote a bad test that assumed a particular repr of a value. We've
On 05/13/2013 12:06 AM, Raymond Hettinger wrote:
Ethan's email suggests that against my advice he is in-fact going to go through
the standard library, applying enums
quite broadly.
I think you are falling victim to Wizard's First Rule: people will believe what
they want to be true, or are af
On May 12, 2013, at 04:49 PM, Raymond Hettinger wrote:
>After the long design effort for the enum module, I'm sure there will be a
>forthcoming effort to apply them pervasively throughout the standard library.
We usually, explicitly, try not to do such wholesale adoptions in the stdlib
when new f
Raymond Hettinger wrote:
> I would like to ask for a little restraint and for there to
> be individual cost/benefit evaluations for each case.
+1
> For external constants, some thought needs to be given to:
> * is the current API working just fine (i.e. decimal's ROUND_DOWN)
For compatibility
Le Mon, 13 May 2013 00:06:52 -0700,
Raymond Hettinger a écrit :
>
> On May 12, 2013, at 8:26 PM, Eli Bendersky wrote:
>
> > Thanks for the insights, Raymond. I don't think anyone is planning
> > on rushing anything. We still have to get the enum module itself
> > committed and a serious review
On May 12, 2013, at 8:26 PM, Eli Bendersky wrote:
> Thanks for the insights, Raymond. I don't think anyone is planning on rushing
> anything. We still have to get the enum module itself committed and a serious
> review process has just started for that, so it will take time.
>
> There's no ge
On 05/12/2013 08:15 PM, Stephen J. Turnbull wrote:
Ethan Furman writes:
> I will certainly ask for advice on which modules to spend my time
> on. I know enums are not a cure-all, but they are great for
> debugging and interactive work.
Especially in new code where they are used throughou
Thanks for the insights, Raymond. I don't think anyone is planning on
rushing anything. We still have to get the enum module itself committed and
a serious review process has just started for that, so it will take time.
There's no general "let's replace all constants with enums" TODO item that
I k
Ethan Furman writes:
> I will certainly ask for advice on which modules to spend my time
> on. I know enums are not a cure-all, but they are great for
> debugging and interactive work.
Especially in new code where they are used throughout. Not so in the
existing stdlib, I expect.
The concre
On 05/12/2013 04:49 PM, Raymond Hettinger wrote:
After the long design effort for the enum module,
I'm sure there will be a forthcoming effort to apply
them pervasively throughout the standard library.
I'd like to apply them where it makes sense. It would be a good way for me to learn all that
12 matches
Mail list logo
