[Python-Dev] Tag trackbacks with version (was Re: readd u'' literal support in 3.3?)
Steven D'Aprano
steve at pearwood.info
Sat Dec 10 18:52:37 CET 2011
Terry Reedy wrote:
> On 12/9/2011 5:17 AM, Nick Coghlan wrote:
>
>> As Chris pointed out though, the real problem with the "repeatedly run
>> 2to3" workflow is that it can make interpreting tracebacks from the
>> field *really* hard.
>
> This just gave me the idea of tagging tracebacks with the Python version
> number. Something like
>
> Traceback (Py3.2.2, most recent call last):
>
> and perhaps with the platform also
>
> Traceback (most recent call last) [Py3.2.2 on win23]:
>
> Since computation has stopped, the few extra milliseconds is trivial.
> This would certainly help on Python list and the tracker when people do
> post the traceback (which they do not always) without version and system
> (which they often do not, especially on Python list). It might suggest
> to people that this is important info to include.
[...]
But how often is it actually important information to include?
I am active on both the tutor and the python-list lists, and it seems to me
that this proposed feature won't be very useful in either place. In my
experience, the version number is rarely important for the sorts of questions
that are commonly asked. Python is quite a stable language, and alist =
alist.append(1) has confused newbies since version 1.5 and will probably
continue confusing them in version 4000. (Aside: I was reading historical
What's New docs today, and was stunned to realise how many cool features go
back all the way to version 2.0.)
Obviously there are times where knowing the version is useful, but often you
can often derive the version number from the error (at least to 1 significant
figure):
>>> map(chr, (40, 41, 42))[1]
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
TypeError: 'map' object is not subscriptable
Assuming map has not been shadowed, this is obviously Python 3.
If the question involves tracking down an actual bug in Python, the version
number becomes important. E.g. "it works as documented in 2.6 on Linux, but
not in 2.7 on OS-X" sort of thing. But that's quite unusual.
Newbies barely read tracebacks at all. Adding the version number and platform
will just add more text which they won't read and will probably discourage
them further from reading it (more text = less chance they read it).
Experienced coders tend to know when the version number is important and
provided it only when necessary. So it's hard to see who this is aimed at...
users experienced enough to pay attention to tracebacks but not experienced
enough to know when to provide the version number?
YMMV, but I don't see much value in this. If it comes at the cost of making
doctest harder to use, I'm actively against it. Otherwise I'm just mildly
"meh, why bother?".
--
Steven
More information about the Python-Dev
mailing list