Re: [Zope-dev] Zope 2.3.1b1, strange things when ConflictError.
On Sun, 25 Feb 2001, Steve Alexander wrote: I wasn't reading the code clearly the first time around. By far the simplest place to return copied results from methodB is to change the last line to Thanks, it all works nice. Nearly, that is. The reverse problem is now gone. But the fact that every time I get a ConflictError it doesn't "flush" the 'objects' of methodB, and just seems to append to it, still remains. I only get this when a ConflictError occur. ___ 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 2.3.1b1, strange things when ConflictError.
On Mon, 26 Feb 2001, Erik Enge wrote: I only get this when a ConflictError occur. Nope, it occurs every time I change to another object. I need to do some more testing here. It seems as if the 'objects' variable of 'methodB' is semi-persistent or something. Weired. ___ 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 2.3.1b1, strange things when ConflictError.
The use of a literal anonymous list in methodb's signature for "objects" may have something to do with the results you're getting on conflict. Try assigning "objects" to an empty list in the method body instead. - Original Message - From: "Erik Enge" [EMAIL PROTECTED] To: "Steve Alexander" [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Monday, February 26, 2001 5:46 AM Subject: Re: [Zope-dev] Zope 2.3.1b1, strange things when ConflictError. On Sun, 25 Feb 2001, Steve Alexander wrote: I wasn't reading the code clearly the first time around. By far the simplest place to return copied results from methodB is to change the last line to Thanks, it all works nice. Nearly, that is. The reverse problem is now gone. But the fact that every time I get a ConflictError it doesn't "flush" the 'objects' of methodB, and just seems to append to it, still remains. I only get this when a ConflictError occur. ___ 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 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 2.3.1b1, strange things when ConflictError.
Chris McDonough wrote: The use of a literal anonymous list in methodb's signature for "objects" may have something to do with the results you're getting on conflict. Try assigning "objects" to an empty list in the method body instead. Of course! Yet another demonstration of the dangers of using mutable objects carelessly :-) -- Steve Alexander Software Engineer Cat-Box limited http://www.cat-box.net ___ 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 2.3.1b1, strange things when ConflictError.
Erik Enge wrote: The reverse problem is now gone. But the fact that every time I get a ConflictError it doesn't "flush" the 'objects' of methodB, and just seems to append to it, still remains. I only get this when a ConflictError occur. I don't know exactly why this might happen. I'd need to reproduce the problem, and look through things with a debugger, or instrument the code with print statements or something like that. Perhaps you've found a bug (or feature) in the support for concurrency in Extension Class. You can probably work around the problem, and get faster code into the bargain: rewrite methodB so that it is not recursive. -- Steve Alexander Software Engineer Cat-Box limited http://www.cat-box.net ___ 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 2.3.1b1, strange things when ConflictError.
On Mon, 26 Feb 2001, Steve Alexander wrote: Chris McDonough wrote: The use of a literal anonymous list in methodb's signature for "objects" may have something to do with the results you're getting on conflict. Try assigning "objects" to an empty list in the method body instead. Of course! I'm missing out on something here. Why is this an "of course"? What's a "literal anonymous list"? ___ 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 2.3.1b1, strange things when ConflictError.
Erik Enge wrote:
On Mon, 26 Feb 2001, Steve Alexander wrote:
Chris McDonough wrote:
The use of a literal anonymous list in methodb's signature for "objects" may
have something to do with the results you're getting on conflict. Try
assigning "objects" to an empty list in the method body instead.
Of course!
I'm missing out on something here. Why is this an "of course"? What's a
"literal anonymous list"?
Consider this method:
def methodFoo(self, objects=[]):
# do stuff, including altering the list objects
The list that is assigned to "objects" in the definition of arguments is
only created once. There is only one instance of the list for all the
calls to methodFoo. If you alter that list, then it is altered for the
future too.
Try it in Python from the interactive prompt:
def foo(o=[]):
... o.append('x')
... print o
...
foo()
['x']
foo()
['x', 'x']
foo()
['x', 'x', 'x']
--
Steve Alexander
Software Engineer
Cat-Box limited
___
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 2.3.1b1, strange things when ConflictError.
I have two nice methods. One of them (methodA) is called via the web. These belong to one class; classA. class classA: "doc string" def methodA(self): "doc string" objects = self.methodB(self) objects.reverse() attrib = '' for object in objects: attrib = attrib + 'some html' return attrib def methodB(self, object, skip=[], stop=[], objects=[]): "doc string" try: if object.meta_type in skip: return self.methodB(object.getParentNode(), skip, stop, objects) if object.meta_type in stop: raise AttributeError else: # I don't think I need this. if object not in objects: objects.append(object) else: raise AttributeError return self.methodB(object.getParentNode(), skip, stop, objects) except AttributeError: return objects Narrative story: The user calls methodA (from a instance of classA) through the web. methodA returns some nicely formatted HTML navigation links. methodB should traverse through the objects with getParentNode(), append the object in the list objects (if its meta_type is not listed in 'skip' or 'stop' - which are "skip meta_types" and "stop_meta_types" lists) and return them to methodA for formatting. The objects should be listed in the list that is returned sequentially and methodA would be required to do an objects.reverse() to make sure we are facing the right direction. First of all, this doesn't work very nicely. Every other time I refresh my webpage (ie. call methodA) it seems to reverse() the list returned from methodB on its own. That's strange. This results in: [instance1, instance2] and [instance2, instance1] every other time. *baffled* Now comes the part which really makes me want to go to my hotelroom and watch Life of Brian on BBC at 9.00pm; if I refresh the webpage quickly, and many times (not too quick or too many times; 2-5 times within 2-5 seconds) I get a ConflictError raised in my log - it doesn't take it up to the webpage. There is other stuff going on which causes the ConflictError to get raised (although, I'm only _reading_ from a ZCatalog, as far as I know anyway). Heres what I don't understand. When ever I get a ConflictError, the contents of the 'objects' attribute in methodB isn't "flushed". Thus, resulting in a very long navigation bar with repeating links. Let me repeat that: The attribute 'objects' of the method methodB appears to be persistent. Which it isn't of course. My best guess is that something is wrong with the logic when a ConflictError is raised. It would make kinda sense. Tracebacks, beers or other interesting things offered if needed. :) ___ 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 2.3.1b1, strange things when ConflictError.
Erik, You're returning a mutable object from methodB. You should either return an immutable object (such as a tuple or a string), or return a *copy* of your mutable object. some_list.reverse() reverses the list in-place. That's why you're seeing the strange reversal results you report. The easiest way to achieve this is to change methodA as below: def methodA(self): "doc string" objects = self.methodB(self) objects.reverse() attrib = '' for object in objects: attrib = attrib + 'some html' return attrib def methodA(self): "doc string" objects = self.methodB(self)[:] objects.reverse() Here, you're making a copy of what methodB returns, before doing stuff to it. Otherwise, you can re-reverse what methodB returns using try: finally: in methodA. If methodB is called by anything else, as methodB is recursive, you should either make it non-recursive, or access it via a methodC: def methodC(self, object): return self.methodB(object)[:] -- Steve Alexander Software Engineer Cat-Box limited http://www.cat-box.net ___ 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 2.3.1b1, strange things when ConflictError.
I wasn't reading the code clearly the first time around. By far the simplest place to return copied results from methodB is to change the last line to return objects[:] Erik Enge wrote: def methodB(self, object, skip=[], stop=[], objects=[]): "doc string" try: if object.meta_type in skip: return self.methodB(object.getParentNode(), skip, stop, objects) if object.meta_type in stop: raise AttributeError else: # I don't think I need this. if object not in objects: objects.append(object) else: raise AttributeError return self.methodB(object.getParentNode(), skip, stop, objects) except AttributeError: return objects -- Steve Alexander Software Engineer Cat-Box limited ___ 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 )
