"Kevin Dangoor" <[EMAIL PROTECTED]> writes: > Hmm... Which platform are you on? Are there any reproduceable steps or > a minimal project you can send me that shows the problem? On my Mac, I > don't see any kind of locking up like that.
Linux. I'm checking all of my code for this, and I haven't changed nothing for a while. The problem is that I wasn't touching this part for a while and it stopped first on the production machine and when I went testing it here it failed as well. About a reproducible example, if I can't solve it I'll try writing one. It should be just a form anyway (it has fieldsets, though...). I've tried printing "kw"'s keys and I see all keys correctly defined, the form passes through TG's validators, there's no tg_errors, no nothing. It all looks fine from TG's side. I just don't know where to look for it. From the traceback it is something related to SQLObject... I've also tried downgrading SQLObject, but it didn't solve the problem and then I went back to HEAD. > So the question becomes, how did a dictionary get in as one of the > parameters? I would've assumed that this filter would run before any of our > decorator code. Me too... And I'm trying to track it down. The only dict that is being passed is a "datetime.datetime", but if I pass something different than that I get an error from SQLObject saying that it expected a datetime (either mx.DateTime ou datetime.datetime) object and instead got a str... -- Jorge Godoy <[EMAIL PROTECTED]> --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "TurboGears Trunk" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/turbogears-trunk -~----------~----~----~----~------~----~------~--~---
