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 )
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
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
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] 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 )
[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] 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 )
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 "", 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] 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
> > 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 "", 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] 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 )
[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? - --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 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 )
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
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 )
[Zope-dev] Feedback wanted on Zope/CMF/Plone product developing - you might really want to read this;-)
Hi everyone, **READABILITY ALERT: text too long** **NEWBIE ALERT: New to Python/Zope/CMF/Plone. Please bear with my ignorance.** First, appologies sorry for cross postng, but I needed to access wider audience for feedback. I hope this will be my last shot at clearing up any doubts about the way I'm developing Zope/CMF/Plone products. Please enlighten me if I'm wrong. First, a bit of background why I'm posting this. I have a set of three products finished just a few hours ago: NeoBoard 1.1b1, NeoPortal Library, and NeoPortal Content Pak. NeoPortal Library NeoPortal Library is a collection of base modules on which to build sophisticated Zope/CMF/Plone products such as NeoBoard. NeoBoard NeoBoard is a threaded message board ( http://www.neoboard.net ). There's a HUGE gap between 1.0x versions and 1.1a, and another QUANTUM LEAP between the last 1.1a2 and soon-to-be-released 1.1b1. Most of its core features have been refactored into NeoPortal Library. NB supports stock Zope and CMF, and Plone. Works the same with or without CMF or Plone. NeoPortal Content Pak NeoPortal Content Pak is a collection of CMFPlone content types. It's dependent on Plone but I wouldn't call it Plone product since I don't fully follow the Plone developing guides. With NCP comes NeoPortal Document, NP File, NP Image, NP External File, NP Article, NP Link, NP Media, NP Container/Element pairs ( eg. NeoPortal Aritlce is a container and NeoPortal Page Element or Image Element type is an element ), plus all their advanced counterparts that offer additional features: DTML handling for example. As of 0.9a, NPC has 20 or so new content types and a couple of NeoPortal content-specific tools. NCP is an add-on to CMFPlone. Some common features include (every feature can be toggled on and off either in a site-wide or individual manner):: - backtalk like inline commenting ( factored out from NeoBoard ) - automatic conversion of textual notations into icons ( emoticons, for example ) - OLE-like object embedding ( one object can embed another; changes in embedded objects are automtically updated in embedding objects, etc ); even inline comments can embed and render other objects; NeoPortal object embedding follows the rules of acquisition - element-type-aware Containers like NeoPortal Article/Advanced Article ( automatic renumbering/navigation: you get your sequenceable photo albums in a second, for example ) - external data access ( External File and ExternalAccess tool - the tool supports filesystem access only as of 0.9a ; will support MySQL, etc; - a whole directory ( and its subdirectories ) of files on the server can be imported into corresponding NeoPortal External Files - individual content-rating and daily access logging ( IP-based and purgeable by specific interval of days ) - a new discussion tool for new content-types ( creates a NeoBoard instance when discussion is enabled ); you get everything NeoBoard offers for content discussion - site-wide configuration and instance-specific configuration that can override the former - togglable IP-based spam-blocking ( one can't comment on an article twice in less than 10 seconds, for example, to prevent malicious duplicate postings ) to name a few (that's quite a few;-). NeoBoard comes with the same set of bells and whistles since it's basically a NeoPortal Element container and its articles/attachments are NeoPortal Elements, you get the idea. Need Your Help/Feedback Now here's what I'm not sure about. 1. Some fear granting users filesystem accesss is a real bad idea. You can specify file bases (/home/ZopeHome/archives, for example) NeoPortal External Files validate against given an absolute filepath at the time of their instantiatioin raising error if a user tries to go up the file bases. That's the solution I came up for filesystem security. NeoPortal Content Pak currently allows users with AddPortalContent permissions to use this mass-importing features from a given directory: one can FTP his files to one of the allowed directoy bases and import them into NeoPortal External Files in one go. If you import a set of images into a NeoPortal Article ( a NeoPortal container) , that is your auto-navigatable photo album, for example. In fact, I have tons of audio files that should be imported into my own Zope server to serve up our users. That's why I created the feature. Am I missing anything here? 2. The new discussion tool appends a acquisition-wrapped discussion board ( np_neoboard.__of__( self ) ) to instances as a normal property so that a board can be attachable to a non-folderish object (guess that's how it works with CMF anyway). Works just fine, but again... am I missing something? 3. Might be simple but haven't been able to find answers: how do I go about i18n'ing Zope internal messages like you do with ZPT's i18n tags? Every NeoPortal classes u
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?
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 "", line 1, in ?
ValueError: invalid literal for int(): xxx
>>> import sys
>>> int(sys.maxint+1)
Traceback (most recent call last):
File "", line 1, in ?
OverflowError: long int too large to convert to int
>>> int(int)
Traceback (most recent call last):
File "", line 1, in ?
TypeError: int() argument must be a string or a number
>>> int(AttributeError())
Traceback (most recent call last):
File "", 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 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 )
