On 12/07/2004, at 12:29 PM, Chris McDonough wrote:
FWIW, as far as I understand the "prevent commit on conflict" behavior
*is* currently the behavior for caught ReadConflictErrors. The only
time ZODB doesn't exhibit this behavior is *during the commit of a
transaction*. If a commit is attempted a
Tim Peters wrote at 2004-7-10 17:55 -0400:
> ...
>Which is why the current ZODB releases intend to prevent committing a
>transaction if a conflict error occurred during the transaction. It
>shouldn't matter to this ZODB machinery if the application suppressed
>the original conflict error(s), ZODB
Shane Hathaway wrote at 2004-7-10 02:41 -0600:
> ...
>Hmm. I just heard about this "hasattr geddon". hasattr is *good*. Why are
>we fixing hasattr and bare excepts when the real problem is ZODB?
That's even better!
However, we may still be interested to get an exception unswallowed
by "hasatt
FWIW, as far as I understand the "prevent commit on conflict" behavior
*is* currently the behavior for caught ReadConflictErrors. The only
time ZODB doesn't exhibit this behavior is *during the commit of a
transaction*. If a commit is attempted at this point and a conflict
error is caught uninten
On Saturday 10 July 2004 20:54 pm, Casey Duncan wrote:
> Shane Hathaway <[EMAIL PROTECTED]> wrote:
> > Why are
> > we fixing hasattr and bare excepts when the real problem is ZODB?
>
> Well, the real problem is *probably* people, but I digress...
http://c2.com/cgi/wiki?TheProcessIsTheProblem ;-)
On Saturday 10 July 2004 15:55 pm, Tim Peters wrote:
> [Shane Hathaway]
>
> > Here is what often happens in Zope:
> >
> > def setFoo(self, value):
> > try:
> >self.foo = value
> > except:
> >LOG("Oops", ERROR, "Some error happened", error=sys.exc_info())
> > self.change_count += 1
> > s
[Shane Hathaway]
> Here is what often happens in Zope:
>
> def setFoo(self, value):
> try:
>self.foo = value
> except:
>LOG("Oops", ERROR, "Some error happened", error=sys.exc_info())
> self.change_count += 1
> self.get_indexes().update(self)
>
> Some piece of code has a legitimate reas
On Saturday 10 July 2004 11:41 am, Tim Peters wrote:
> [Shane Hathaway]
> > when the real problem is ZODB? ZODB
> > should *not* be sensitive to the way the application handles
> > ConflictErrors. When a ConflictError (or ReadConflictError) occurs, the
> > transaction should fall into an "uncommit
[Shane Hathaway]
> Hmm. I just heard about this "hasattr geddon". hasattr is *good*. Why are
> we fixing hasattr and bare excepts
Well, bare excepts are generally bad news in any application -- they
almost always turn out to catch more than the author intended
(including things like SystemExit
Shane Hathaway wrote:
On Friday 09 July 2004 11:50 am, Casey Duncan wrote:
On Fri, 9 Jul 2004 16:22:17 +0200
Dieter Maurer <[EMAIL PROTECTED]> wrote:
[..]
The "hasattr" replacement in Python's "__builtin__" could look like:
_marker = []
def hasattr(obj, attr):
return getattr(obj, att
On Friday 09 July 2004 11:50 am, Casey Duncan wrote:
> On Fri, 9 Jul 2004 16:22:17 +0200
> Dieter Maurer <[EMAIL PROTECTED]> wrote:
> [..]
>
> > The "hasattr" replacement in Python's "__builtin__" could look like:
> >
> > _marker = []
> > def hasattr(obj, attr):
> > return getattr(obj,
11 matches
Mail list logo
