Re: #25582: Add a way to build URLs with query strings

At Mozilla we've used a jinja2 template filter called 'urlparams' for quite some time. You can see the code in jingo here: https://github.com/jbalogh/jingo/blob/master/jingo/helpers.py#L116 In Python: urlparams(reverse('translate', kwargs={'slug': document.slug}), to_locale=locale) In Jinja2

Re: Python 3.5 Support in Django 1.8.x?

Never mind, just saw that 3.5 is listed in the 1.8 release notes and answered my own question. -- You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group. To unsubscribe from this group and stop receiving emails from

Re: Python 3.5 Support in Django 1.8.x?

Bumping this thread a bit because I subscribe to Debian's tracker for their Django package, and there's some question of whether we do or do not officially support Python 3.5 on Django 1.8. Was there ever a final decision? On Tue, Oct 27, 2015 at 5:19 PM, Ned Batchelder

Re: Non-atomic migrations in Django?

Hi Ludwig, the API looks clean and sensible to me. +1 for getting that into 1.10 /Markus On November 25, 2015 12:00:59 AM GMT+10:00, "Ludwig Hähne" wrote: >Hi all, > >I'd like to get your feedback on supporting non-atomic migrations in >Django. > >Database transactions are

Re: Case-insensitive email as username

On 11/24/2015 04:33 AM, Aymeric Augustin wrote: > 2015-11-23 23:52 GMT+01:00 Carl Meyer >: > > I've implemented the CITEXT-based solution a couple times; I think for a > PostgreSQL-based project it's the preferable option overall. > > Perhaps

Re: Make template caching a feature of the Django template engine

So. If I understand correctly, this would deprecate the existing cached template loader, replace it with a more powerful, debug ready version (on by default?). Assuming this is what you mean, I wholeheartedly support this. There's no reason not to be performant by default. Marc On 23 Nov 2015

Re: Bringing some popular must have django tools/packages under django org umbrella

This is something the core team discussed in Amsterdam. I believe there was consensus to trial it with Django registration. I should catch up with James and see if it is transferred. If this goes well I see no reason why not. The biggest problem is the selection of packages, we have historically

Re: Bringing some popular must have django tools/packages under django org umbrella

The projects will have the official tool status + the maintainer of the projects will be able to collaborate better with django core team? less risk of being abandoned by the maintainers etc. IMHO On Wed, Nov 25, 2015 at 12:31 AM, Collin Anderson wrote: > Hi, > > Say a

Re: Non-atomic migrations in Django?

I also agree this looks sensible - I think South even had an attribute like this on the migration class, it just never got ported over. +1 On Tue, Nov 24, 2015 at 8:19 AM, Marc Tamlyn wrote: > +1 to idea and API. I've wished I had this recently - even if it's just so > I

Re: Bringing some popular must have django tools/packages under django org umbrella

Hi, Say a little bit more: What would be the goal? What would you hope would be accomplished by doing this? Thanks, Collin On Tuesday, November 24, 2015 at 1:27:11 PM UTC-5, Asif Saifuddin wrote: > > How is the idea? tools like django-debug-toolbar, django-silk, > django-taggit, django-filter

Bringing some popular must have django tools/packages under django org umbrella

How is the idea? tools like django-debug-toolbar, django-silk, django-taggit, django-filter etc and some more de facto tools under the umbrella of django github org? Regards -- You received this message because you are subscribed to the Google Groups "Django developers (Contributions to

[ANNOUNCE] Django security releases issued (1.7.11, 1.8.7, and 1.9rc2)

Today the Django team issued multiple releases -- Django 1.7.11, 1.8.7, and 1.9rc2 -- as part of our security process. These releases address a security issue, and we encourage all users to upgrade as soon as possible. More details can be found on our blog:

Re: Case-insensitive email as username

We usually just handle this with a custom serializer (or form) field that converts all input to lowercase. That way we don't have to change any lookups or anything; all emails that come in to the system are already lowercase. Of course, that doesn't preserve what users enter but IME anything

Re: Non-atomic migrations in Django?

+1 to idea and API. I've wished I had this recently - even if it's just so I can check up on the progress of a slow running data generation migration so it flushes the data every few 100 records. On 24 November 2015 at 16:07, Aymeric Augustin < aymeric.augus...@polytechnique.org> wrote: > I like

Re: Non-atomic migrations in Django?

I like the API as well. Surprisingly, I couldn't find a Trac ticket about this. -- Aymeric. 2015-11-24 16:39 GMT+01:00 Anssi Kääriäinen : > I don't see any problem with optional non-transactional migrations. So, +1 > for the idea and API. I haven't looked at the

Re: Non-atomic migrations in Django?

I don't see any problem with optional non-transactional migrations. So, +1 for the idea and API. I haven't looked at the implementation, so no comments about that. - Anssi On Tuesday, November 24, 2015, Ludwig Hähne wrote: > Hi all, > > I'd like to get your feedback on

Non-atomic migrations in Django?

Hi all, I'd like to get your feedback on supporting non-atomic migrations in Django. Database transactions are always wrapped in transactions (on DBs that support transactional DDL like Postgres). Generally this is a good idea. However, one can't do batched updates in data migrations which is

Re: Case-insensitive email as username

2015-11-23 23:52 GMT+01:00 Carl Meyer : I've implemented the CITEXT-based solution a couple times; I think for a > PostgreSQL-based project it's the preferable option overall. > Perhaps we should add native support in contrib.postgres? I'm forseeing a small difficulty in terms