[ python-Bugs-1117048 ] Dictionary Parsing Problem
SourceForge.net
noreply at sourceforge.net
Thu Feb 17 05:30:54 CET 2005
Bugs item #1117048, was opened at 2005-02-05 17:50
Message generated for change (Comment added) made by tjreedy
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: Terry J. Reedy (tjreedy)
Date: 2005-02-16 23:30
Message:
Logged In: YES
user_id=593130
The Python interpreter does not print blank lines except as
requested. While a starting linefeed would look nicer in this
particular circumstance (error while outputting), I would not
want it for two reasons: 1) the circumstance is extremely
rare, should usually only result from a program bug, and
cannot hardly be detected, so a starting linefeed would
nearly always produce an extraneous blank line; 2) without
the linefeed, it is completely clear that the error occured in
mid-sentence, so to speak.
Looking at the informative output, which I don't see as
nasty, I see the following:
* the error occurred while trying to get the repr of the object
(a module) associated with the name 'const'.
* in const, you defined a function with the special name
__getattr__, which apparently gets treated as a method that
overrides the default. (I was not aware you could do this for
modules.)
* because of the presence of __getattr__, or perhaps
because of something else in const, repr() asked const, via
__getattr__, whether it has a method __repr__.
* your __getattr__ raised proprietary const.ConstError
* since this is something other than the expected "return the
(computed) attribute value or raise an AttributeError
exception" (Ref Man 3.3.2 Customizing attribute access),
this ended the globals() call and triggered a traceback.
Without seeing the code for const, I wonder whether you
really need a custom __setattr__ and __getattr__ (once
fixed) or should get rid of them and use the default
mechanism.
Unless you see a real bug that I missed, please close this
report.
----------------------------------------------------------------------
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