On Mon, Jun 15, 2009 at 12:02 PM, Gustavo Narea<[email protected]> wrote: > > Hi everyone. > > Jorge said: >> >> > Here we go once again... >> >> > >> >> > It's not "how repoze.what works". It's all about how Python works. >> >> > >> >> > In Python, an object can act as a boolean if its __nonzero__/__bool__ >> >> > method is set accordingly. For TG2 users, a horrible error-prone >> >> > monkey-patch has been implemented and enabled by default by popular >> >> > demand: >> >> > http://trac.turbogears.org/ticket/2205 >> >> >> >> I'm sorry but this is circular logic to me. It is a monkey patch >> >> because you decided not to enable it by default, because it's >> >> error-prone (to monkey patch), because someone (I know this predates >> >> r.what) decided the predicates where classes which forced the >> >> __nonzero__ call. It all boils down to the fact that the current >> >> internal state of the system forces ALL of those decisions on us. If >> >> you implement it half way (aka booleanize_predicates) you are creating >> >> several other problems (your error-phone point and the ugly API). >> > >> > As I've said before, the problem is not that __non_zero__ is set >> > dynamically (i.e., monkey-patched). The problem is that __nonzero__ >> > should not be set. >> > >> > From a generic perspective, not specifically about repoze.what: >> > >> > The only safe way to evaluate a condition represented by an object that >> > is shared among threads, is to make this object stateless and evaluate it >> > by passing other objects which represent the context of the evaluation. >> >> I believe you wanted to say the current implementation of non-zero, >> there is nothing wrong with non-zero itself. > > No, I meant __nonzero__, however it's defined, is wrong. [1] > > >> > If you want to skip the step where you pass the context, so you could >> > pass it implicitly to save code (i.e., with thread-locals being the only >> > way to do so, AFAIK), you'll end up with a buggy software: This object >> > won't be stateless anymore, in spite of being used in many threads, which >> > is absolutely unreliable. >> >> how are thread locals buggy? if you simply pass the environ to each >> call won't that fix all your issues with it? make each predicate take >> the environ as first argument and make them functions that return a >> boolean or raises NotAutorizedException. What is the flaw there? > > Noone but you said that thread locals were buggy. And the flaw is in the whole > proposal, because you cannot use functions, as I've told you in another > thread. > you can not use functions if you keep the current
allow_only = foo() but if you transform that into allow_only = autorrize(foo()) or something similar that objection is gone. > Cheers. > > [1] > http://groups.google.com/group/turbogears/browse_thread/thread/f35ef3d347793682 > -- > Gustavo Narea <xri://=Gustavo>. > | Tech blog: =Gustavo/(+blog)/tech ~ About me: =Gustavo/about | > > > > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "TurboGears" 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?hl=en -~----------~----~----~----~------~----~------~--~---
