On 5/14/2013 7:16 AM, Ethan Furman wrote:
Thank you for being persistent. You are correct, the value should be
an IntET (at least, with a custom __new__ ;).
You know, when you look at something you wrote the night before, and
have no idea what you were trying to say, you know you were tired.
>> * Doctests practically beg you to write your code first and then copy and
>> paste terminal sessions - they're the enemy of TDD
>
> Of course , not , all the opposite . If the approach is understood
> correctly then the first thing test author will do is to write the
> code «expected» to get som
On 5/20/13, Olemis Lang wrote:
[...]
> On 5/20/13, Michael Foord wrote:
[...]
>
>> * Tool support for editing within doctests is *generally* worse
>
> this is true , let's do it !
>
[...]
>> * Typing >>> and ... all the time is really annoying
>
> ... I have faith ... there should be something li
Hi !
... sorry , I could not avoid to reply this message ...
On 5/20/13, Michael Foord wrote:
>
> On 20 May 2013, at 18:26, Mark Janssen wrote:
>
I'm hoping that core developers don't get caught-up in the "doctests are
bad
meme".
Instead, we should be clear about their p
On 5/19/2013 9:08 PM, Ethan Furman wrote:
On 05/19/2013 05:24 PM, Nick Coghlan wrote:
This is the point I was trying to make: once you use IntEnum (as you
would in any case where you need bitwise operators), Enum gets out of
the way for everything other than __str__, __repr__, and one other
slo
I don't think a python-dev discussion about the value of doctests is going to
change minds one way or the other, but I just *had* to respond to this one
point:
On May 20, 2013, at 11:26 PM, Michael Foord wrote:
>* Doctests practically beg you to write your code first and then copy and
>* paste te
On Mon, May 20, 2013 at 11:35 AM, Greg Ewing
wrote:
> Joao S. O. Bueno wrote:
>>
>> Actually, when I was thinking on the subject I came to the same idea, of
>> having
>> some functions marked differently so they would use a different call
>> mechanism -
>> but them I wondered around having a diffe
On 20 May 2013, at 18:26, Mark Janssen wrote:
>>> I'm hoping that core developers don't get caught-up in the "doctests are bad
>>> meme".
>>>
>>> Instead, we should be clear about their primary purpose which is to test
>>> the examples given in docstrings.
>>> In other words, doctests have a pe
On 21 May 2013 05:01, "Ethan Furman" wrote:
>
> On 05/20/2013 11:32 AM, Terry Jan Reedy wrote:
>>
>> On 5/20/2013 11:39 AM, Steven D'Aprano wrote:
>>>
>>> On 21/05/13 00:12, Ethan Furman wrote:
>>>
>>>
As a case in point, base64.py is currently getting a bug fix, and also
contains this c
On May 20, 2013, at 11:46 AM, Antoine Pitrou wrote:
> On Mon, 20 May 2013 07:12:07 -0700
> Ethan Furman wrote:
>>
>> As a case in point, base64.py is currently getting a bug fix, and also
>> contains this code:
>>
>> def b32decode(s, casefold=False, map01=None):
>> .
>> .
>> .
>
On 05/20/2013 11:32 AM, Terry Jan Reedy wrote:
On 5/20/2013 11:39 AM, Steven D'Aprano wrote:
On 21/05/13 00:12, Ethan Furman wrote:
As a case in point, base64.py is currently getting a bug fix, and also
contains this code:
def b32decode(s, casefold=False, map01=None):
.
.
.
On 05/20/2013 11:14 AM, Mark Janssen wrote:
I have pondered it many times, although usually in the form "Why do we
need both str and repr?"
Here's an idea: considering python objects are "stateful". Make a
general, state-query operator: "?". Then the distinction is clear.
--> ?"This is a s
On 5/20/2013 11:39 AM, Steven D'Aprano wrote:
On 21/05/13 00:12, Ethan Furman wrote:
As a case in point, base64.py is currently getting a bug fix, and also
contains this code:
def b32decode(s, casefold=False, map01=None):
.
.
.
for i in range(0, len(s), 8):
quanta
20.05.13 16:12, Ethan Furman написав(ла):
As a quick reminder, PEP 409 allows this:
try:
...
except AnError:
raise SomeOtherError from None
so that if the exception is not caught, we get the traditional single
exception traceback, instead of the new:
During han
> I have pondered it many times, although usually in the form "Why do we
> need both str and repr?"
Here's an idea: considering python objects are "stateful". Make a
general, state-query operator: "?". Then the distinction is clear.
>>> ?"This is a string" #Returns the contents of the string
On 5/19/13, Steven D'Aprano wrote:
> On 20/05/13 09:27, Gregory P. Smith wrote:
>> On Sat, May 18, 2013 at 11:41 PM, Raymond Hettinger <
>> raymond.hettin...@gmail.com> wrote:
>>
>>>
>>> On May 14, 2013, at 9:39 AM, Gregory P. Smith wrote:
>>>
>>> Bad: doctests.
>>>
>>>
>>> I'm hoping that core d
Am 20.05.2013 17:39, schrieb Steven D'Aprano:
> On 21/05/13 00:12, Ethan Furman wrote:
>
>
>> As a case in point, base64.py is currently getting a bug fix, and also
>> contains this code:
>>
>> def b32decode(s, casefold=False, map01=None): . . . for i in range(0,
>> len(s), 8): quanta = s[i: i +
>> I'm hoping that core developers don't get caught-up in the "doctests are bad
>> meme".
>>
>> Instead, we should be clear about their primary purpose which is to test
>> the examples given in docstrings.
>> In other words, doctests have a perfectly legitimate use case.
>
> But more than just one
-- Forwarded message --
From: Olemis Lang
Date: Mon, 20 May 2013 11:33:42 -0500
Subject: Re: [Python-Dev] Purpose of Doctests [Was: Best practices for Enum]
To: Antoine Pitrou
On 5/20/13, Antoine Pitrou wrote:
> On Sat, 18 May 2013 23:41:59 -0700
> Raymond Hettinger wrote:
>>
>
Hi !
:)
I'll be replying some individual messages in this thread in spite of
putting my replies in the right context . Sorry if I repeat something
, or this makes the thread hard to read . Indeed , IMHO this is a
subject suitable to discuss in TiP ML .
On 5/19/13, Gregory P. Smith wrote:
> On Sa
On Tue, 21 May 2013 02:00:32 +1000
Steven D'Aprano wrote:
> On 20/05/13 23:38, Antoine Pitrou wrote:
> > On Mon, 20 May 2013 23:32:10 +1000
> > Steven D'Aprano wrote:
> >> On 20/05/13 20:45, Antoine Pitrou wrote:
> >>> On Sat, 18 May 2013 23:41:59 -0700
> >>> Raymond Hettinger wrote:
>
> >
On 20/05/13 23:38, Antoine Pitrou wrote:
On Mon, 20 May 2013 23:32:10 +1000
Steven D'Aprano wrote:
On 20/05/13 20:45, Antoine Pitrou wrote:
On Sat, 18 May 2013 23:41:59 -0700
Raymond Hettinger wrote:
We should continue to encourage users to make thorough unit tests
and to leave doctests for
On Mon, 20 May 2013 07:12:07 -0700
Ethan Furman wrote:
>
> As a case in point, base64.py is currently getting a bug fix, and also
> contains this code:
>
> def b32decode(s, casefold=False, map01=None):
> .
> .
> .
> for i in range(0, len(s), 8):
> quanta = s[i: i +
On 21/05/13 00:12, Ethan Furman wrote:
As a case in point, base64.py is currently getting a bug fix, and also contains
this code:
def b32decode(s, casefold=False, map01=None):
.
.
.
for i in range(0, len(s), 8):
quanta = s[i: i + 8]
acc = 0
try:
On 05/20/2013 07:50 AM, R. David Murray wrote:
On Mon, 20 May 2013 07:12:07 -0700, Ethan Furman wrote:
As a case in point, base64.py is currently getting a bug fix, and also
contains this code:
def b32decode(s, casefold=False, map01=None):
.
.
.
for i in range(0, len(s),
I think that kills the "let's make all dicts ordered" idea, even for
CPython. I wouldn't want people to start relying on this. The dict type
should be clearly recognizable as the hash table it is.
Making **kwds ordered is still open, but requires careful design and
implementation to avoid slowing
On May 19, 2013, at 04:27 PM, Gregory P. Smith wrote:
>Idea: I don't believe anybody has written a fixer for lib2to3 that applies
>fixers to doctests. That'd be an interesting project for someone.
I'm not sure that's true. I don't use 2to3 anymore if I can help it, but I'm
pretty sure you can 2
On May 19, 2013, at 07:28 PM, Tim Peters wrote:
>But more than just one ;-) Another great use has nothing to do with
>docstrings: using an entire file as "a doctest". This encourages
>writing lots of text explaining what you're doing,. with snippets of
>code interspersed to illustrate that the
On Mon, May 20, 2013 at 6:39 AM, Barry Warsaw wrote:
> Or in other words, if dicts are to be ordered, let's make it an explicit
> language feature that we can measure compliance against.
Guaranteeing a dict order would be tough on Jython - today it's nice
that we can just have a thin wrapper aroun
On May 18, 2013, at 11:41 PM, Raymond Hettinger wrote:
>I'm hoping that core developers don't get caught-up in the "doctests are bad
>meme".
Thanks for your message Raymond. I know that doctests are controversial, but
I do firmly believe that when used correctly, they have value and should not
b
On Mon, 20 May 2013 07:12:07 -0700, Ethan Furman wrote:
> As a case in point, base64.py is currently getting a bug fix, and also
> contains this code:
>
> def b32decode(s, casefold=False, map01=None):
> .
> .
> .
> for i in range(0, len(s), 8):
> quanta = s[i: i + 8]
On Mon, 20 May 2013 15:57:35 +0200, Antoine Pitrou wrote:
> On Mon, 20 May 2013 09:37:32 -0400
> "R. David Murray" wrote:
> > On Mon, 20 May 2013 12:45:57 +0200, Antoine Pitrou
> > wrote:
> > > On Sat, 18 May 2013 23:41:59 -0700
> > > Raymond Hettinger wrote:
> > > >
> > > > We should continu
On 05/20/2013 06:47 AM, Nick Coghlan wrote:
On 20 May 2013 23:38, Ethan Furman wrote:
As a quick reminder, PEP 409 allows this:
try:
...
except AnError:
raise SomeOtherError from None
so that if the exception is not caught, we get the traditional single exception
trac
On Mon, 20 May 2013 09:37:32 -0400
"R. David Murray" wrote:
> On Mon, 20 May 2013 12:45:57 +0200, Antoine Pitrou
> wrote:
> > On Sat, 18 May 2013 23:41:59 -0700
> > Raymond Hettinger wrote:
> > >
> > > We should continue to encourage users to make thorough unit tests
> > > and to leave doctest
On Mon, 20 May 2013 06:12:41 -0700, Ethan Furman wrote:
> As a quick reminder, PEP 409 allows this:
>
> try:
> ...
> except AnError:
> raise SomeOtherError from None
>
> so that if the exception is not caught, we get the traditional single
> exception traceback, inst
On 20 May 2013 23:38, "Ethan Furman" wrote:
>
> As a quick reminder, PEP 409 allows this:
>
> try:
> ...
> except AnError:
> raise SomeOtherError from None
>
> so that if the exception is not caught, we get the traditional single
exception traceback, instead of the new:
>
>
On Mon, 20 May 2013 15:02:08 +0200, Stefan Drees wrote:
> On 20.05.13 14:37, Serhiy Storchaka wrote:
> > 20.05.13 01:33, Benjamin Peterson напиÑав(ла):
> >> 2013/5/19 Demian Brecht :
> >>> It seems like external docs is standard throughout the stdlib. Is
> >>> there an actual reason for t
On Mon, 20 May 2013 12:45:57 +0200, Antoine Pitrou wrote:
> On Sat, 18 May 2013 23:41:59 -0700
> Raymond Hettinger wrote:
> >
> > We should continue to encourage users to make thorough unit tests
> > and to leave doctests for documentation. That said, it should be
> > recognized that some testi
On May 20, 2013, at 02:30 PM, Armin Rigo wrote:
>Just checking: in view of Raymond's proposal, is there a good reason
>against having all dicts be systematically ordered? It would
>definitely improve the debugging experience, by making multiple runs
>of the same program more like each other, ins
On Mon, 20 May 2013 23:32:10 +1000
Steven D'Aprano wrote:
> On 20/05/13 20:45, Antoine Pitrou wrote:
> > On Sat, 18 May 2013 23:41:59 -0700
> > Raymond Hettinger wrote:
> >>
> >> We should continue to encourage users to make thorough unit tests
> >> and to leave doctests for documentation. That
As a quick reminder, PEP 409 allows this:
try:
...
except AnError:
raise SomeOtherError from None
so that if the exception is not caught, we get the traditional single exception
traceback, instead of the new:
During handling of the above exception, another exception
On 20/05/13 20:45, Antoine Pitrou wrote:
On Sat, 18 May 2013 23:41:59 -0700
Raymond Hettinger wrote:
We should continue to encourage users to make thorough unit tests
and to leave doctests for documentation. That said, it should be
recognized that some testing is better than no testing. And
On 20.05.13 14:37, Serhiy Storchaka wrote:
20.05.13 01:33, Benjamin Peterson написав(ла):
2013/5/19 Demian Brecht :
It seems like external docs is standard throughout the stdlib. Is
there an actual reason for this?
ernal
One is legacy. It certainly wasn't possible with the old LaTeX doc
system
20.05.13 01:33, Benjamin Peterson написав(ла):
2013/5/19 Demian Brecht :
It seems like external docs is standard throughout the stdlib. Is
there an actual reason for this?
ernal
One is legacy. It certainly wasn't possible with the old LaTeX doc
system.
Do you know that TeX itself written usin
Hi all,
On Sun, May 19, 2013 at 4:59 PM, Maciej Fijalkowski wrote:
> Note that raymonds proposal would make dicts and ordereddicts almost
> exactly the same speed.
Just checking: in view of Raymond's proposal, is there a good reason
against having all dicts be systematically ordered? It would
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 05/19/2013 07:22 PM, Mark Janssen wrote:
> On Sun, May 19, 2013 at 1:13 PM, Tres Seaver
> wrote:
>> -BEGIN PGP SIGNED MESSAGE- Hash: SHA1
>>
>> On 05/19/2013 10:48 AM, Guido van Rossum wrote:
>>> Anyway, if you're doing arithmetic on enums
On Sat, 18 May 2013 23:41:59 -0700
Raymond Hettinger wrote:
>
> We should continue to encourage users to make thorough unit tests
> and to leave doctests for documentation. That said, it should be
> recognized that some testing is better than no testing. And doctests
> may be attractive in that
47 matches
Mail list logo
