BUG: ValueError while changing height of the template edit window
Hi All! Zope 2.6: pressing of "Taller" or "Shorter" buttons of the page template edit window raises ValueError. Patch attached. -- Dmitry Vasiliev (dima at hlabs.spb.ru) Index: ZopePageTemplate.py =================================================================== RCS file: /cvs-repository/Zope/lib/python/Products/PageTemplates/ZopePageTemplate.py,v retrieving revision 1.44 diff -u -r1.44 ZopePageTemplate.py --- ZopePageTemplate.py 18 Sep 2002 15:12:46 -0000 1.44 +++ ZopePageTemplate.py 10 Dec 2002 14:33:43 -0000 @@ -155,8 +155,11 @@ cols = min(cols, 100) # Max width 100% cols = "%d%%" % cols # Add percent sign back on else: # Absolute width - try: cols = int(width) - except: cols = max(40, int(dtpref_cols) + szchw.get(width, 0)) + try: + cols = int(width) + except: + cols = max(40, int(dtpref_cols[:-1]) + szchw.get(width, 0)) + cols = "%d%%" % cols # Add percent sign back on try: rows = int(height) except: rows = max(1, int(dtpref_rows) + szchh.get(height, 0))
Please submit a collector issue for this http://collector.zope.org/Zope so the patch doesn't get lost. Thanks. -Casey On Tuesday 10 December 2002 10:07 am, Dmitry Vasiliev wrote:
Hi All!
Zope 2.6: pressing of "Taller" or "Shorter" buttons of the page template edit window raises ValueError. Patch attached.
-- Dmitry Vasiliev (dima at hlabs.spb.ru)
Casey Duncan wrote:
Please submit a collector issue for this http://collector.zope.org/Zope so the patch doesn't get lost.
I tried it first, but my zope member login hadn't work yet and I had a problem with file uploading. I'm new with the collector, was I doing some things wrong? -- Dmitry Vasiliev (dima at hlabs.spb.ru)
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... On Tue, 2002-12-10 at 13:07, Dmitry Vasiliev wrote:
Hi All!
Zope 2.6: pressing of "Taller" or "Shorter" buttons of the page template edit window raises ValueError. Patch attached.
-- Dmitry Vasiliev (dima at hlabs.spb.ru) ----
Index: ZopePageTemplate.py =================================================================== RCS file: /cvs-repository/Zope/lib/python/Products/PageTemplates/ZopePageTemplate.py,v retrieving revision 1.44 diff -u -r1.44 ZopePageTemplate.py --- ZopePageTemplate.py 18 Sep 2002 15:12:46 -0000 1.44 +++ ZopePageTemplate.py 10 Dec 2002 14:33:43 -0000 @@ -155,8 +155,11 @@ cols = min(cols, 100) # Max width 100% cols = "%d%%" % cols # Add percent sign back on else: # Absolute width - try: cols = int(width) - except: cols = max(40, int(dtpref_cols) + szchw.get(width, 0)) + try: + cols = int(width) + except: + cols = max(40, int(dtpref_cols[:-1]) + szchw.get(width, 0)) + cols = "%d%%" % cols # Add percent sign back on
try: rows = int(height) except: rows = max(1, int(dtpref_rows) + szchh.get(height, 0)) -- Ideas don't stay in some minds very long because they don't like solitary confinement.
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? int() happens to raise a bunch of different exceptions, and I think an unqualified except: clause is okay here (though it needs a comment). Also note that the unpatched code has an unqualified except: already, so you can't really blame Dmitry. --Guido van Rossum (home page: http://www.python.org/~guido/)
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 ;^).
int() happens to raise a bunch of different exceptions, and I think an unqualified except: clause is okay here (though it needs a comment).
Yup and please reformat the other try: except: if you reformat the first one.
Also note that the unpatched code has an unqualified except: already, so you can't really blame Dmitry.
I say blame Canada! -Casey
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)
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
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("999999999999999") raises ValueError, as does int("xxx"). --Guido van Rossum (home page: http://www.python.org/~guido/)
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
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/)
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
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/)
participants (5)
-
Casey Duncan -
Dmitry Vasiliev -
Guido van Rossum -
Leonardo Rochael Almeida -
Steve Alexander