Re: [Zope-dev] BUG: ValueError while changing height of the templateedit window
Casey Duncan wrote: On Tuesday 10 December 2002 03:14 pm, Guido van Rossum wrote: Can we get the same patch without the generic except:, please? the last thing I want is a database corruption caused by resizing the Edit box... Why would this particular except clause cause database corruption? I think Leonard is refering to catching ConflictErrors. However I don't think int() touches the database ;^). I saw try: int() except: pattern in many places through all the Zope code. I think catching ValueError only does the job, but then we should replace it in all the places. :-) -- Dmitry Vasiliev (dima at hlabs.spb.ru) ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] BUG: ValueError while changing height of the templateedit window
Guido van Rossum wrote:
Can we get the same patch without the generic except:, please?
snipped part about whether there could be database corruption
int() happens to raise a bunch of different exceptions, and I think
an unqualified except: clause is okay here (though it needs a
comment).
I think this would be a useful note for the Zope3 style guide.
What exceptions can int() raise?
On converting a preexisting value to an int:
ValueError, OverflowError, TypeError, AttributeError
(Any others?)
On converting an instance that implements __int__:
Anything at all.
It can even return a non-int value.
On evaluating the expression inside the int() brackets:
Anything at all.
I would suggest that only the four exceptions I listed first are worth
catching. The other cases are programming errors.
Of those four exceptions, in this situation, I think you only need to
catch ValueError. The other cases are application logic errors that I
think it is counterproductive to catch. If you get one, there is a bug
in some code, or some template, that should be fixed.
Here's how I produced the errors listed in the first category:
int('xxx')
Traceback (most recent call last):
File stdin, line 1, in ?
ValueError: invalid literal for int(): xxx
import sys
int(sys.maxint+1)
Traceback (most recent call last):
File stdin, line 1, in ?
OverflowError: long int too large to convert to int
int(int)
Traceback (most recent call last):
File stdin, line 1, in ?
TypeError: int() argument must be a string or a number
int(AttributeError())
Traceback (most recent call last):
File stdin, line 1, in ?
AttributeError: AttributeError instance has no attribute '__int__'
--
Steve Alexander
___
Zope-Dev maillist - [EMAIL PROTECTED]
http://lists.zope.org/mailman/listinfo/zope-dev
** No cross posts or HTML encoding! **
(Related lists -
http://lists.zope.org/mailman/listinfo/zope-announce
http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] BUG: ValueError while changing height of the template edit window
On Wednesday 11 December 2002 03:43 am, Dmitry Vasiliev wrote: Casey Duncan wrote: On Tuesday 10 December 2002 03:14 pm, Guido van Rossum wrote: Can we get the same patch without the generic except:, please? the last thing I want is a database corruption caused by resizing the Edit box... Why would this particular except clause cause database corruption? I think Leonard is refering to catching ConflictErrors. However I don't think int() touches the database ;^). I saw try: int() except: pattern in many places through all the Zope code. I think catching ValueError only does the job, but then we should replace it in all the places. :-) Nope, as Guido pointed out (and he should know ;^), Int can raise miriad exceptions. not just ValueError. IMO as long as the int is the *only* thing happening in the try block and you comment the bare except, then we are ok. Changing the except clause will only introduce bugs. -Casey ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] BUG: ValueError while changing height of the template edit window
I saw try: int() except: pattern in many places through all the Zope code. I think catching ValueError only does the job, but then we should replace it in all the places. :-) Yes, catching ValueError is sufficient for string conversions to int. I thought you could get an OverflowError, but that can only happen when the input is a Python long or float -- int(999) raises ValueError, as does int(xxx). --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] BUG: ValueError while changing height of the template edit window
I think this would be a useful note for the Zope3 style guide. What exceptions can int() raise? On converting a preexisting value to an int: ValueError, OverflowError, TypeError, AttributeError (Any others?) On converting an instance that implements __int__: Anything at all. It can even return a non-int value. On evaluating the expression inside the int() brackets: Anything at all. Anything can raise MemoryError. On converting an 8bit string to an int: ValueError *only* On converting a Unicode string to an int: ValueError UnicodeError (or UnicodeEncodeError, which is a subclass of it) --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
[Zope-dev] Guido van Rossum: Re: [ZODB-Dev] Fwd: [Zope3-dev] directory hierarchy proposal (MartijnFaassen)
Sorry, cc'ed the wrong list. :-( --- Forwarded Message Date:Wed, 11 Dec 2002 10:29:12 -0500 From:Guido van Rossum [EMAIL PROTECTED] To: [EMAIL PROTECTED] (Jeremy Hylton) cc: [EMAIL PROTECTED] Subject: Re: [ZODB-Dev] Fwd: [Zope3-dev] directory hierarchy proposal (Martijn Faassen) SA Can they be methods on objects, rather than functions in a SA module? Just what I asked Tim :-). There are as many as six functions -- difference, union, intersection, weightedUnion, weightedIntersection, and multiunion. The functions operate on sets; they accept any of XY family of objects. So it's not obvious what they would be methods of. Each object -- Set, TreeSet, Bucket, BTree -- could get a copy of the code, but that seems a little silly. Perhaps it could be defined on a common base class? duck - --Guido van Rossum (home page: http://www.python.org/~guido/) --- End of Forwarded Message ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] BUG: ValueError while changing height of the templateedit window
Anything can raise MemoryError. Ok. But I don't think regular application code should catch these. On converting an 8bit string to an int: ValueError *only* Ok. On converting a Unicode string to an int: ValueError UnicodeError (or UnicodeEncodeError, which is a subclass of it) Can you provide an example of raising a unicode error like this: u = makeUnicodeString() # your choice of function int(u) My point is that once you have a valid unicode object, I don't see how calling int(valid_unicode_object) will raise a UnicodeError. If this is so, then the style should be: value = expression_to_compute_value try: i = int(value) except ValueError: # take corrective action rather than: try: i = int(expression_to_compute_value) except: # Note: calling 'int()' can raise just about anything # take corrective action -- Steve Alexander ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] BUG: ValueError while changing height of the template edit window
Anything can raise MemoryError. Ok. But I don't think regular application code should catch these. Correct. On converting an 8bit string to an int: ValueError *only* Ok. On converting a Unicode string to an int: ValueError UnicodeError (or UnicodeEncodeError, which is a subclass of it) Can you provide an example of raising a unicode error like this: u = makeUnicodeString() # your choice of function int(u) In Python 2.3, I get this: int(u\u1234) Traceback (most recent call last): File stdin, line 1, in ? UnicodeEncodeError: 'decimal' codec can't encode character '\u1234' in position 0: invalid decimal Unicode string In Python 2.2, this raises ValueError. I think I may have to report this as a bug in Python 2.3 though. My point is that once you have a valid unicode object, I don't see how calling int(valid_unicode_object) will raise a UnicodeError. If this is so, then the style should be: value = expression_to_compute_value try: i = int(value) except ValueError: # take corrective action rather than: try: i = int(expression_to_compute_value) except: # Note: calling 'int()' can raise just about anything # take corrective action Even if we decide that we have to use a bare except after all, the expression_to_compute_value should still be moved outside the try/except. --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Infuriating ZClass registry Heisenbug
Shane Hathaway wrote: Shot in the dark #2: Does it enter the ClassFactory function in Zope.ClassFactory? That's part of the ZClass magic... although there are two ways that the pickler tries to load classes. ZODB only tries to load Persistent instances as ZClasses. If there are things inside the pickles that are not Persistent, yet come from a ZClass, ZODB will not treat them kindly. As far as I can tell, it doesn't enter *any* Python code. Unless there's some other reason for pdb to be unable to step into it, it seems to execute only C code right up to the ImportError. By contrast, I *was* able to trace through ClassFactory when it loaded the BTree -- the trace would then fail when loading the first Bucket. Apparently small OOBTrees store their state differently, because the trace fails on the OOBTree load now, and I can do unpickler.noload() and see the state tuple with all the keys and None where the ZClasses should be. Shot in the dark #3: Unfortunately, there's one bit of ZODB that I still don't fully understand, and that's setklassstate(). You might be running into this somehow. I'd hazard a guess that the latest cPickleCache does not do the right thing with setklassstate(), since no one has committed to maintain that part. Ugh, we need unit tests for that. I had never heard of it -- I'll have to take a peek. Here's a simple suggestion: after loading the site and browsing a few pages involving ZClasses, flush the ZODB cache and see if the bug appears right away. If so, it's probably occurring as a result of deactivation. I had pretty much been assuming that that was the case, but performing this test confirms it. Flushing the cache breaks things immediately. ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] BUG: ValueError while changing height of the template edit window
Can you provide an example of raising a unicode error like this: u = makeUnicodeString() # your choice of function int(u) In Python 2.3, I get this: int(u\u1234) Traceback (most recent call last): File stdin, line 1, in ? UnicodeEncodeError: 'decimal' codec can't encode character '\u1234' in position 0: invalid decimal Unicode string In Python 2.2, this raises ValueError. I spoke too soon. UnicodeEncodeError is a subclass of ValueError. So catching ValueError from int(str_or_unicode) is the way to go. Who's writing that Zope 3 style guide again? --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] BUG: ValueError while changing height of the templateedit window
I spoke too soon. UnicodeEncodeError is a subclass of ValueError. So catching ValueError from int(str_or_unicode) is the way to go. Who's writing that Zope 3 style guide again? Great. http://dev.zope.org/Wikis/DevSite/Projects/ComponentArchitecture/ZopePythonStyleGuide -- Steve Alexander ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
[Zope-dev] zope book volunteering
I am incredibly happy to report that many folks are signing up to edits chapters of the Zope Book in preparation for the upcoming Zope 2.6.1 release! It's really beating the cynicism out of me! ;-) As a matter of fact, so many people are signing up that I'm getting *multiple* submissions of the same chapters! While this is a wonderful problem to have, I don't want folks to waste effort doing something that somebody else has already committed to. I have put up a page documenting signups and current status for the editing effort at http://www.zope.org/DocProjects/zope_book_signups/index_html . Hopefully this will serve as a place that I can keep track of who is doing what. Here are the chapters in the 2.6 edition of the Zope Book ( http://www.zope.org/Documentation/Books/ZopeBook/2_6Edition/index_html ) that are not yet spoken for: Maintaining Zope Extending Zope (ZClasses) Advanced DTML Searching and Categorizing Content If anyone aspires to edit some Zope docs and get some fame and glory, the time is now. ;-) - C ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] zope book volunteering
On Wed, 2002-12-11 at 20:14, Chris McDonough wrote: Here are the chapters in the 2.6 edition of the Zope Book ( http://www.zope.org/Documentation/Books/ZopeBook/2_6Edition/index_html ) that are not yet spoken for: Maintaining Zope Extending Zope (ZClasses) Advanced DTML Searching and Categorizing Content Whoops! I think I made a mistake in the above. I think Bakhtiar Hamid picked up Extending Zope (maybe he can speak up if this isn't the case). ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Infuriating ZClass registry Heisenbug
More data: It may well be loading correctly, but it seems to be storing incorrectly. I managed to grab the ZGlobals pickle string, and it has the _zclass_ stored as a plain class instead of an oid. I copied the commented-out Python persistent_id() in ZODB/Connections.py into a method called test_persistent_id(), and compared its results with coptimizations' new_persistent_id. They matched for everything except _zclass_ objects, for which test_persistent_id returned the _p_oid and new_persistent_id returned None. I have no idea why this is. It would explain why the _zclass_es are stored wrongly, but not why everyone else isn't seeing major breakage. Argh, Evan @ 4-am ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Infuriating ZClass registry Heisenbug
I think I've fixed my ZGlobals, but there's definitely a problem in coptimizations. I made Connections.py use the Python persistent_id, restarted twice, and ZGlobals was fine on the second restart. Whew, Evan @ 4-am ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Infuriating ZClass registry Heisenbug
On Wed, 11 Dec 2002, Evan Simpson wrote: I think I've fixed my ZGlobals, but there's definitely a problem in coptimizations. I made Connections.py use the Python persistent_id, restarted twice, and ZGlobals was fine on the second restart. Ah-ha, you now have a reproducible test case. The coptimizations code has been undergoing beautification lately; apparently this particular ZClass-related functionality was not retained correctly. This ought to be a priority for Zope 2.6, I think. Shane ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Infuriating ZClass registry Heisenbug
On Wednesday 11 December 2002 11:13 pm, Shane Hathaway wrote: On Wed, 11 Dec 2002, Evan Simpson wrote: I think I've fixed my ZGlobals, but there's definitely a problem in coptimizations. I made Connections.py use the Python persistent_id, restarted twice, and ZGlobals was fine on the second restart. Ah-ha, you now have a reproducible test case. The coptimizations code has been undergoing beautification lately; apparently this particular ZClass-related functionality was not retained correctly. This ought to be a priority for Zope 2.6, I think. I think we should call a memoratorium on code beautification for its own sake, especially C code. Too much pain for too little gain. I'd be willing to bet the code's still ugly anyhow ;^) -Casey ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
