Re: [Python-Dev] PEP 435 - ref impl disc 2
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. Ignore my parenthetical remark. Gladly. And we now have several more days to have forgotten what we were doing/talking about... Okay, the value is now an IntET, as expected and appropriate. Maybe. I upgraded my ref435.py from yours at https://bitbucket.org/stoneleaf/ref435 (and your test file there references enum.py which is not there). My demo1.py still doesn't work. The first 4 lines are fine, but not the last two. I still cannot do a lookup (via __call__ syntax) by either int or IntET value. You have my old misnamed NEI class in your test file now, and the tests you use with it work... but you don't have a lookup test. My demo1 does, and that fails. After instrumenting Enum.__new__ it seems that the member.value is still the constructor parameters... Maybe I picked up the wrong version of your code? Oh and demo1.py has leftover __new__ and __init__ definitions for NIE, modeled after your earlier suggestions. Leaving them in causes everything to be named 'temp'. Taking them out makes things not work differently. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 409 and the stdlib
21.05.13 10:17, Hrvoje Niksic написав(ла): On 05/20/2013 05:15 PM, Ethan Furman wrote: 1) Do nothing and be happy I use 'raise ... from None' in my own libraries 2) Change the wording of 'During handling of the above exception, another exception occurred' (no ideas as to what at the moment) The word occurred misleads one to think that, during handling of the real exception, an unrelated and unintended exception occurred. This is not the case when the raise keyword is used. In that case, the exception was intentionally *converted* from one type to another. For the raise case a wording like the following might work better: The above exception was converted to the following exception: ... That makes it clear that the conversion was explicit and (hopefully) intentional, and that the latter exception supersedes the former. How do you distinguish intentional and unintentional exceptions? ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 409 and the stdlib
On 05/21/2013 10:36 AM, Serhiy Storchaka wrote: The above exception was converted to the following exception: ... That makes it clear that the conversion was explicit and (hopefully) intentional, and that the latter exception supersedes the former. How do you distinguish intentional and unintentional exceptions? By the use of the raise keyword. Given the code: try: x = d['key'] except KeyError: raise BusinessError(...) ...the explicit raising is a giveaway that the new exception was quite intentional. Hrvoje ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 435 - ref impl disc 2
On 5/20/2013 11:44 PM, Glenn Linderman wrote: 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. Ignore my parenthetical remark. Gladly. And we now have several more days to have forgotten what we were doing/talking about... Okay, the value is now an IntET, as expected and appropriate. Maybe. I upgraded my ref435.py from yours at https://bitbucket.org/stoneleaf/ref435 (and your test file there references enum.py which is not there). My demo1.py still doesn't work. The first 4 lines are fine, but not the last two. I still cannot do a lookup (via __call__ syntax) by either int or IntET value. You have my old misnamed NEI class in your test file now, and the tests you use with it work... but you don't have a lookup test. My demo1 does, and that fails. After instrumenting Enum.__new__ it seems that the member.value is still the constructor parameters... Maybe I picked up the wrong version of your code? Oh and demo1.py has leftover __new__ and __init__ definitions for NIE, modeled after your earlier suggestions. Leaving them in causes everything to be named 'temp'. Taking them out makes things not work differently. Oh, it was an hg misunderstanding (hg newbie here)... I wasn't getting the latest code. Things are working much better now. I notice, however, with my latest code at https://v_pyt...@bitbucket.org/v_python/ref435a that demo1, which has an explicit duplicate name, and no __new__ or __init__ code, has a .value which is actually a IntET (as shown by the last print of the repr of the value). However, demo2, which attempts to marry the classes and avoid the duplicate name specifications, has a .value which is an unnamed IntET, whereas one would expect it to be named. Noticing the changes you made, I think it is a result of line 177 in ref435.py where you actually instantiate a 2nd copy of IntET—using the same parameters, but a separate instantiation from the married-with-Enum copy—to use as the value. I guess there is no way to extract the IntET from the married-with-Enum copy, to use as the value? So then, this is good, but not quite good enough: the 2nd copy of the IntET should have the same name as the married-with-Enum copy. Now in demo4.py I figured out how I could fix that, since the second copy is (currently) made before the __init__ call for the married-with-Enum copy, and stored in an accessible place. On the other hand, it is a bit of a surprise to have to do that, and it would also be a bit of a surprise for classes that have class state that affects the instantiation of instances... That might just mean that some classes can't be mixed with Enum, but I suppose known restrictions and/or side effects should be documented. As an example of this, I tried to resurrect your AutoNumber from your message of 6 May 2013 19:29 -0700 in the PEP 435: initial values must be specified? Yes thread, but couldn't, apparently due to changes in the implementation of ref435, but after fixing those problems, I still got an error where it demanded a parameter to new, even though one shouldn't be needed in that case. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 409 and the stdlib
21.05.13 12:28, Hrvoje Niksic написав(ла):
On 05/21/2013 10:36 AM, Serhiy Storchaka wrote:
The above exception was converted to the following exception:
...
That makes it clear that the conversion was explicit and (hopefully)
intentional, and that the latter exception supersedes the former.
How do you distinguish intentional and unintentional exceptions?
By the use of the raise keyword. Given the code:
try:
x = d['key']
except KeyError:
raise BusinessError(...)
the explicit raising is a giveaway that the new exception was quite
intentional.
try:
x = d['key']
except KeyError:
x = fallback('key')
def fallback(key):
if key not in a:
raise BusinessError(...)
return 1 / a[key] # possible TypeError, ZeroDivisionError, etc
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 409 and the stdlib
On 05/21/2013 11:56 AM, Serhiy Storchaka wrote:
try:
x = d['key']
except KeyError:
x = fallback('key')
def fallback(key):
if key not in a:
raise BusinessError(...)
return 1 / a[key] # possible TypeError, ZeroDivisionError, etc
Yes, in that case the exception will appear unintentional and you get
the old message — it's on a best-effort basis.
Hrvoje
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 409 and the stdlib
On Tue, May 21, 2013 at 5:17 PM, Hrvoje Niksic hrvoje.nik...@avl.com wrote: On 05/20/2013 05:15 PM, Ethan Furman wrote: 1) Do nothing and be happy I use 'raise ... from None' in my own libraries 2) Change the wording of 'During handling of the above exception, another exception occurred' (no ideas as to what at the moment) The word occurred misleads one to think that, during handling of the real exception, an unrelated and unintended exception occurred. This is not the case when the raise keyword is used. In that case, the exception was intentionally *converted* from one type to another. For the raise case a wording like the following might work better: The above exception was converted to the following exception: ... That makes it clear that the conversion was explicit and (hopefully) intentional, and that the latter exception supersedes the former. This ship sailed long ago (it was covered by the original exception chaining spec in PEP 3134). If you want to deliberately replace an exception while retaining the full traceback, you use raise X from Y, and the intro text will change to something like This exception was the direct cause of the following exception: This thread is about the case where you want to use raise X from None to suppress the display of the original exception completely, which is a new capability in Python 3.3. So whenever we consider changing the standard library, we should also look at the explicit chaining option, particularly when the original exception may have happened inside a user provided callback (including method calls) Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 409 and the stdlib
21.05.13 13:05, Hrvoje Niksic написав(ла):
On 05/21/2013 11:56 AM, Serhiy Storchaka wrote:
try:
x = d['key']
except KeyError:
x = fallback('key')
def fallback(key):
if key not in a:
raise BusinessError(...)
return 1 / a[key] # possible TypeError, ZeroDivisionError, etc
Yes, in that case the exception will appear unintentional and you get
the old message — it's on a best-effort basis.
In both cases the BusinessError exception raised explicitly. How do you
distinguish one case from another?
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] What if we didn't have repr?
On 20 maj 2013, at 03:46, Guido van Rossum gu...@python.org wrote: On Sun, May 19, 2013 at 4:27 PM, Gregory P. Smith g...@krypto.org wrote: Now you've got me wondering what Python would be like if repr, `` and __repr__ never existed as language features. Upon first thoughts, I actually don't see much downside (no, i'm not advocating making that change). Something to ponder. I have pondered it many times, although usually in the form Why do we need both str and repr? What if we did the opposite? 1. Make __str__() a protocol for arbitrary string conversion. 2. Move the current __repr__() contracts, both firm and informal to a new, extensible version of pprint. There has been some discussion led by Raymond in 2010 about a general `pprint rewrite`__ and I'm willing to pick up the idea with a PEP for inclusion in 3.4. __ http://bugs.python.org/issue7434 -- Best regards, Łukasz Langa WWW: http://lukasz.langa.pl/ Twitter: @llanga IRC: ambv on #python-dev ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-checkins] cpython (3.3): #17973: Add FAQ entry for ([], )[0] += [1] both extending and raising.
On Tue, May 21, 2013 at 12:35 AM, r.david.murray python-check...@python.org wrote: Yay for having this in the FAQ, but... +If you wrote:: + +a_tuple = (1, 2) +a_tuple[0] += 1 + Traceback (most recent call last): + ... + TypeError: 'tuple' object does not support item assignment + +The reason for the exception should be immediately clear: ``1`` is added to the +object ``a_tuple[0]`` points to (``1``), producing the result object, ``2``, +but when we attempt to assign the result of the computation, ``2``, to element +``0`` of the tuple, we get an error because we can't change what an element of +a tuple points to. + +Under the covers, what this augmented assignment statement is doing is +approximately this:: + +result = a_tuple[0].__iadd__(1) +a_tuple[0] = result + Traceback (most recent call last): + ... + TypeError: 'tuple' object does not support item assignment For the immutable case, this expansion is incorrect: hasattr(0, __iadd__) False With immutable objects, += almost always expands to: result = a_tuple[0] + 1 a_tuple[0] = result (For containers that support binary operators, the presence of the relevant __i*__ methods is actually a reasonable heuristic for distinguishing the mutable and immutable versions) Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 409 and the stdlib
On 05/21/2013 02:57 PM, Serhiy Storchaka wrote:
21.05.13 13:05, Hrvoje Niksic написав(ла):
On 05/21/2013 11:56 AM, Serhiy Storchaka wrote:
try:
x = d['key']
except KeyError:
x = fallback('key')
def fallback(key):
if key not in a:
raise BusinessError(...)
return 1 / a[key] # possible TypeError, ZeroDivisionError, etc
Yes, in that case the exception will appear unintentional and you get
the old message — it's on a best-effort basis.
In both cases the BusinessError exception raised explicitly. How do you
distinguish one case from another?
In my example code the raise keyword appears lexically inside the
except clause. The compiler would automatically emit a different
raise opcode in that case.
NB in your example the raise is just as intentional, but invoked from
a different function, which causes the above criterion to result in a
false negative. Even in so, the behavior would be no worse than now,
you'd just get the old message.
Hrvoje
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] What if we didn't have repr?
Actually changing __str__ or __repr__ is out of the question, best we can
do is discourage makingbthem different. But adding a protocol for pprint
(with extra parameters to convey options) is a fair idea. I note that Nick
sggested to use single-dispatch generic functions for this though. Both
have pros and cons. Post design ideas to python-ideas please, not here!
--Guido
On Tuesday, May 21, 2013, Łukasz Langa wrote:
On 20 maj 2013, at 03:46, Guido van Rossum
gu...@python.orgjavascript:_e({}, 'cvml', 'gu...@python.org');
wrote:
On Sun, May 19, 2013 at 4:27 PM, Gregory P. Smith
g...@krypto.orgjavascript:_e({}, 'cvml', 'g...@krypto.org');
wrote:
Now you've got me wondering what Python would be like if repr, `` and
__repr__ never existed as language features. Upon first thoughts, I
actually
don't see much downside (no, i'm not advocating making that change).
Something to ponder.
I have pondered it many times, although usually in the form Why do we
need both str and repr?
What if we did the opposite?
1. Make __str__() a protocol for arbitrary string conversion.
2. Move the current __repr__() contracts, both firm and informal to a new,
extensible version of pprint.
There has been some discussion led by Raymond in 2010 about a general
`pprint rewrite`__ and I'm willing to pick up the idea with a PEP for
inclusion in 3.4.
__ http://bugs.python.org/issue7434
--
Best regards,
Łukasz Langa
WWW: http://lukasz.langa.pl/
Twitter: @llanga
IRC: ambv on #python-dev
--
--Guido van Rossum (python.org/~guido)
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 409 and the stdlib
On Tue, May 21, 2013 at 11:23 PM, Hrvoje Niksic hrvoje.nik...@avl.com wrote: In my example code the raise keyword appears lexically inside the except clause. The compiler would automatically emit a different raise opcode in that case. Hrvoje, can we drop this subthread please. The topic was addressed way back when PEP 3134 was written, and there is already dedicated syntax to distinguish incidental exceptions in error handlers (raise new) from deliberate replacement of an exception with a new one (raise new from original) Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 409 and the stdlib
On Tue, 21 May 2013 01:39:03 +1000, Steven D'Aprano st...@pearwood.info 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 = s[i: i + 8]
acc = 0
try:
for c in quanta:
acc = (acc 5) + b32rev[c]
except KeyError:
raise binascii.Error('Non-base32 digit found')
.
.
.
else:
raise binascii.Error('Incorrect padding')
Does the KeyError qualify as irrelevant noise?
[...]
In another reply, R.David Murray answered:
I don't see that it is of benefit to suppress [the KeyError].
Can I suggest that it's obviously been a long, long time since you
were a beginner to the language, and you've forgotten how intimidating
error messages can be? Error messages should be *relevant*. Irrelevant
details don't help, they hinder, and I suggest that the KeyError is
irrelevant.
Doubtless you are correct. Now that you mention it I do remember being
confused, even as an experienced programmer, by the chained exceptions
when I first started dealing with them, but at this point I suppose it
has become second nature :).
I agree with the subsequent discussion that this error is a good case
for 'from None', given that any such conversion should make sure all
essential information is contained in the new error message. And I agree
with Nick that there are probably many more places where 'raise from'
will help clarify things when we *don't* want 'from None'.
--David
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] PEP 442 delegate
Hello, I would like to nominate Benjamin as BDFL-Delegate for PEP 442. Please tell me if you would like to object :) Regards Antoine. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 442 delegate
2013/5/21 Antoine Pitrou solip...@pitrou.net: Hello, I would like to nominate Benjamin as BDFL-Delegate for PEP 442. Please tell me if you would like to object :) I think he's a scoundrel. -- Regards, Benjamin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 442 delegate
No objections. Benjamin, don't accept it until we've had a chance to talk this over in person. I think we'll see a lot of each other starting next week... :-) On Tue, May 21, 2013 at 9:00 AM, Benjamin Peterson benja...@python.org wrote: 2013/5/21 Antoine Pitrou solip...@pitrou.net: Hello, I would like to nominate Benjamin as BDFL-Delegate for PEP 442. Please tell me if you would like to object :) I think he's a scoundrel. -- Regards, Benjamin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/guido%40python.org -- --Guido van Rossum (python.org/~guido) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 409 and the stdlib
On 05/21/2013 04:23 AM, Nick Coghlan wrote: On Tue, May 21, 2013 at 5:17 PM, Hrvoje Niksic hrvoje.nik...@avl.com wrote: On 05/20/2013 05:15 PM, Ethan Furman wrote: 1) Do nothing and be happy I use 'raise ... from None' in my own libraries 2) Change the wording of 'During handling of the above exception, another exception occurred' (no ideas as to what at the moment) The word occurred misleads one to think that, during handling of the real exception, an unrelated and unintended exception occurred. This is not the case when the raise keyword is used. In that case, the exception was intentionally *converted* from one type to another. For the raise case a wording like the following might work better: The above exception was converted to the following exception: ... That makes it clear that the conversion was explicit and (hopefully) intentional, and that the latter exception supersedes the former. This ship sailed long ago (it was covered by the original exception chaining spec in PEP 3134). If you want to deliberately replace an exception while retaining the full traceback, you use raise X from Y, and the intro text will change to something like This exception was the direct cause of the following exception: I had forgotten about that, Nick, thanks. So the moral of the story for our library code and replacing exceptions is we should either do raise ... from OldException or raise ... from None depending on the importance of the originating exception. And, of course, we only make these changes when we're already modifying the module for some other reason. -- ~Ethan~ ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Is thread-safe smtpd desired/possible?
Hi, I am posting this here since I could find no active maintainer of the smtpd module. In my work as a test engineer for Axis (www.axis.com) I encountered the need of having thread-safe SMTP servers. I know the use case of several SMTP servers running in concurrent threads might seem odd, but it can actually be quite useful for testing purposes. I have implemented (for my own use) a possible solution which basically means that every SMTP channel has its own socket map, instead of using asyncore's global socket map. It would not involve any change in asyncore. Looking at the disucssion from http://bugs.python.org/issue11959 it seems to me that such a solution would not be accepted. Do you think that modifying asyncore is more feasible? If not, is this something that might be looked at? I can provide code if needed, but I would first like to know your thoughts about this. Best regards, Sorin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Is thread-safe smtpd desired/possible?
On Tue, 21 May 2013 18:50:23 +0200, Sorin Stelian sorin.stel...@axis.com wrote: I am posting this here since I could find no active maintainer of the smtpd module. Currently I am effectively the maintainer of that module, though other people are helping out. In my work as a test engineer for Axis (www.axis.com) I encountered the need of having thread-safe SMTP servers. I know the use case of several SMTP servers running in concurrent threads might seem odd, but it can actually be quite useful for testing purposes. I have implemented (for my own use) a possible solution which basically means that every SMTP channel has its own socket map, instead of using asyncore's global socket map. It would not involve any change in asyncore. Looking at the disucssion from http://bugs.python.org/issue11959 it seems to me that such a solution would not be accepted. Do you think that modifying asyncore is more feasible? If not, is this something that might be looked at? I can provide code if needed, but I would first like to know your thoughts about this. I don't think issue 11959 represents a categorical rejection of improvements here; however, I suspect that tulip has an impact on this. Regardless of that, any changes need to be discussed in a wider context than just the smtpd module, no matter where changes are actually made. --David ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] What if we didn't have repr?
Łukasz Langa wrote: 1. Make __str__() a protocol for arbitrary string conversion. 2. Move the current __repr__() contracts, both firm and informal to a new, extensible version of pprint. -1. The purposes of repr() and pprint() are quite different. Please let's not make any sweeping changes about str() and repr(). They're generally okay as they are, IMO. -- Greg ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Purpose of Doctests [Was: Best practices for Enum]
On 5/20/13, Mark Janssen dreamingforw...@gmail.com wrote: * 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 something done . When everything is ok with API code style then write the code . Many problems in the API and inconsistencies are thus detected early . Now all we need is a test() built-in, a companion to help() and we have the primo platform for doctest-code-test cycle for TDD and agile development. «test() built-in» , interesting observation ... at least to me setup.py test is more than enough in real-life , and I guess many people really involved in building APIs for sure will notice that in real life it's not as simple as «doctest-code-test» ; in the same way that TDD is not always exactly like what is read in the books . However writing doctests first for APIs could definitely be helpful to think in advance in terms of the clients , especially when there are some aspects looking a bit fuzzy . Nevertheless , what is really needed , like I've been saying (elsewhere) since years ago , is a better doctest module . The API in stdlib does not offer the means to really benefit of its potential (= that does not mean it's bad , it might be better ;) . Above I was talking about testing libraries defining APIs . In the meantime following the approach sketched above , it's been possible (at least to me) to develop tested documented RESTful + RPC APIs with relatively little effort . Besides , the differences between RPC and functions due to subtle technological implementation details may be erased . Using the approach I've sketched in previous messages it's also possible to run the very same doctests for APIs that are meant to work transparently locally or hosted online (e.g. pastebins ... or other services in the cloud) . The only thing needed is to use the right implementation of doctests setUp / tearDown e.g. switching from Python functions to ServerProxy , or REST , or ... ... so , yes , it's proven to be useful in practice ... -- Regards, Olemis. Apache™ Bloodhound contributor http://issues.apache.org/bloodhound Blog ES: http://simelo-es.blogspot.com/ Blog EN: http://simelo-en.blogspot.com/ Featured article: ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
