Re: Dropping Python 2.3 compatibility for Django 1.1
+1 to Malcolm and Julien. Having a clear roadmap before you make changes is really helpful. I've been bitten by changes appearing in code suddenly because I've tuned out for a few weeks. There is always the option of sticking to an earlier revision, but that doesn't help for long. I also agree it's worth getting a feel for the need for 2.3. I'm sure there's quite a few RHEL <5 boxes out there for example. Ned's suggestion is a cunning one, but a Q on the user list might be a useful first move. Ben On Nov 26, 1:20 am, Julien Phalip <[EMAIL PROTECTED]> wrote: > On Nov 26, 11:43 am, "Russell Keith-Magee" <[EMAIL PROTECTED]> > wrote: > > > > > On Wed, Nov 26, 2008 at 2:08 AM, Jacob Kaplan-Moss > > > <[EMAIL PROTECTED]> wrote: > > > > Hi folks -- > > > > I'd like to officially drop Python 2.3 support in Django 1.1. Discuss. > > > I'm going to be the stick in the mud and say -0. > > > I don't have any particular love of or need for Python 2.3, but it has > > taken us a lot of effort to get and maintain Python 2.3 compatibility. > > I know maintaining this support is a pain, but in the grand scheme of > > things it doesn't bite us that often. > > > I know the GIS stuff is bound to 2.4+, but other than this, is there > > any particularly compelling reason to drop 2.3 support other than the > > annoyance factor for 1.1? I'm just not convinced that the first minor > > release after a major 1.0 release is the right time to do it. > > > Russ %-) > > Maybe the best approach would be to warn people one or two releases in > advance. For example: "Python 2.3 support will be dropped in Django > 1.3, so be warned and get ready for it." --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Problems with concurrent DB access and get_or_create()
Hi, I'm using rev 7713 (I need to port to the new upload handling before I can get back to trunk). The code that actually adds to the table: def do_update(self, event): if event.countable: matrix, new = self.get_or_create(date=event.time.date(), member=event.target, shop=event.shop, product=event.product) matrix.increment_column(event.type) matrix.save() Ben On Jul 16, 3:28 pm, "[EMAIL PROTECTED]" <[EMAIL PROTECTED]> wrote: > What version are you running, and what's the exact line you're using > for get_or_create? --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Problems with concurrent DB access and get_or_create()
I'm experiencing the issue with concurrent writes on a low traffic site hosted on a single machine DB and web server. I'm logging reporting events in certain views and everytime I get indexed by a search engine, this error floods into my inbox. If I implement the workaround of hiding the multiple-rows-returned exception, I will end up with multiple rows containing my data instead of one. Until aggregates support comes around this means I would have to sum() the rows with some custom SQL. I suppose I could hide duplicates found by get_or_create and write a script to periodically tidy up duplicates into a single row. That seems rather a hack though. Regarding the prior conversation from December. I think it's important that this "just works," or there is at least a note warning about this possibility in the get_or_create docs. Otherwise the same thing that happened to me will happen to others. They'll build their software merrily and think it's working until one day traffic hits the level at which this problem occurs, then they have to modify code. Ben --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Session unpickle exceptions silenced
I just spent a day unpicking a bug that manifested as a disappearing session. It wasn't uniform so it was hard to recreate. It turned out objects that I was placing in the session were not unpickling successfully. It was very hard to trace this to the Session.get_decoded method and it felt like a bit of a slap to find all pickle.loads exceptions being dropped silently. Is this really the best thing to do? Surely it would be better to raise the exception so that the programmer can see it? Once I laid hands on the exception text, it took me 30 seconds to fix my mistake. Ben http://aftnn.org http://cambodiachallenge.org --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
