I found another bug. Counter.get_count tests whether self.memcached.count is None, however self.memcached.count will never return None.
On Nov 2, 1:11 am, Bill <[EMAIL PROTECTED]> wrote: > > As I see it, any code that uses your new counter object will need to > > deal with instantiating it somewhere > ... > > others might have a > > similar question when wondering how best to actually implement it and > > ensure the variable name they wish to use for the counter is not > > taken, and that they're not unnecessarily instantiating multiple > > Counter objects for no reason. > > The way I'm using counters, they are hardwired into the code right at > the time counter info is needed to be retrieved or set. I do the > instantiation right at that point. For my app, I guarantee variable > names are OK just via code review and making each group of counters > has a special prefix name so there can't be conflict across groups of > counters. > > I'm still relatively new to python web apps, so I can use educating > here as well, but my understanding was a request created a limited > lifecycle for the request handler and instantiated models, unless you > put it in the global space. So if you really want to be efficient, > you could create the counters globally so they are kept across > requests some times. But even if you are dynamically creating > multiple instances of Counter objects, there shouldn't be much of a > performance penalty or access issue because these objects are so > lightweight and the very nature of a web app where the whole response > gets recreated each request. > > Best, > Bill --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Google App Engine" group. To post to this group, send email to google-appengine@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/google-appengine?hl=en -~----------~----~----~----~------~----~------~--~---
