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. 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 -~----------~----~----~----~------~----~------~--~---
