Bugs item #1117048, was opened at 2005-02-05 17:50 Message generated for change (Comment added) made by walterbrunswick 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: WalterBrunswick (walterbrunswick) Date: 2005-04-21 22:59 Message: Logged In: YES user_id=1164416 As much as I'd like to take credit for writing the constants module, credit goes to Alex Martelli who submitted the script to the ActiveState Programmer Network (http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/652 07); however, I did append the __getattr__ attribute, as well as __delattr__ -- that is where the errors occurred. But again, lest we forget, the issue is the dictionary parsing problem, which I have clearly marked. But as it has been mentioned, data is streamed in blocks rather than buffered, as to save memory. I'm closing this report. Sorry for any inconvenience. ---------------------------------------------------------------------- Comment By: Sean Reifschneider (jafo) Date: 2005-04-19 23:48 Message: Logged In: YES user_id=81797 Just to chime in, I am ok with the current behavior. ---------------------------------------------------------------------- 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 _______________________________________________ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
