[ python-Bugs-1117048 ] Dictionary Parsing Problem
SourceForge.net
noreply at sourceforge.net
Thu Feb 17 01:08:15 CET 2005
Bugs item #1117048, was opened at 2005-02-05 17:50
Message generated for change (Comment added) made by linkmastersab
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1117048&group_id=5470
Category: Python Interpreter Core
Group: None
Status: Open
Resolution: None
Priority: 2
Submitted By: WalterBrunswick (walterbrunswick)
Assigned to: Nobody/Anonymous (nobody)
Summary: Dictionary Parsing Problem
Initial Comment:
Python Version: Python 2.4
OS Version: Microsoft Windows XP [Version 5.1.2600]
There may or may not be (according to some people on
#python on irc.freenode.net) a fault, if you will, in
the way that Python evaluates dictionaries (in this
case, globals()).
<titanstar> apparently printing of dicts are optimized
not to produce the entire output string before
printing it
This may be an advantage when it comes to processing
speed and memory management, but when it comes to
catching errors, this could very well be a problem.
(I am waltz.)
...
<waltz> you think it should print a dict with an error
in it?
<waltz> ha! caught ya there!
<dash> well, if there's an error, it should break.
<dash> and it did.
<waltz> It shouldn't print AT ALL.
<dash> why not?
<waltz> Because of the ERROR!
...
I'm saying it should raise an abstract exception
(something like DictError) BEFORE printing, as to
allow the programmer to handle the error.
Some people don't agree with my argument, but I'll let
you (the core developers) decide what's best. I just
thought I should mention this issue, to help improve
Python to the max!
----------------------------------------------------------------------
Comment By: Scott Baldwin (linkmastersab)
Date: 2005-02-16 19:08
Message:
Logged In: YES
user_id=1135743
My opinion on the most feasible solution is to simple insert
a linebreak before the traceback begins, so that the
traceback stands out more. An exception for this kind of
trivial bug is too expensive for any good that would come
out of it.
----------------------------------------------------------------------
Comment By: Scott Baldwin (linkmastersab)
Date: 2005-02-16 19:05
Message:
Logged In: YES
user_id=1135743
My opinion on the most feasible solution is to simple insert
a linebreak before the traceback begins, so that the
traceback stands out more. An exception for this kind of
trivial bug is too expensive for any good that would come
out of it.
----------------------------------------------------------------------
Comment By: WalterBrunswick (walterbrunswick)
Date: 2005-02-16 18:05
Message:
Logged In: YES
user_id=1164416
The interpreter begins parsing the dictionary immediately,
without buffering and checking for errors beforehand. In
the case that an error occurs, such as a faulty key, the
interpreter outputs a nasty-looking error - including the
error message as part of the dictionary, as you can see
from the log (ErrorLog2.log). There is no way that this can
be prevented without locating the source of the problem.
What I'm saying is that the interpreter should catch the
error and raise an exception. But as you said, parsing data
streams in chunks is standard; however, I can't see any way
around this problem.
----------------------------------------------------------------------
Comment By: Terry J. Reedy (tjreedy)
Date: 2005-02-16 15:07
Message:
Logged In: YES
user_id=593130
What do you mean by 'dict with an error in it'? I don't know
that I can produce such a thing with Python. Or how globals
could have an error.
I suppose you could give a dict an unprintable key or value
(by having __str__ raise an exception), but I would consider
that a bug in the program and an error in the key/value and
not the dict. I think the behavior on trying to print a
collection with such nasty objects is best left undefined.
Or do you have something else in mind?
In any case, reading and writing data streams in chunks is
standard practice. If a dict were large enough, its text
representation would not even fit in RAM all at once.
And, in any case ... Bug reports should give a specific
example of the purported bug, complete with cut and paste
of (minimal) code and output or error trace. They may need
a reference to the relevant section of the manuals. If you
don't have a verifiable example, please close this.
Specific feature requests can be submitted as an RFE.
Design discussions should be kept to discussion forums.
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1117048&group_id=5470
More information about the Python-bugs-list
mailing list