Re: Django 1.5.1 released
Hi Josh, In short, no - Twitter isn't a particularly reliable source for updates. Someone in the core team will usually tweet about the release, but since it's hard to share logins to a single Twitter account, and the person who owns Django's twitter account won't always be involved in formally cutting the release, we sometimes drop the ball. Our official channels are the django-announce mailing list, and Django's blog. If you're looking for guaranteed notification, those two channels are guaranteed to receive notification. Yours Russ Magee %-) On Wed, Apr 3, 2013 at 12:10 AM, Josh Cartmell wrote: > Thanks for the release! > > Kind of random question, but this seems like the best place to ask > it. I used to use Twitter mobile notifications to keep up with Django > releases, but I've noticed that the last three releases (since 1.4.4) > have not been announced on Django's Twitter. Is this just an over- > site, or is Twitter no longer a good place to keep up with Django > releases. > > Thanks, > Josh > > On Mar 28, 2:02 pm, Jacob Kaplan-Moss wrote: > > Hi folks -- > > > > We've just released Django 1.5.1, a bug fix release that cleans up a > > couple issues with last month's 1.5 release. > > > > The biggest fix is for a memory leak introduced in Django 1.5. Under > > certain circumstances, repeated iteration over querysets could leak > > memory - sometimes quite a bit of it. > > > > For more details, see our announcement: > > > >https://www.djangoproject.com/weblog/2013/mar/28/django-151/ > > > > Thanks for using Django! > > > > Jacob > > -- > You received this message because you are subscribed to the Google Groups > "Django developers" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to django-developers+unsubscr...@googlegroups.com. > To post to this group, send email to django-developers@googlegroups.com. > Visit this group at http://groups.google.com/group/django-developers?hl=en > . > For more options, visit https://groups.google.com/groups/opt_out. > > > -- You received this message because you are subscribed to the Google Groups "Django developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-developers+unsubscr...@googlegroups.com. To post to this group, send email to django-developers@googlegroups.com. Visit this group at http://groups.google.com/group/django-developers?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
Re: Django 1.5 using a cached HttpResponse with WSGI has an empty body
On 25 mars 2013, at 18:02, SteveB wrote:
> I suspect this is a bug. Any thoughts?
Yes, it's annoying, all the more since Django exposes response.content as an
attribute.
> This works, but makes my code dependent on the internals of the HttpResponse
> class, which isn't great. Any better ideas?
I assume you're pickling the response to cache it. We could define a
__getstate__ method to remove _iterator from what's pickled, like this:
def __getstate__(self):
state = self.__dict__.copy()
state.pop('_iterator', None)
return state
Could you file a ticket so we don't lose track of this problem?
--
Aymeric.
--
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.
Re: URL dispatcher fallthrough?
On Tue, Apr 2, 2013 at 4:49 AM, David Danier wrote: > This is somethign that does not need to be inside Django core. So why > not just start an thirt party app implementing the proposal? I did just that: https://pypi.python.org/pypi/django-multiurl. Turns out it takes a fair bit of spelunking inside the guts of the urlresolver, but ends up being a fairly short bit of code. Give it a shot, let me know if it works for your usecase(s). Jacob -- You received this message because you are subscribed to the Google Groups "Django developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-developers+unsubscr...@googlegroups.com. To post to this group, send email to django-developers@googlegroups.com. Visit this group at http://groups.google.com/group/django-developers?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
Re: unittest2 discovery proposal
Hi Shai, The discover runner does discovery based on pattern. So, if your tests are named, test_*.py, they would by be discovered by default. Test discovery is recursive, under the root, so it doesn't matter if you have tests in a tests directory. The __init__.py imports would be redundant, and actually ignored by the discover process. If your test files don't match the default pattern of "test*.py", then you have three options: 1) Rename the test files 2) Invoke the test command with a custom pattern 3) Specify a custom load_tests in the __init__.py file that tells discovery what to do. Preston On Apr 1, 2:28 pm, Shai Berger wrote: > Hi, > > +1 in general. One concern, and one idea: > > > -- Backwards-incompatible changes -- > > > * Some valid test structures in Django don't work with unittest2. For > > instance, tests in `tests/__init__.py` don't match a patter than > > unittest would recognize if running discovery on a module. > > I have a complex app with many tests; so many, that we felt the need to break > the tests module into modules in a package. So we have > tests/test_frobnication.py > tests/test_grobulation.py > etc., and > tests/__init__.py > which imports them all. > > It isn't quite clear to me how this applies to such a structure; it seems like > I would need a special pattern, "tests.test_*.py" or some such. This, in turn, > raises an idea: an app should be able to specify the discovery parameters for > its own tests in the source, not just on the command line. > > Just to be clear: In view of backwards-compatibility concerns, I don't think > the load_tests protocol supported by unittest2 is enough for this. It should > be much simpler, IMO; something like (pseudo code): > > try: > from app import tests > if hasattr(tests, 'root'): > set_discovery_root(tests.root) > if hasattr(tests, 'pattern'): > set_discovery_pattern(tests.pattern) > except ImportError: > pass > > This way, my case is handled simply by adding these lines into > tests/__init__.py: > > root=app.tests > > Thanks, > Shai. -- You received this message because you are subscribed to the Google Groups "Django developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-developers+unsubscr...@googlegroups.com. To post to this group, send email to django-developers@googlegroups.com. Visit this group at http://groups.google.com/group/django-developers?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
Re: Django 1.5.1 released
Thanks for the release! Kind of random question, but this seems like the best place to ask it. I used to use Twitter mobile notifications to keep up with Django releases, but I've noticed that the last three releases (since 1.4.4) have not been announced on Django's Twitter. Is this just an over- site, or is Twitter no longer a good place to keep up with Django releases. Thanks, Josh On Mar 28, 2:02 pm, Jacob Kaplan-Moss wrote: > Hi folks -- > > We've just released Django 1.5.1, a bug fix release that cleans up a > couple issues with last month's 1.5 release. > > The biggest fix is for a memory leak introduced in Django 1.5. Under > certain circumstances, repeated iteration over querysets could leak > memory - sometimes quite a bit of it. > > For more details, see our announcement: > > https://www.djangoproject.com/weblog/2013/mar/28/django-151/ > > Thanks for using Django! > > Jacob -- You received this message because you are subscribed to the Google Groups "Django developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-developers+unsubscr...@googlegroups.com. To post to this group, send email to django-developers@googlegroups.com. Visit this group at http://groups.google.com/group/django-developers?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
Re: URL dispatcher fallthrough?
> David: The slugs wouldn't be overlapping if they inherited from some > sort of "Organization" model with unique slug. The user could also add > validation code to prevent company and schools having same slugs. If you have a common base model this sounds like some polymorphic model problem, which does not need to be solved in the URLs (and probably should not). There are existing third party solutions, which may help you get the right model back, when fetching one "Organization". An user validation is only useful if you put the logic into an unrelated app, as my proposed alias app. Otherwise you will need to mix your models, at least when doing validation. This may not follow the loose coupling philosophy (https://docs.djangoproject.com/en/dev/misc/design-philosophies/) of Django. If you have this app the name resolution can be done without doing fallbacks anywhere in your code. Anyways, about your proposal: This is somethign that does not need to be inside Django core. So why not just start an thirt party app implementing the proposal? David -- You received this message because you are subscribed to the Google Groups "Django developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-developers+unsubscr...@googlegroups.com. To post to this group, send email to django-developers@googlegroups.com. Visit this group at http://groups.google.com/group/django-developers?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
