Class based views: A standard hook for http-method-independent code

[Marc Tamlyn]

Hi all,

Apologies if this has been raised before. I've had a look around and can't 
find a good way of doing this with the current code.

I regularly have views which rely on some custom code which runs some 
sanity checking on the request and is independent of method. As an example, 
consider a view which creates an object related to a parent. This is easily 
achievable by overriding the form_valid method of CreateView and excluding 
the foreign key from the form. However, the view should return a 404 if the 
related object specified by the url does not exist. Written as a non class 
based view, the natural flow is to try to load the parent object from the 
database, handle it as necessary, and then split paths depending on whether 
we have a get or post. It is currently very difficult to emulate this 
without duplication of some sort.

My proposal is that we add a process_request (or similar name) method which 
is called by the dispatch method immediately before the method handler is 
called. (i.e. 
here<https://github.com/django/django/blob/master/django/views/generic/base.py#L68>).
 
This would then allow pre-processing and sanity checking of the request 
object, using the args, kwargs and request that have been saved on the 
class, before delegating off the the respective views. The method should 
return None or an HttpResponse subclass. If it returns something, then we 
return that directly from the dispatch method.


I can supply some code (my proposal is pretty simple I think) but I thought 
I'd open it up for discussion first.

Marc Tamlyn

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To view this discussion on the web visit 
https://groups.google.com/d/msg/django-developers/-/3gP1cLOL9usJ.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: Django's CVB - Roadmap?

[Marc Tamlyn]

There is a plan to do some work on the docs at the djangocon sprints - in 
particular trying to get some examples of when you 'could' and when you 
'should not' use the generic CBVs.

With regards to Zach's point about TDD testing - some of that may simply be 
familiarity. I don't know about you but it would have been very difficult 
for me to get into successfully TDDing a functional view until I'd written 
several dozen views and knew what the pattern is. You can still test the 
CBV top to bottom, exactly as you would with a function based view. Yes 
there may be some shift to conventions, but that will come with familiarity.

I think part of the important difference is that when you look at a CBV for 
the purposes of unit testing it, you feel very quickly that you should be 
testing the individual methods. This is actually really nice and gives a 
lot more branch-coverage without rerunning the same 4 database queries 
every time for variables which aren't used. Without CBVs a complex view can 
easily extend over 50 or so lines, whereas it's more natural to split this 
up and test the sections independently with a Class based system. I know in 
general we should be 'writing less view code' and pushing the logic 
elsewhere, but that depends on what that logic is - for example the view 
layer needs to decide whether to return JSON or HTML depending on certain 
headers in the request, and that is more easily testable as an overridden 
render to response method than as the last 4 lines of a 50 line view.

Marc

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To view this discussion on the web visit 
https://groups.google.com/d/msg/django-developers/-/VZsGxxTYyoIJ.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: Draft branch: Swappable User models in contrib.auth

[Marc Tamlyn]

I believe changes to auth (and several other things) are waiting for 
contrib.migrations. It will be some time...

On Sunday, 19 August 2012 03:02:51 UTC+1, Victor Hooi wrote:
>
> Hi,
>
> I'm just wondering, has there been any updates on the User model refactor?
>
> My understanding is that this is the official way of handling Users going 
> forward.
>
> Is there any roadmap on when it might hit trunk? I didn't see any 
> reference to User models in the 1.5 release notes.
> Cheers,
> Victor
>
> On Wednesday, 6 June 2012 21:34:42 UTC+10, Andrew Ingram wrote:
>>
>> On 4 June 2012 16:12, Russell Keith-Magee  
>> wrote: 
>> >  * The swapping mechanic is set up using a new Meta option on models 
>> > called 'swappable' that defines the setting where an alternate model 
>> > can be defined. Technically, the swappable option *could* be used for 
>> > any model; however, I'm not proposing that we actually document this. 
>> > I've implemented it as a generic approach purely to make the internals 
>> > cleaner -- mostly to avoid needing to make references to auth.User in 
>> > the model syncdb code, and to make testing possible (i.e., we can do 
>> > validation tests on a dummy 'swappable' model, rather than trying to 
>> > munge a validation test for auth.User specifically). 
>>
>> I like the idea of a 'swappable' option, but I can see some potential 
>> issues with the implementation. I'm one of the developers of Oscar 
>> (https://github.com/tangentlabs/django-oscar/) and providing a clean 
>> method to for overriding models has been a major pain point. One of 
>> our key requirements is that any model in Oscar may be overridden, to 
>> that end every model has both abstract and concrete versions (much 
>> like your implementation of AbstractBaseUser and User). 
>>
>> Our current way of handling overrides is for every reference to a 
>> model in Oscar to use get_model rather than the explicit classname. 
>> But this does end up causing some ugly things like this: 
>>
>> from oscar.apps.catalogue.abstract_models import AbstractProduct 
>>
>> class Product(AbstractProduct): 
>> # stuff 
>>
>> from oscar.apps.catalogue.models import * 
>>
>>
>> Issues: 
>> 1) The override model HAS to have the same name as the default model, 
>> otherwise get_model('catalogue', 'Product') won't work. 
>> 2) We have to import all the remaining default models after we declare 
>> our overrides. But this only works because Django's model metaclass 
>> prevents the default Product replacing the one we've just defined. I 
>> don't like this because it's a little bit magic. 
>> 3) You have to remove Oscar's version of the app from INSTALLED_APPS 
>> and replace it with your own. Actually, technically you don't. If you 
>> leave Oscar's app installed but put your own one ('foo.catalogue') in 
>> front of it, you can even get rid of the nasty import * thing - but 
>> again, more magic. (Aside: you can actually use this approach already 
>> to override Django's User model, because the metaclass means any 
>> references to Django's User will be replaced with references to your 
>> own. ) 
>>
>> I had investigated using a class decorator to handle overrides: 
>>
>> @replace_model('catalogue.Product') 
>> class MyProduct(AbstractProduct): 
>> # foo 
>>
>> But this got seriously complicated because the metaclass modifies the 
>> class before the decorator can be applied, so I was looking into ways 
>> to sever all the ties with the app cache before I went insane and gave 
>> up. 
>>
>> Back to my main points... Your swappable option would solve quite a 
>> lot, in the case of the User model it's ideal. But I'm concerned that 
>> if people start using it more widely we'd end up having dozens of new 
>> settings that would get quite silly in the case of a large project 
>> like Oscar. I think it's important that overrides can be defined in 
>> the settings file, but I'd also like to see it possible at model 
>> definition time, either using a decorator (like above) or a Meta 
>> option like 'replaces'. The risk, of course, is that it means any 
>> third-party app could override any other model without you necessarily 
>> being aware of it, not sure how this would be mitigated. 
>>
>> If I've not made much sense let me know, I've always found it hard to 
>> articulate on this particular topic. 
>>
>>
>> Regards, 
>> Andrew Ingram 
>>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To view this discussion on the web visit 
https://groups.google.com/d/msg/django-developers/-/VkctqktqAxMJ.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: django 1.5 incompatibility at TemplateView

[Marc Tamlyn]

Hi Bernado,

Template view passing params into the context rather than just passing the 
kwargs from the urlconf directly is actally somewhat older, and is kept as 
legacy from django.views.generic.simple.direct_to_template. The changes you 
refer to do actually introduce a subtle backwards incompatibility with 
TemplateView - but yesterday we made a new commit[1], fixing the *real* 
problem, which is that the params variable was inconsistent with how the 
rest of the CBVs worked. This actually introduces a slightly different 
backwards incompatibility, which is that the params variable no longer 
exists. This has been documented in the release notes.

There is perhaps a case for removing this passing of urlconf kwargs to the 
context all together, as it seems a little odd to me and only applies to 
TemplateView, but for the moment it's at least been made a bit more 
consistent with how other CBVs work.

Marc

[1] 
https://github.com/django/django/commit/f04bb6d798b07aa5e7c1d99d700fa6ddc7d39e62

On Saturday, 18 August 2012 08:21:28 UTC+1, Bernardo wrote:
>
> Hi, I was trying my project on django 1.5 alpha and a change on 
> TemplateViews made some code break. 
> The `get` method changed how `get_context_data` is called from (**kwargs)to 
> (params=kwargs). Link: 
> https://github.com/django/django/blob/master/django/views/generic/base.py
>
> I traced the change and found a ticket saying the TemplateView could not 
> be used with FormView because the get_context_data is in a different 
> layout. Ticket: https://code.djangoproject.com/ticket/16074
>
> I don't know how popular are classed based views among other django 
> developers, but I only use them. So, this change could be added in the 
> release notes to warn people about breaking some code.
> For me, I had the habit of writing:
>
> With e.g. this url:   url(r'^ref/(?P\d+?)/?$', 
> views.ref.Show.as_view())
>
> def get_context_data(self, id, **kw):
> pass #do something with id
>
> Now, the only way I find to keep the code compatible with both 1.4 and 1.5 
> is doing:
>
> def get_context_data(self, **kw):
> id = kw.get('params', kw)['id']
>
> which is just a little bit more code but could crash in django 1.4 if 
> somehow there's a "params" argument
>
> Could this be avoided?
>
> Thanks,
> Bernardo
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To view this discussion on the web visit 
https://groups.google.com/d/msg/django-developers/-/M48ifovMmXwJ.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: django 1.5 incompatibility at TemplateView

[Marc Tamlyn]

Correct :)

On Sunday, 19 August 2012 20:44:11 UTC+1, Bernardo wrote:
>
> So as long as I don't use the `params` thing (which I don't) there will be 
> no problem with my views? 
> Reading this and the other commit done at the same time, looks like the 
> function calls behave the way I expect :)
>
> Bernardo
>
> Em domingo, 19 de agosto de 2012 06h44min03s UTC-3, Marc Tamlyn escreveu:
>>
>> Hi Bernado,
>>
>> Template view passing params into the context rather than just passing 
>> the kwargs from the urlconf directly is actally somewhat older, and is kept 
>> as legacy from django.views.generic.simple.direct_to_template. The changes 
>> you refer to do actually introduce a subtle backwards incompatibility with 
>> TemplateView - but yesterday we made a new commit[1], fixing the *real* 
>> problem, which is that the params variable was inconsistent with how the 
>> rest of the CBVs worked. This actually introduces a slightly different 
>> backwards incompatibility, which is that the params variable no longer 
>> exists. This has been documented in the release notes.
>>
>> There is perhaps a case for removing this passing of urlconf kwargs to 
>> the context all together, as it seems a little odd to me and only applies 
>> to TemplateView, but for the moment it's at least been made a bit more 
>> consistent with how other CBVs work.
>>
>> Marc
>>
>> [1] 
>> https://github.com/django/django/commit/f04bb6d798b07aa5e7c1d99d700fa6ddc7d39e62
>>
>> On Saturday, 18 August 2012 08:21:28 UTC+1, Bernardo wrote:
>>>
>>> Hi, I was trying my project on django 1.5 alpha and a change on 
>>> TemplateViews made some code break. 
>>> The `get` method changed how `get_context_data` is called from 
>>> (**kwargs) to (params=kwargs). Link: 
>>> https://github.com/django/django/blob/master/django/views/generic/base.py
>>>
>>> I traced the change and found a ticket saying the TemplateView could not 
>>> be used with FormView because the get_context_data is in a different 
>>> layout. Ticket: https://code.djangoproject.com/ticket/16074
>>>
>>> I don't know how popular are classed based views among other django 
>>> developers, but I only use them. So, this change could be added in the 
>>> release notes to warn people about breaking some code.
>>> For me, I had the habit of writing:
>>>
>>> With e.g. this url:   url(r'^ref/(?P\d+?)/?$', 
>>> views.ref.Show.as_view())
>>>
>>> def get_context_data(self, id, **kw):
>>> pass #do something with id
>>>
>>> Now, the only way I find to keep the code compatible with both 1.4 and 
>>> 1.5 is doing:
>>>
>>> def get_context_data(self, **kw):
>>> id = kw.get('params', kw)['id']
>>>
>>> which is just a little bit more code but could crash in django 1.4 if 
>>> somehow there's a "params" argument
>>>
>>> Could this be avoided?
>>>
>>> Thanks,
>>> Bernardo
>>>
>>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To view this discussion on the web visit 
https://groups.google.com/d/msg/django-developers/-/wDgBjSVJVtcJ.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: Draft branch: Swappable User models in contrib.auth

[Marc Tamlyn]

Ah, thanks Russ, I'd missed the final resolution to that.

M

On Monday, 20 August 2012 00:12:18 UTC+1, Russell Keith-Magee wrote:
>
> On Sun, Aug 19, 2012 at 5:23 PM, Marc Tamlyn 
> > 
> wrote: 
> > I believe changes to auth (and several other things) are waiting for 
> > contrib.migrations. It will be some time... 
>
> Incorrect. The strategy that was approved for trunk won't require 
> migrations unless you want to change an existing project, which means 
> it will be entirely opt-in. There was an extensive django-dev 
> discussion about 6 months ago about this; the redux is on the wiki: 
>
> https://code.djangoproject.com/wiki/ContribAuthImprovements 
>
> Yours, 
> Russ Magee %-) 
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To view this discussion on the web visit 
https://groups.google.com/d/msg/django-developers/-/YRjWXtBIuD0J.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Possible deprecation of depth= in select_related

[Marc Tamlyn]

Hi all,

The issue #16855 [1] tracks some unexpected behaviour in the chaining of 
`Queryset.select_related`. It's been proving rather complex to get a patch 
for this which works, mainly because of the complexity added by the depth 
argument. It has been proposed (by Luke Plant) that depth be deprecated 
(and +1d by several other users and a core dev). With this in mind, I 
propose that we put the kwarg on the deprecation path adding the warning in 
1.5 (so the bug can eventually be fixed in 1.7). As it changes no 
functionality in this release, I don't see any reason to hold this for 1.6 
(and thereby delay the fix until 1.8).

If anyone has any major objections to the deprecation of depth, you should 
shout now. If there are no objections and people think it's ok to push this 
deprecation in now, then I'll get a patch done on Monday.

Thanks,
Marc


[1] https://code.djangoproject.com/ticket/16855

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To view this discussion on the web visit 
https://groups.google.com/d/msg/django-developers/-/bC-65slJ8gwJ.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: Possible deprecation of depth= in select_related

[Marc Tamlyn]

It seems there had been a little confusion as to exactly what the initial 
proposal was. I had assumed it was just about removing the `depth` argument 
but it was still possible to pass *no* arguments to get the implicit 
"follow everything" behaviour. In fact Luke was suggesting that we remove 
this behaviour as well, requiring the user to pass in some field names. 
This has various knock on effects within Django (mostly in the admin), but 
they're not particularly difficult to fix. My concern is that I've seen 
"blank" select related calls quite often in the wild (although never seen 
depth=), so it may break a few more things. Then again, blank select 
related calls are pretty risky, and although it's not documented are 
actually equivalent to `depth=5`. I'm not really against deprecating this 
but I thought it should be made clear exactly what the deprecation was (and 
we should get this sorted out for 1.5).

Marc

On Saturday, 3 November 2012 01:19:59 UTC, Russell Keith-Magee wrote:
>
>
> On Fri, Nov 2, 2012 at 10:33 PM, Jacob Kaplan-Moss 
> 
> > wrote:
>
>> On Fri, Nov 2, 2012 at 9:29 AM, Marc Tamlyn 
>> > 
>> wrote:
>> > If anyone has any major objections to the deprecation of depth, you 
>> should
>> > shout now. If there are no objections and people think it's ok to push 
>> this
>> > deprecation in now, then I'll get a patch done on Monday.
>>
>> No objections here. Depth was a simple protection we added before we
>> got select_related(*fields); the *fields form is a ton more useful. +1
>> on deprecating depth.
>>
>>  
> Sounds good to me too. +1.
>
> Russ %-)
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To view this discussion on the web visit 
https://groups.google.com/d/msg/django-developers/-/k-6EK0iI_8AJ.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: Could prefetch_related be modified to utilize select_related for ForeignKey relations?

[Marc Tamlyn]

A better way of achieving this functionality would be the API proposed 
in https://code.djangoproject.com/ticket/17001

Marc

On Wednesday, 6 February 2013 00:29:15 UTC, Michal Novotný wrote:
>
> Hey, what about this 
> one: qs.prefetch_related('best_pizza__toppings__topping_type_*')
>
> It is intuitive and simple. But of course, that would mean to add wildcard 
> support everywhere.
>
> On Sunday, February 19, 2012 11:18:20 PM UTC+1, Yo-Yo Ma wrote:
>>
>> Speaking with regards to the ORM method documented at 
>>
>> https://docs.djangoproject.com/en/dev/ref/models/querysets/#prefetch-related 
>>
>> Of course, ``prefetch_related`` uses a Pythonic join to attach reverse- 
>> related objects and avoids the N+1 queries problem, which of course is 
>> great. However, if you use it like this: 
>>
>> >>> 
>> Restaurant.objects.prefetch_related('best_pizza__toppings__topping_type') 
>>
>> It doesn't seem to take advantage ``select_related`` (assuming that 
>> ``topping_type`` is a ``ForeignKey`` from ``Topping``. It instead 
>> sends a separate query for ``Topping`` and ``ToppingType``, joining 
>> them in Python. Is it feasible to modify ``prefetch_related`` use 
>> ``select_related`` when it encounters a ``ForeignKey``?
>
>

-- 
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: Database pooling vs. persistent connections

[Marc Tamlyn]

+1 to django-postgrespool it works well for me.

On Sunday, 17 February 2013 22:17:09 UTC, Carl Meyer wrote:
>
> On 02/17/2013 11:31 AM, Anssi Kääriäinen wrote: 
> > It seems SQLAlchemy has a mature pooling implementation. So, yet 
> > another approach is to see if SQLAlchemy's pooling implementation 
> > could be reused. (Maybe in conjunction with the above 'POOLER' idea). 
>
> There is in fact an implementation of reusing SQLAlchemy's connection 
> pool with Django (via DatabaseWrapper subclassing): 
> https://github.com/kennethreitz/django-postgrespool/ 
>
> I have this in production for several months with no issues, so the 
> concept certainly works. 
>
> Carl 
>
>

-- 
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: Moving database backends out of the core

[Marc Tamlyn]

Seems to me that if database backends were separate from Django then the 
postgres backend would get a long way ahead of the others as much as the 
other backends would get behind - it's bound to attract the most work and 
be adding custom fields like hstore, arrays, json... I think this would be 
great for most of my use cases, but then again I also have to deploy a 
small proportion of sites on MySQL, so it's bound to bite me.

That said, I don't know why Oracle is included and MSSQL is not - pretty 
much none of the core devs currently use either (or would recommend it 
given the choice). Cross compatibility of Django core is really important, 
and should ideally be as far reaching as we can achieve. I'd rather see 
MSSQL pulled in, and hopefully testing of it via Travis at some point than 
things split out, as I think it's better for Django.

-- 
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: Ticket 20147 - deprecate and replace request.META

[Marc Tamlyn]

I agree wholeheartedly with the introduction of request.HEADERS. I can see 
Carl's point regarding deprecating META, and I think it would be fine for it to 
exist as an alternative implementation in the same way as request.REQUEST does.

-- 
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: RFC: "universal" view decorators

[Marc Tamlyn]

I'm going to resurrect this old thread as I'd like to get it resolved in 
some fashion.

I used to be very in favour of the class decorators approach. I've been 
using an implementation of `@class_view_decorator(func)` for some time and 
it works pretty well. That said my implementation at least was subject to a 
notable flaw which is that if multiple parts of the hierarchy have the same 
decorator applied to them then the check gets done twice. Mixins are much 
cleverer than this because of MRO, so we avoid that problem.

Mixins however have their own issues - it's "harder" (for some definition) 
to ensure that all of your top-level permission checking happening in the 
correct order. That said, I am certainly veering towards implementing this 
using mixins (for each piece of functionality).

I'd really like to have a look at Donald's implementation, sadly it seems 
to no longer be on github. Do you still have then code somewhere, or can 
you explain the implementation idea?

Marc


On Thursday, 15 September 2011 22:44:39 UTC+2, Jacob Kaplan-Moss wrote:
>
> Hi folks --
>
> I'd like to convert all the view decorators built into Django to be
> "universal" -- so they'll work to decorate *any* view, whether a
> function, method, or class. I believe I've figured out a technique for
> this, but I'd like some feedback on the approach before I dive in too
> deep.
>
> Right now view decorators (e.g. @login_required) only work on
> functions. If you want to use a decorator on a method then you need to
> "convert" the decorator using method_decorator(original_decorator).
> You can't use view decorators on class-based views at all. This means
> making a class-based view require login requires this awesomeness::
>
> class MyView(View):
> @method_decorator(login_required)
> def dispatch(self, *args, **kwargs):
> return super(MyView, self.dispatch(*args, **kwargs)
>
> This makes me sad. It's really counter-intuitive and relies on a
> recognizing that functions and methods are different to even know to
> look for method_decorator.
>
> #14512 proposes a adding another view-decorator-factory for decorating
> class-based views, which would turn the above into::
>
> @class_view_decorator(login_required)
> class MyView(View):
> ...
>
> This makes me less sad, but still sad. Factory functions. Ugh.
>
> I want @login_required to work for anything::
>
> @login_required
> class MyView(View):
> ...
>
> class Something(object):
> @login_required
> def my_view(self, request):
> ...
>
> @login_required
> def my_view(request):
> ...
>
>
> Now, back in the day we somewhat had this: decorators tried to work
> with both functions and methods. The technique turned out not to work
> (see #12804) and was removed in [12399]. See
>
> http://groups.google.com/group/django-developers/browse_thread/thread/3024b14a47f5404d
> for the discussion.
>
> I believe, however, I've figured out a different technique to make
> this work: don't try to detect bound versus unbound methods, but
> instead look for the HttpRequest object. It'll either be args[0] if
> the view's a function, or args[1] if the view's a method. This
> technique won't work for any old decorator, but it *will* work (I
> think) for any decorator *designed to be applied only to views*.
>
> I've written a proof-of-concept patch to @login_required (well,
> @user_passes_test, actually):
>
> https://gist.github.com/1220375
>
> The test suite passes with this, with one exception:
>
> https://code.djangoproject.com/browser/django/trunk/tests/regressiontests/decorators/tests.py#L87
> .
> I maintain that this test is broken and should be using RequestFactory
> instead.
>
> Can I get some thoughts on this technique and some feedback on whether
> it's OK to apply to every decorator built into 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: ORM expressions DEP

[Marc Tamlyn]

I've had a proper read of the patch and the DEP. As far as I'm concerned,
it's an extremely powerful and useful change. We may have some minor
modifications to make to the implementation as issues are found, but the
API decisions are good.

On 27 October 2014 12:04, Anssi Kääriäinen  wrote:

> The ORM expressions DEP (
> https://github.com/django/deps/blob/master/drafts/orm_expressions.rst) is
> now ready for review.
>
> In brief, the DEP proposes an improved and publicly documented way to
> write expressions for the ORM. The expressions can be used in .annotate()
> calls. The DEP also proposes that aggregates are a subclass of expressions.
>
> The benefits are:
>   - Public API to write expressions
>   - Simplified implementation of how expressions are added to the query
> and how they are evaluated
>   - Aggregates behave similarly to other ORM expressions
>
> A pull request by Josh Smeaton implements the DEP (
> https://github.com/django/django/pull/2496).
>
> My understanding is that we don't have yet any process for how to accept
> (or number...) DEPs. I propose that first the community reviews the DEP.
> Unless there is clear objection to the DEP, the technical board can then
> consider if (and how) they want to accept the DEP.
>
>  - Anssi
>
> --
> 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 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.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/9b7fcf81-e618-4ea5-a806-2ffd3cd42718%40googlegroups.com
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>

-- 
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 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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAMwjO1FXiagxmE%3DmmtF6z_nE16pQKuJ%2BnHrf%2B-A5_P0cenXrjA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Multiple template engines for Django - week 4 - DEP ready for review!

[Marc Tamlyn]

A few thoughts:

I like OPTIONS, I think it's a good idea for the reasons Carl suggested.

It would be preferable to have the backend configuration outside of
`django.template`. `django.templating` seems reasonable, but even
`django.template_backends` might be appropriate as it only contains
backends.

Assuming we go for the "subdirectory" based convention for app directories
(option 4?) it would seem appropriate to make this configurable. In
particular I can imagine a possibility where you may want multiple
instances of the same backend with different configuration (e.g. different
jinja extensions which conflict to support multiple pluggable apps). The
loading problem is the only obvious flaw I can see here. It's a weird use
case though.

I agree the DEP needs to specify more clearly what happens with `render`
and friends. I also think there's potential merit to Option 1 (engine=)
support on these APIs even with Option 4 - there may be times you need to
force the use of a particular engine.

Marc

On 3 November 2014 22:54, Carl Meyer  wrote:

> Hi Collin and Aymeric,
>
> On 11/03/2014 03:26 PM, Aymeric Augustin wrote:
> > Hi Collin,
> >
> > It’s exactly the right time to discuss APIs :-)
> >
> > After pondering your proposal, I'm still +0 on consistency with
> > DATABASES and CACHES, but I'll make that change if other people agree
> > with you. Does anyone else have an opinion on this?
> >
> > Thanks,
> >
> > --
> > Aymeric.
> >
> >
> >> On 3 nov. 2014, at 01:50, Collin Anderson  >> > wrote:
> >>
> >> Hi Aymeric,
> >>
> >> Thanks for all of your work on this. Am I too late to discuss the
> >> settings?
> >>
> >> I don't see much advantage to the OPTIONS dict. It is consistent with
> >> DATABASES, and it separates the engine specific settings from the
> >> common settings. However, it doesn't seem like that helpful of a
> >> distinction to the user, especially considering there's only 3(?)
> >> non-OPTIONS settings. It seems like it only opens up the door to
> >> misconfiguration. Could we just pop-off the 3 common settings when
> >> configuring the template engine?
>
> I favor keeping OPTIONS. I don't think OPTIONS will be significantly
> confusing to beginners (it may even provide a useful hedge between "the
> basics" and "the advanced knobs").
>
> Once you are doing anything beyond the basics, the distinction between a
> setting that is handled specially by Django vs one that is just passed
> as-is to the template backend is an important distinction to keep clear.
>
> OPTIONS provides clear indication (without referencing the docs) which
> settings you can expect to provide to any template backend with
> equivalent effects, and which ones are engine-specific. I think losing
> this clear distinction is likely to result in much more
> mis-configuration frustration than OPTIONS will.
>
> Carl
>
> --
> 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 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.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/5458079E.70104%40oddbird.net
> .
> For more options, visit https://groups.google.com/d/optout.
>

-- 
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 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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAMwjO1Gx_8vxCVdQHwnyQxPTznBG-BhAL-h7KtMeRgrXzjf5DQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Unicode SlugField design decision (#16501)

[Marc Tamlyn]

It feels to me more like an option to SlugField and I feel UnicodeSlugField
is a bit ugly. If however we find an example where Michael's point is valid
(an external 3rd party backend which uses ascii chars for SlugField now)
then we should go with that.

On 5 November 2014 03:20, Michael Manfre  wrote:

> Should the unicode validated field (either options) have a different
> internal type for the sake of 3rd party database backends? I'm not sure if
> any currently store SlugFIeld in an ascii char datatype and would need an
> easy way to differentiate.
>
> Regards,
> Michael Manfre
>
> On Tue, Nov 4, 2014 at 8:27 PM, Tim Graham  wrote:
>
>> I wanted to solicit feedback on the two approaches to supporting unicode
>> in SlugField:
>>
>> 1. Added a unicode argument to models.SlugField and forms.SlugField.
>> https://github.com/django/django/pull/1979
>>
>> 2. Added models.UnicodeSlugField and forms.UnicodeSlugField.
>> https://github.com/django/django/pull/1987
>>
>> The patch author says, "On one hand, I like the new field approach
>> because it gives us an easier upgrade path. On the other hand, it feels
>> like I'm polluting django.db.models and django.forms with slightly
>> different versions of something that's already there."
>>
>> Approach 1 does seem cleaner to me, but I'd be interested in hearing from
>> those interested in this feature.
>>
>> Ticket: https://code.djangoproject.com/ticket/16501
>>
>> --
>> 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 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.
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/django-developers/33e9747f-6ced-4710-9e59-ca128e065c5c%40googlegroups.com
>> 
>> .
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>  --
> 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 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.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/CAGdCwBv%3DfGD-DpG4w9Bd3_9FkcKiw_CYqhR8tJK8W1EC_zvQNg%40mail.gmail.com
> 
> .
>
> For more options, visit https://groups.google.com/d/optout.
>

-- 
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 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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAMwjO1H%2BCUXs%2B8_fQ_xiAMu%3DR%2BAxMNMmaTwaAEkavOmtAPcy8w%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Next LTS version after 1.4?

[Marc Tamlyn]

The current plan appears to be that 1.8 will be the next LTS, with 1.4
keeping security support until 6 months after 1.8's release. We will be
having a core meeting in 10 days in Amsterdam, I'll make sure it's
finalised.

Marc

On 5 November 2014 14:55, Rob Yates  wrote:

> On Monday, August 25, 2014 6:10:52 AM UTC-4, Aymeric Augustin wrote:
>>
>>
>> 1.4 is LTS until March 2015. Based on past release schedules, 1.8 should
>> be released a few months later.
>>
>> We could extend 1.4 support a bit and then make 1.8 the next LTS. In my
>> opinion, that's the most reasonable plan.
>>
>> That said, Russell rightly points out that we haven't made a definitive
>> decision yet.
>>
>
> I really hate to dig up an old thread, but was curious if there were
> additional discussions or decisions regarding LTS.  As much as our large,
> commercial project would love to stay on the cutting edge, our maintenance
> scenarios require that we settle in on a release for awhile.
>
> I'm concerned that we will soon have no supported LTS version and no
> recommendation for which previously-released version to settle on until a
> new LTS release is announced.  Does anyone have any recommendations?
> Thanks in advance for any guidance you can provide!
>
> -Rob
>
> --
> 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 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.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/e9d76b6d-9dea-45b0-8676-c3b1f2e05c82%40googlegroups.com
> 
> .
>
> For more options, visit https://groups.google.com/d/optout.
>

-- 
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 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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAMwjO1Ek8d-Mj9Y4K55hAnC5KrSzBDAit1BFEg1ceM5PTtLj0A%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Unicode SlugField design decision (#16501)

[Marc Tamlyn]

Even if the backend is storing using an ascii backed data type, it should
still return unicode data to Django anyway, so I'm not sure there would be
a difference.

Marc

On 6 November 2014 01:18, Michael Manfre  wrote:

>
>
> On Wed, Nov 5, 2014 at 7:53 PM, Shai Berger  wrote:
>
>> On Wednesday 05 November 2014 17:29:20 Michael Manfre wrote:
>> > We can change the internal type of SlugField for option 1 based upon
>> > whether or not the field should be unicode. Whether or not an existing
>> > backend stores SlugField in an ascii char datatype shouldn't dictate
>> > whether we go with SlugField(unicode=True) or UnicodeSlugField(). Let me
>> > rephrase the question as, Do we want to provide backends enough
>> information
>> > so that they can decide to store an ascii slug field in an ascii char
>> field
>> > (e.g. varchar) and a unicode slug field in a unicode char field (e.g
>> > nvarchar)?
>> >
>>
>> Could you please clarify the question? As far as I understand, schema
>> editors
>> get all the information anyway.
>>
>
> Constructing the schema is only one part of the process. The main bit I am
> concerned about is how the ORM will translate the data. There are several
> methods on DatabaseOperatoins that exist to act based upon a field's
> internal type string. E.g. get_db_converters, field_cast_sql.
>
> --
> 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 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.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/CAGdCwBtW2qXdR5vm8g6Trwp7_aMY9GRfHUSeCjONz10W7audpw%40mail.gmail.com
> 
> .
>
> For more options, visit https://groups.google.com/d/optout.
>

-- 
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 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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAMwjO1Gb0TtDUdZQ0Yj2yRr2AfweRG-VJxaUqJd-ucic%3D50jyA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Why doesn't ModelChoiceField.queryset support slicing?

[Marc Tamlyn]

The dangers of fetching objects in the class definition is precisely why
the extra `.all()` calls exist in `ModelChoiceField` and part of the reason
why this does not work. The proposed code from Thomas is dangerous, and
even putting that code in the `__init__` will result in rather inefficient
queries, although it will work.

To be more explicit as to why this is dangerous: django queries executed at
module level will be executed on start of the server, and not rerun as the
data or database underneath them changes until the server is restarted.
Depending on where they are, they may completely break the `migrate`
command needed to create the tables!

On 6 November 2014 11:16, Kamil Śliwak  wrote:

> Sorry, for a late reply.
>
> Personally I don't feel that it's a particularly common need, but I can
>> see your use case. More common is that a reasonable filter is applicable -
>> say books with a rating over 80.
>>
>
> Yeah, I thought about using some other filter but it's a bit harder to
> control the number of results that way. You can get more or less than you
> want if you can't predict the contents of the database. This makes sense in
> some situations but in others, like in mine, you just want top N results,
> no matter what they are and getting that with a filter is just a cumbersome
> workaround for something that can be easily expressed in SQL.
>
> As far as I know we don't have any support for SQL intersects and I don't
>> believe there are any plans to introduce it.
>>
>
> OK. My bad. I was under impression that you can get an INTERSECT with
> something like
>
> Book.objects.filter(id__gt = 100) & Book.objects.filter(id = 300)
>
> But looking at the SQL now I see that this simply combines the conditions
> with AND and that something like this fails:
>
> Book.objects.filter(id__gt = 100)[:10] & Book.objects.filter(id = 300)
>
> In that case the solution is not as straightforward as I originally
> thought.
>
> I do agree that this should be both documented and preferably raise an
>> error - please open a ticket.
>>
>
> OK.
>
> The obvious nicety handled by
>> ModelChoiceField is the transformation from ids back to objects; the less
>> obvious one is that a ModelChoiceField runs the query anew for every
>> form;
>> your ChoiceField cannot be initialized by a query in its definition, and
>> needs
>> to have its choices set in the form's __init__().
>>
>
> Thanks, good to know. I actually do want the instance to make this query,
> not the class as since the content of my table is not entirely constant.
>
> I can also add another gotcha to your list - if you fetch objects in class
> definition, the query is performed before the test runner can switch
> database to TEST_DATABASE so the data comes from the default database. I
> ran into this when trying to set 'initial' and it was breaking my tests. I
> have to move it to __init__().
>
> you can base your condition on some subquery, for instance :
>>
>> class BookForm(forms.Form):
>> book = forms.ModelChoiceField(queryse
>> t=Book.objects.filter(pk__in=Book.objects.order_by('-rating
>> ')[:100].values_list('pk')))
>>
>> I don't know if there is a better way to do that...
>>
>
> Thanks, that's a really nifty workaround. I thought that something like
> this would make two queries but I see that Django is smart enough to
> combine it into a single query with a subquery. Nice. A great thing is that
> I don't see any downsides to it except that it's a bit less clear than
> doing the limit in the main query. And I think that it shouldn't really
> degrade performance as the outer query is trivial.
>
> Maybe having the from detect LIMIT and do something like this internally
> would be a good way to handle this in the Form class?
>
> --
> 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 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.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/044f428c-8192-48ff-8619-21b22833a7fd%40googlegroups.com
> 
> .
>
> For more options, visit https://groups.google.com/d/optout.
>

-- 
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 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.
To view this discussion on the web vi

Re: Explicit relative imports

[Marc Tamlyn]

I agree wholeheartedly. (Sorry, not much else to say...)

On 11 November 2014 21:51, Aymeric Augustin <
aymeric.augus...@polytechnique.org> wrote:

> Hello,
>
> We’ve started using explicit relative imports in newer parts of the Django
> source tree. They’re short and readable. That’s good.
>
> I would like to add guidelines about imports in the coding style guide in
> order to improve consistency.
>
> My inclination would be to recommend relative imports within “components”
> but avoid them between “components”, where a component is:
>
> - a well-defined sub-framework (django.core.cache, django.db,
> django.forms, django.template, etc.)
> - a contrib app
> - an app in the tests/ directory
> - etc.
>
> I would discourage going back into parent modules with relative imports
> because statements such as `from ...spam import eggs` are hard to parse.
>
> You can see an example of this style in django.apps which has only three
> files.
>
> What do you think?
>
> --
> Aymeric.
>
>
>
> --
> 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 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.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/9FFE2185-6F9D-41EE-8A19-16C5538E6B53%40polytechnique.org
> .
> For more options, visit https://groups.google.com/d/optout.
>

-- 
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 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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAMwjO1EHGVyDfiuh1aYtXJkd2M51jOjPfwAPmUtB0dw%2B47voZQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Explicit relative imports

[Marc Tamlyn]

Whilst I think it's a bit nicer to be explicit in smaller projects, there
are a few places where django's structure can result in long import paths -
e.g. django.contrib.gis.db.backends where I think relative imports would
actually add clarity.

I tend to separate the relative section as the last block at the end of the
imports which further show what is "within" a component, rather than it
being buried within a large block.

In any case, explicit relative imports are greatly preferable to implicit
ones.

Marc
On 13 Nov 2014 13:57, "Tom Christie"  wrote:

> Contrary voice here, but I don't dig explicit relative imports, it's just
> adds an extra decision point for no real benefit.
>
> Personally I always recommend full absolute imports, ordered strictly
> alphabetically - there's then never any room for confusion or decision
> making around how the imports should be written, and it's always tidy and
> consistent.
>
> Not looking to necessarily change the Django project's stance on that, but
> that's the style I use throughout my projects and it's trivial to stick to.
>
> Cheers,
>
>   Tom
>
> On Wednesday, 12 November 2014 21:59:42 UTC, Jannis Leidel wrote:
>>
>>
>> > On 11 Nov 2014, at 22:51, Aymeric Augustin > polytechnique.org> wrote:
>> >
>> > Hello,
>> >
>> > We’ve started using explicit relative imports in newer parts of the
>> Django source tree. They’re short and readable. That’s good.
>> >
>> > I would like to add guidelines about imports in the coding style guide
>> in order to improve consistency.
>> >
>> > My inclination would be to recommend relative imports within
>> “components” but avoid them between “components”, where a component is:
>> >
>> > - a well-defined sub-framework (django.core.cache, django.db,
>> django.forms, django.template, etc.)
>> > - a contrib app
>> > - an app in the tests/ directory
>> > - etc.
>> >
>> > I would discourage going back into parent modules with relative imports
>> because statements such as `from ...spam import eggs` are hard to parse.
>> >
>> > You can see an example of this style in django.apps which has only
>> three files.
>> >
>> > What do you think?
>>
>> Yup, the way to go.
>>
>> Jannis
>
>  --
> 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 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.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/7f1a5323-1efd-4891-bc02-eab5d67bc8b4%40googlegroups.com
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>

-- 
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 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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAMwjO1GAyv%3DU939LQiKYJeM_z3EOzPXEYMOPteDoOuOUoefH%3DQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Backend-specific lookups

[Marc Tamlyn]

The test failures on the CI would suggest that overriding
`get_db_prep_lookup` is a problem!

There are changes on my ranges branch which move the % sign addition out of
`Field.get_db_prep_lookup` and into the relevant lookup. This makes
overriding certain lookups (e.g. contains, startswith etc) much cleaner for
field types where that name makes sense but it does not mean text. You can
see those here:
https://github.com/mjtamlyn/django/commit/3c45e2cfecbc2c8da6e4a05c5db3367c5cabfde7

I've commented on the PR with more details.

On 15 November 2014 23:06, Shai Berger  wrote:

> On Sunday 16 November 2014 00:46:43 Josh Smeaton wrote:
> > Clever. I don't mind this approach at all. Will the overriding of
> > get_db_prep_lookup interfere with other implementations though?
> >
>
> Yes, it probably would. It is there because the default one for the lookup
> adds % signs around the value, which I didn't want; and within the evening
> I
> couldn't find the clean way to get rid of that [in retrospect, I think I
> need
> to invoke the grand-grand-parent -- super(BuiltinLookup,
> self).process_rhs()]
>
> Shai.
>
> --
> 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 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.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/201411160106.16550.shai%40platonix.com
> .
> For more options, visit https://groups.google.com/d/optout.
>

-- 
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 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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAMwjO1HWBmf_EdKuZQUJ8WW_MLavwSd5R6uZ-3PJMxErKDjgJg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Adding hard dependencies to Django's test suite

[Marc Tamlyn]

I agree. Anyone wanting to contribute to Django should be able to run a pip
install -r test_requirements.txt.

Marc

On 28 November 2014 at 04:03, Fabio Caritas Barrionuevo da Luz <
bna...@gmail.com> wrote:

> python 2.7.9 rc1 include a backported version of python3 ensurepip
>
> see:
>
> https://hg.python.org/cpython/rev/592a5414fabd
> https://docs.python.org/2/library/ensurepip.html
>
>  --
> 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 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.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/173434d5-3313-47b6-bfed-07463c58aa8a%40googlegroups.com
> 
> .
>
> For more options, visit https://groups.google.com/d/optout.
>

-- 
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 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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAMwjO1HQWb-2MqYCThmBNHGcS_trEho5RwCOH-y0PCcZOp5-iw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Internationalise GET parameters?

[Marc Tamlyn]

I'm afraid I have to agree the gain does not merit the effort.

To the average user, I think the query string already looks like it's weird
code stuff (with &=?) so I don't think it being in a different language
would improve things that much.

Marc
On 28 Nov 2014 13:36, "Florian Apolloner"  wrote:

>
>
> On Friday, November 28, 2014 11:17:15 AM UTC+1, Jorge C. Leitão wrote:
>>
>> IMO, this lies on the assumption that the Form's field names are never
>> shown to the user. When the form is POST, this assumption is valid.
>> However, in a GET, the field names are presented in the URL, and the
>> assumption breaks. This even exposes serve-side implementation details (the
>> field name of the Form) to the user.
>>
>
> You always expose some server information, even with POST -- you just
> don't see the parameters in the URL
>
>
>> 1. how common is this?
>>
>
> No idea on that, but field names are programmatic identifiers (as you
> said, they are an implementation detail), translating those will break
> loads of things.
>
>
>> 2. wouldn't it add a lot of complexity to JavaScript and CSS,
>> specifically on name selectors?
>>
>
> They wouldn't work anymore unless you send a mapping to the client, again
> exposing server implementation details.
>
>
>> 3. do any other web framework support this?
>>
>
> Not that I am aware.
>
> Could we have some feedback to decide wether it justifies or not to have
>> this in Django?
>>
>
> Personally, I am against it, I don't think that the gains justify the
> effort.
>
> Cheers,
> Florian
>
> --
> 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 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.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/c3258005-6bac-483f-b425-2681b8898b34%40googlegroups.com
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>

-- 
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 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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAMwjO1GUf7x06sum_G%2Bn7kueSySZs_8M7Qrh2-P_f_GPzHaLyQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: DB Migrations: Proposed fix for "Index name collisions after objects are renamed then re-created"

[Marc Tamlyn]

I intend the new indexes to have customisable names, and to deconstruct
their name into the migration. This means that any changes in the name (if
the name is autogenerated) would be detected. It should be possible to do
renames.

It is worth noting that mysql (and sqlite obviously) do not support
renaming of indexes and the index would need to be dropped and rebuilt. On
large tables this would be a problem, so we'll need some warnings in the
documentation about how to fix the index name so it is not identified as a
change.

On 1 December 2014 at 19:15, Markus Holtermann 
wrote:

> Hey folks,
>
> I don't like the idea of expected failures either.
>
> Given the fact that at one point user defined indexes are going to be
> introduced, I would consider to delay this issue for now until the DEP has
> been accepted and is (being) implemented. At that point we know what the
> underlying API in e.g. the schema editor is and how we are generating the
> indexes in migrations. We might end up with AddIndex, AlterIndex and
> DeleteIndex operations where CreateModel etc don't know about the index.
>
> Introducing some - in any way hacky-ish - "solution" to prevent duplicate
> index names would probably be deprecated as soon as custom indexes are
> implemented. That said, touching the migration operations for 1.8 (LTS) in
> a way that we are not sure yet is are going to stay, and later introducing
> a new API, seems a bit odd and complicated in terms of backwards
> compatibility from 1.9? where indexes are introduced.
>
> /Markus
>
>
> On Monday, December 1, 2014 6:35:17 PM UTC+1, Tim Graham wrote:
>>
>> I'm not in favor of merging expectedFailure tests:
>> * It adds the overhead of time running tests that we know aren't expected
>> to work.
>> * It's more code to maintain (might go stale in the meantime anyway).
>> * An issue might be obsoleted (via deprecation, etc.) at some point.
>> * When viewing commit history, it seems clearer to add tests when fixing
>> an issue rather than removing a decorator on a test (the contents of the
>> test won't be easily viewable in the latter case).
>>
>> We currently have < 10 tests marked as such in the test suite now. I'd
>> like to audit them to check their state. Here's a ticket if anyone wants to
>> help with that: https://code.djangoproject.com/ticket/23943
>>
>> On Monday, December 1, 2014 12:18:31 PM UTC-5, Carl Meyer wrote:
>>>
>>> On 11/30/2014 05:54 AM, tomv wrote:
>>> > It's important to note that right now, index names are not
>>> re-creatable in
>>> > retrospect. They rely on the names of models and fields, that are free
>>> to
>>> > be renamed. So a complete rethink will be needed if introspection can
>>> no
>>> > longer be used for user-specified types of indexes. For example, maybe
>>> the
>>> > user should choose the name, which they should make unique at the app
>>> > level? Or if not, Django will need to either keep a record of the
>>> generated
>>> > index name somewhere, or start renaming indexes to keep them
>>> up-to-date
>>> > with the components in their names.
>>>
>>> I think one way or another with the indexes DEP we will need to surface
>>> the name of an index as an explicit part of its deconstructed
>>> specification (just like with fields, models, etc). This implies
>>> probably letting the user pick an explicit name if they want. We could
>>> also keep the option of using an autogenerated default name, but in that
>>> case migrations should notice if that autogenerated name changes and
>>> generate an index-name-change operation.
>>>
>>> > What's the best way to proceed with the index name collision ticket
>>> #23577
>>> >  at this point then? I
>>> can:
>>> >
>>> >1. re-write my "use migration names in index names" branch
>>> >>> with_poc_migration_name_fix>
>>> >to allow index suffix names passed from migration operations?
>>>
>>> What about having the entire index name explicitly passed from the
>>> operation in migrations (even if for now its always autogenerated
>>> there)? That seems like maybe a step towards where I think we'll
>>> eventually need to be. (But take with a grain of salt, you've been in
>>> this code and I haven't).
>>>
>>> >2. or declare there's no consensus on the solution / we'll wait for
>>> >Mark's index DEP - in which case, can I submit my tests
>>> >
>>> as
>>> >xfails?
>>>
>>> Hmm, that's an interesting idea. It's not something we've generally done
>>> in the past, but it might be better than just letting the tests bit-rot
>>> as an un-merged PR, later probably needing to be rebased. I'm curious
>>> what others think of the idea of actually merging xfail tests for
>>> unfixed bugs?
>>>
>>> Carl
>>>
>>>  --
> You received this message because you are subscribed to the Google Groups
> "Django developers (Contributions to Djang

Re: Status of #15619: logout via POST, but not GET

[Marc Tamlyn]

>From a brief look, the changes in the pull request do not appear to
consider backwards compatibility at all, which would be important.

The argument that it's ok because it would now just show a confirmation
page is insufficient as if someone had built a confirmation page there
would now be two. Also it requires every user to ensure such a confirmation
page fits the look of their website.

A possible solution would be to introduce a new view (logout_confirm) which
describes the new behaviour and throw deprecation warnings on the old
logout view.

In my opinion this change is not worth the backwards incompatibility.

On 4 December 2014 at 00:25, Tim Graham  wrote:

> I think you're thinking of https://code.djangoproject.com/ticket/17209.
> The latest patch appears to allow logout via GET, but even it enforced
> POST, there are still client-side (template) updates required to turn the
> logout links into form submissions so I think it should be considered an
> independent task (I may be missing your reasoning).
>
> On Wednesday, December 3, 2014 6:48:48 PM UTC-5, Curtis Maloney wrote:
>>
>> Wasn't there a PR to turn all the auth views to CBV?
>>
>> That would implicitly enforce the behaviour to POST-only, I would hope.
>>
>> --
>> Curtis
>>
>>
>> On 4 December 2014 at 09:52, Tim Graham  wrote:
>>
>>> Hi Tim,
>>>
>>> There's an open pull request
>>> , but it was opened over a
>>> year ago and has gone stale. Maybe you'd like to review and update it.
>>>
>>> You can use the patch review checklist:
>>>
>>> https://docs.djangoproject.com/en/dev/internals/
>>> contributing/writing-code/submitting-patches/#patch-review-checklist
>>>
>>> If you are happy with the patch after that, please mark the ticket as
>>> "ready for checkin" for a final review from a core developer.
>>>
>>> Thanks!
>>> Tim
>>>
>>>
>>> On Wednesday, December 3, 2014 5:02:42 PM UTC-5, Tim Chase wrote:

 I've had a couple cases where browser link pre-fetching triggered
 an unintended logout from my Django app (I haven't fully tracked down
 the exact combination of triggering conditions, but I suspect they
 similar to Israel Brewster's CherryPy issue mentioned on
 comp.lang.python [1]) and was surprised that Django suffered the same
 issue.

 Researching, I found https://code.djangoproject.com/ticket/15619
 but see that it was last modified ~10mo ago, having been opened ~4yrs
 ago.  The current (development HEAD from git) versions of

   django/contrib/auth/views.py:logout()
   django/contrib/auth/__init__.py:logout()

 still don't seem to contain any checks to ensure logouts can only
 happen via POST rather than GET requests.

 Is there any movement forward on resolving this so my browser
 doesn't inconveniently boot me from the app when I don't intend to
 log out?

 -tkc

 [1]
 https://mail.python.org/pipermail/python-list/2014-December/682106.html






 .

>>>  --
>>> 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 it, send
>>> an email to django-develop...@googlegroups.com.
>>> To post to this group, send email to django-d...@googlegroups.com.
>>> Visit this group at http://groups.google.com/group/django-developers.
>>> To view this discussion on the web visit https://groups.google.com/d/
>>> msgid/django-developers/c888627a-d1da-4755-ad77-
>>> 055b7837c2e2%40googlegroups.com
>>> 
>>> .
>>>
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>>
>>  --
> 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 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.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/03ade6e9-457c-4d17-a4bf-542bfed0ef4c%40googlegroups.com
> 
> .
>
> For more options, visit https://groups.google.com/d/optout.
>

-- 
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 it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googleg

Re: Should annotations allow model field constraints?

[Marc Tamlyn]

I think this should be an error personally - I'm not sure how we check that
effectively and efficiently.

It reminds me of asking postgres to cast a certain type to another one - it
will throw an error if any record it tries to cast can't be done.

Is it possible with say a CharField to not have a max_length parameter
here, even though you can't make a concrete field without it? If not then
we have another issue.

Marc

On 5 December 2014 at 06:15, Anssi Kääriäinen 
wrote:

> On Thu, 2014-12-04 at 18:04 -0800, Josh Smeaton wrote:
>
> >
> > I've implemented https://github.com/django/django/pull/3655/ which
> > effectively ignores the max_digits and decimal_places arguments in the
> > base expression class. Subclasses are free to enforce validation if it
> > is necessary. Further, callers using aren't required to supply bounds
> > checking in this situation.
>
> It seems wrong to throw away constraints the user has explicitly set.
> So, if you say:
>
> .annotate(sum_age=Sum('age', output_field=DecimalField(max_digits=3)))
>
> then it seems that the max_digits should really be 3.
>
> So, if the user explicitly asks for max_digits=3 in the output_field
> argument, then we should enforce that. Or, alternatively we should
> disallow setting max_digits for explicit output_field in expressions.
> But just throwing away the value the user has explicitly set is wrong.
>
>  - Anssi
>
> --
> 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 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.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/1417760145.22478.72.camel%40TTY32
> .
> For more options, visit https://groups.google.com/d/optout.
>

-- 
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 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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAMwjO1FHqFX0ZViVCQSDZRrFL6kBo07%3DR8hU0XTM-fV1CGb3%2BQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Experimental APIs DEP

[Marc Tamlyn]

I'm going to agree with Tim, it's a good idea but it is hard to agree on
its impact without the specifics.

On 8 December 2014 at 15:04, Tim Graham  wrote:

> I am skeptical like Carl, but it seems to me the time to introduce and
> discuss this DEP is when there is an actual feature that we think could
> benefit from this policy so we don't have to talk in hypotheticals.
>
>
> On Monday, December 8, 2014 7:00:44 AM UTC-5, benjaoming wrote:
>>
>> Hi guys!
>>
>> As an external user of Django, relying on its stability, I'd like to
>> comment In general, I think this is possibly a good improvement.. but
>> possibly also a very dangerous one...
>>
>> On Monday, December 8, 2014 12:38:18 AM UTC+1, Russell Keith-Magee wrote:
>>>
>>>
>>> On Sun, Dec 7, 2014 at 6:35 PM, Shai Berger  wrote:
>>>
 I like the general idea of experimental API, although Carl and
 Aymeric's notes
 are important: If we do this, we need to very picky in its use, or else
 it
 just becomes an easy route to avoid committment. In particular, there
 should
 be a hard-and-fast rule that nothing should be made an "experimental
 API" if
 it can just be done outside of core.

 For the example given -- backend API -- I think that, again, Carl and
 Aymeric
 are right; the examples I have more in mind for this are user-facing ORM
 features like the expressions, or custom lookups. I think it might be
 better
 to let people play with them more, in a released version, before
 setting the
 APIs in concrete.

 With that in mind, I would also reconsider adding a silent warning when
 the
 features are used -- because, if they are for general use (as opposed
 to the
 use of, say, 3rd-party backend developers) then there's a significant
 use-case
 where the person who would use the API is not the person who configures
 the
 warnings on the CI.

>>>
>>> To my mind, the role of this new status is closer to "provisional",
>>> rather than "experimental". It's a recognition of the fact that no matter
>>> how many times we ask for pre-release testing, the first *real* test of any
>>> API is when it sees real-world use.
>>>
>>
>>
>> What I would fear is not so much that experimentals/provisionals end up
>> in other parts of Django itself: The Django team is well-disciplined and
>> will understand its own release protocol :)
>>
>> I'm more worried that the application ecology starts suffering from
>> symptoms of an experimental attitude in the Django project...
>>
>> This DEP would definitely have to be understood by the outside
>> app-developer: For the stability of third-party apps, app maintainers
>> should consider to put "don't use experimental APIs" in their contribution
>> guidelines and make sure to go through the painful process of rejecting
>> well-intended PRs relying on experimental components. Especially if it's
>> decided not to raise Warnings when experimental modules are imported.
>>
>> For the projects and applications that do use experimentals, it would be
>> nice to have a guarantee of a smooth API transition when the next Django
>> ships. DEP states that APIs can change, but that it *shouldn't* do so.
>> If stated that the API should not change, that causes for a much more
>> significant guarantee, and sets the bar reasonably high for new
>> experimental components.
>>
>> The amount of deprecations in Django in general is very high, and
>> currently, supporting both South and db.migrations is quite hard. So adding
>> more complexity to multi-version Django support does not sound very
>> attractive to me and should be avoided at all costs.
>>
>> Some suggestions for the "experimental" definition / ruleset:
>>
>>- API has been thoroughly agreed and is not subject to change.
>>- Only stability and performance is a questionable part that makes a
>>feature experimental.
>>- Internal parts of an experimental component are expected to change
>>more than usual
>>- Something does not get pulled out without a deprecation warning,
>>even though it's experimental
>>
>> If experimental components will be allowed to change their APIs, I would
>> definitely suggest a Warning to be raised so they're kept out of the app
>> ecology.
>> The relevant part of the DEP reads:
>>
>> Instead, an Experimental designation will allow APIs to be included in
>>> Django and released without being beholden to the full deprecation cycle.
>>>
>>
>> If you allow that to happen, then in essence, anything can be released
>> and removed again. But there should be a clear intention when something is
>> released, that it will be made permanent, right?
>>
>> DEP also states:
>>
>> Effort will be taken to communicate to users that the APIs in question
>>> are not stable to avoid inadvertent use.
>>>
>>
>> I don't think that's possible. If the feature is attractive, it will be
>> used.
>>
>> RKM wrote:
>>
>> due to fears over whether the public-f

Re: Vendoring XRegexp

[Marc Tamlyn]

I'm certainly in favour of not reinventing the wheel here. As a side note,
I would love to have the javascript slugify functionality easily usable
outside the admin.

On 20 December 2014 at 04:51, Berker Peksağ  wrote:
>
> While I'm working on #3729 [1], I had to update current regexes to
> match unicode codepoints. Unfortunately, JavaScript has no proper
> support for unicode character classes, so writing unicode aware regex
> is a bit difficult: http://stackoverflow.com/a/280762
>
> I would like to add XRegexp to django.contrib.admin. It's a popular,
> well tested and small library. It will only be imported if you pass
> ``unicode=True`` to SlugField and define ``prepopulated_fields`` in a
> ModelAdmin.
>
> [1] https://github.com/django/django/pull/3729
>
> --Berker
>
> --
> 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 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.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/CAF4280KA9FvC082bySLnDCcUQOyJ0nJ5nXJhnO3U6Hy%2BMVVbxQ%40mail.gmail.com
> .
> For more options, visit https://groups.google.com/d/optout.
>

-- 
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 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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAMwjO1HhWBbZA7XNfAnFFBhra_J6Fe0X4Vz9q4gbHgcqbnZRAg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: simplifying the default template context_processors

[Marc Tamlyn]

I like it from a purity point of view, but I'm dreading updating through it
and replacing every instance of `{{ STATIC_URL }}` in my templates...

I also have a number of small projects which add a custom context processor
which add a certain queryset into the context every time because they form
a part of the page navigational architecture. I don't really want to have
to do this either 1) in every view or 2) via a custom template tag (because
I hate custom template tags). A similar example would be the
`add_page_if_missing`[1] context processor provided by feinCMS - it adds
the best matching CMS page to every view's context so your custom views
don't have to load the page themselves every time.

So I'm maybe +0 on the changes suggests, but I'm -0 on removing the whole
concept of context processors, at least without a suitable "one hit" way of
getting certain variables into the context of (nearly) every page.

Marc

[1] http://www.feinheit.ch/media/labs/feincms/api/contextprocessors.html

On 10 January 2015 at 22:40, Collin Anderson  wrote:

> Hi All,
>
> In talking to Aymeric and other developers, we're starting to think about
> the usefulness of global template context_processors. It seems to us that
> ideally you should only need the "request" context processor. You could
> even imagine removing context_processors all together and having render()
> and class based views simply put the request in the context.
>
> Some ways to avoid context processors:
> {% static "my.css" %} instead of {{ STATIC_URL }} (a good idea regardless)
> {{ mediafile.url }} instead of {{ MEDIA_URL }}
> {{ request.user }} instead of {{ user }}
> {% get_current_timezone as TIME_ZONE %}
> {% get_current_language as LANGUAGE_CODE %}
>
> I propose:
>
> - Enabling the request context processor for new projects.
> - Modifying the admin to work without context processors.
> https://code.djangoproject.com/ticket/24117
> - Removing the other context processors for new projects. (Possibly
> waiting for 1.9).
> - Possibly adding `request.messages` similar to `request.user`.
> - Maybe adding `user.perms` or a template tag to replace {{ perms }}
>
> This would be a somewhat controversial change. I think django originally
> tried hard to keep the request as separate from the response as possible.
> This would tie the two together even more. In my experience working with
> django projects, it's often very helpful to have the request object
> directly available in templates.
>
> What do you think?
>
> Collin
>
>
>  --
> 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 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.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/bf74b593-3fbb-46fe-89f6-ce280124d707%40googlegroups.com
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>

-- 
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 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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAMwjO1Gx29ztS9xA-cA3Pn2H9U4P6JjwPxo7fx1qqY8EBkd_Jw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Can't login after upgrading to 1.7.3, and workaround

[Marc Tamlyn]

I think therefore you could resolve the issue by doing
save(update_fields=['count']) in your code.

On 15 January 2015 at 06:31, Horacio G. de Oro  wrote:

> Yeap. Removing the save() done in  solved the issue.
>
> And some component is doing and update() - not a save(). I see in the
> Postgresql logs an UPDATE of the hash with the new increment, that includes
> only the "password" field.
>
> I thought that autenticate() produced a read operation on the DB... now I
> know that it's read/write!
>
> So, it's not a Django issue :-)
>
> Thanks!
> Horacio
>
>  --
> 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 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.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/3cfce232-a561-4c79-8728-8f33548d2cf3%40googlegroups.com
> 
> .
>
> For more options, visit https://groups.google.com/d/optout.
>

-- 
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 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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAMwjO1H670%2BtBM%3Dd2CVRUFnArR%3DwoeZB-gOHE7g6NPu_pOjHjg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Settings: lists or tuples?

[Marc Tamlyn]

I think Florian's point would be that you can still do:

from django.conf import settings
settings.TEMPLATE_DIRS += ('foo',)

if it is a tuple, so I don't really see how it being a tuple is making it
necessarily more safe than a list - is the above code really much different
to:

from django.conf import settings
settings.TEMPLATE_DIRS.append('foo')

On 19 January 2015 at 14:45, Andreas Kahnert 
wrote:

> I'm not talking about modifications inside the settings.py but in other
> place. With lists, unexperienced devs might do things like: from
> django.conf import settings; settings.TEMPLATE_DIRS[3] = '/my_tpls'; and
> expect to work out good. (This doesn't violate the docs, since technicaly
> settings.TEMPLATE_DIRS is still the same list, means the settings variable
> itself hasn't been changed.) This is realy just a question of logic: lists
> are mutable - settings are immutable; see the conflict?
>
> Am Montag, 19. Januar 2015 14:20:51 UTC+1 schrieb Florian Apolloner:
>
>>
>>
>> On Monday, January 19, 2015 at 12:35:10 PM UTC+1, Andreas Kahnert wrote:
>>>
>>> I'm strongly against lists. Lists are mutable objects, their components
>>> can be changed in place. The settings are initialized at server start and
>>> after that changes on them arn't reflected. Therefore all settings should
>>> be tuples from my point of view. Using a custom list/tuple class for "easy"
>>> notation within the settings.py might be an option, but after server
>>> startup all of those should be immutable. So for the sake of logic, take
>>> tuples, please.
>>>
>>
>> As long as  something like settings.MY_SETTING=(1,);
>> settings.MY_SETTING+=(1,2,3) works, that argument is kinda moot imo.
>>
>> Cheers,
>> Florian
>>
>  --
> 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 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.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/5b974048-0c9f-4ae2-8ff2-8db1fbd736f4%40googlegroups.com
> 
> .
>
> For more options, visit https://groups.google.com/d/optout.
>

-- 
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 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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAMwjO1FOBDj3V5KaPBNkMbg__cgkLAQjHXYpx3GyUQB1waWfEg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Support SECRET_KEY and Database creds as callables

[Marc Tamlyn]

I'm not sure what the benefit here would be - the settings are evaluated at
start up time, not on every request and the server would need to be
restarted for it to change.

A patch to db.connections which allows the username and password to be
looked up on each new connection might be interesting, although I'd be
concerned that for any reasonably high traffic site this would be happening
a *lot*, normally during a user request. Something like caching it and then
clearing the cache when it changes upstream would be more appropriate.

Marc

On 24 January 2015 at 03:06, 'Andres Mejia' via Django developers
(Contributions to Django itself)  wrote:

> Hello Django devs,
>
> I would like to see if Django can support setting the SECRET_KEY and
> database creds as callables. Let me explain my situation.
>
> Here at Amazon, we use a system to store and fetch secrets such as a
> Django SECRET_KEY and database creds. There's a Python component to this
> system which works something like this.
>
> SECRET_KEY = get_creds(secret_key_id, type='privatekey')
> . . .
> DATABASES = {
> 'default' = {
> . . .
> 'USER': get_creds(database_creds_id, type='username'),
> 'PASSWORD': get_creds(database_creds_id, type='password'),
> },
> . . .
> }
>
> Secrets are rotated on a regular schedule or as needed. Often times the
> secrets are rotated without advance notice and therefore our various Django
> powered sites go down (because they can't connect to the database) until
> the web servers are restarted. We would prefer it if our web services did
> not have to be restarted.
>
> I was going to propose a patch which modifies the force_text and
> force_bytes methods in django.utils.encoding. The modifications basically
> involves adding an if statement.
>
> if hasattr(s, '__call__'):
> return s()
>
> This would support setting the SECRET_KEY and database creds as callables
> with no arguments. Example.
>
> SECRET_KEY = lambda: get_creds(secret_key_id, type='privatekey')
> . . .
> DATABASES = {
> 'default' = {
> . . .
> 'USER': lambda: get_creds(database_creds_id, type='username'),
> 'PASSWORD': lambda: get_creds(database_creds_id, type='password'),
> },
> . . .
> }
>
> My question is, should I submit a patch or might there be some other way
> to address my use case? Also, I'm aware of the various examples which call
> for storing secrets in a separate file. We cannot store secrets on the
> local disk (this is partly the reason for the use of the system I
> explained).
>
> --
> Andres
>
> --
> 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 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.
> To view this discussion on the web visit https://groups.google.com/d/
> msgid/django-developers/54C30C4D.4030302%40amazon.com.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
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 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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAMwjO1H2d%3DFiTM%2BKhO1-4ip-SyNHymA5L98pQ6TAA0Kx5UwcPA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: GSOC 2015 project ideas suggestion

[Marc Tamlyn]

Anything not done from previous years is likely to be suitable yes.

It would also be very beneficial to familiarise yourself with the
contributing guidelines for Django[1] and take on some small fixes, perhaps
in related areas to your interests for GSOC.

Marc

[1] https://docs.djangoproject.com/en/1.7/internals/contributing/

On 27 January 2015 at 17:15, Asif Saifuddin  wrote:

> Hi,
>
> Although probably It's quite very early to ask about GSOC 2015 in January,
>  I would like to start analyzing to prepare myself for choosing a correct
> project and submitting a good proposal for that to get selected. I haven't
> found any GSOC 2015 project ideas pages yet. But got some older idea pages
>  of year 2013 and 2014. Should I look forward to the ideas that were
> unimplemented or wait for gsoc 2015 wiki ideas page?
>
> ./auvipy
>
> --
> 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 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.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/92f8aa3d-69da-4be2-af5a-b2a0f55d616b%40googlegroups.com
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>

-- 
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 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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAMwjO1HbczNPozaZ3pbWx_MrPjak4Ly6jJfcW1wO0NWKefuBqw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: importing threading and dummy_threading

[Marc Tamlyn]

Given that it already doesn't worth without full threading in the previous
LTS, I don't think we need to worry about it.

On 28 January 2015 at 14:32, Tim Graham  wrote:

> Here's a 9 year old ticket referencing freebsd5.1...
>
> https://code.djangoproject.com/ticket/2052
>
>
> On Wednesday, January 28, 2015 at 8:51:16 AM UTC-5, Tim Graham wrote:
>>
>> As far back as Django 1.4 (didn't check earlier), we use both these
>> patterns in the code:
>>
>> import threading
>>
>> try:
>> import threading
>> except ImportError:
>> import dummy_threading as threading
>>
>> We also have logic in tests to skip if threading isn't available,
>> however, I can't believe that Django is usable without threading given we
>> use the first style of import (without a fallback) in many places
>> (db.models.loading, db.utils, test.testcases, + more).
>>
>> Docs say:
>>
>> "The dummy_threading
>> 
>> module is provided for situations where threading
>> 
>> cannot be used because thread
>>  is
>> missing."
>> https://docs.python.org/2/library/threading.html
>>
>> "The [thread] module is optional. It is supported on Windows, Linux, SGI
>> IRIX, Solaris 2.x, as well as on systems that have a POSIX thread (a.k.a.
>> “pthread”) implementation."
>> https://docs.python.org/2/library/thread.html#module-thread
>>
>> This doesn't answer the question of what systems it *is* needed on.
>> Unless there's an objection, I think we can remove dummy_threading
>> fallbacks?
>>
>  --
> 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 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.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/2147f7e7-1251-42ff-81e2-ad3b453060a5%40googlegroups.com
> 
> .
>
> For more options, visit https://groups.google.com/d/optout.
>

-- 
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 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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAMwjO1GiQaYb0_qc8xDat9mMW35xThogqfqynRwSFKfcRgTOPQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: automated import sorting and better pull request checks

[Marc Tamlyn]

Would it be possible to use travis for flake8/docs checks? That would
hopefully automatically show up as two separate flags on the status API. Of
course it would be really nice if the docs and flake8/isort and tests all
displayed separately.

An alternative could be to use code climate which currently has as private
alpha for python: https://codeclimate.com/python

Marc

On 29 January 2015 at 13:18, Tim Graham  wrote:

> As a code reviewer, I've really appreciated that we've cleaned up the code
> using flake8 and have automated "enforcement" via the CI server. I'd like
> to extend the idea to apply to standardizing import ordering using isort
> [1]. This mail is to advise everyone of the change and to address any
> concerns.
>
> Documentation:
> https://github.com/django/django/pull/4008
>
> Automated cleanups:
> https://github.com/django/django/pull/4009
>
> On a related note, the UI for flake8 errors isn't currently very good (you
> have to look at the bottom of the Jenkins build logs). I'd like to improve
> that by using a separate service that uses the GitHub status API [2] so
> that the check can run separately from the tests build. I don't want to
> reinvent the wheel though, so if there is an existing service we can use
> for this, great. I'd like to also add checks for documentation build and
> spelling errors, as well as isort checks (assuming adoption per above).
>
> [1] https://github.com/timothycrosley/isort#readme
> [2]
> https://github.com/blog/1935-see-results-from-all-pull-request-status-checks
>
> --
> 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 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.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/d356e388-fa45-4fdf-871f-ce484a7b43bf%40googlegroups.com
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>

-- 
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 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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAMwjO1H-Kas-tWwyM8G9dO9dRwtOjG%2BTXxXWAFoxVAXqq87owg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Feature proposal: Conditional block tags

[Marc Tamlyn]

I personally don't see any problem with the existing syntax and find it
much easier to understand.

On 31 January 2015 at 12:43, Aymeric Augustin <
aymeric.augus...@polytechnique.org> wrote:

> Hello,
>
> That’s a rather specialized behavior for the general purpose {% block %}
> tag.
>
> I’m not convinced that building in such specialized behavior beats
> composing blocks i.e. handling the condition with a {% if %} tag.
>
> The Django template language has way too much ad-hoc, inconsistent syntax
> in its built-in tags. I don’t like the idea of adding more.
>
> We have to balance saving keystrokes against increasing the amount of
> things every Django user needs to know. In this regard, adding that new
> syntax looks like a bad tradeoff to me.
>
> --
> Aymeric.
>
>
>
> On 30 janv. 2015, at 19:46, Markus Amalthea Magnuson <
> markus.magnu...@gmail.com> wrote:
>
> Hey all,
>
> Tim Graham suggested I posted to this list regarding an idea for a new
> feature: conditional block tags.
>
> I've summarized the feature in this ticket:
> https://code.djangoproject.com/ticket/24232
>
> The basic idea is to be able to write something like this in a template:
>
> {% block myblock if myvariable %}my content{% endblock %}
>
> If the condition is false it is as if the block wasn't there, meaning its
> parent would be rendered instead, if it exists.
>
> This is really a short form of:
>
> {% if myvariable %}
>   my content
> {% else %}
>   {{ block.super }}
> {% endif %}
>
> Note that it may seem similar to ticket #9173 but they are different,
> which I try to make clear in this comment:
> https://code.djangoproject.com/ticket/24232#comment:2
>
> So, what do you think?
>
> --
> 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 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.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/9ce259ff-6a2e-493a-a6df-1c15b43fe9c0%40googlegroups.com
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>
>
>  --
> 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 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.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/E5734A77-AE8F-4F70-BA87-97F2D77D5488%40polytechnique.org
> 
> .
>
> For more options, visit https://groups.google.com/d/optout.
>

-- 
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 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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAMwjO1FWL4M8h9yn7E-Oz0AobU%3D3QC%2BZPO9HYGnh24pkTAuYBw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Postgres specific fields and third party apps.

[Marc Tamlyn]

I would strongly disagree with supporting these on SQLite, in any format. A
fully supported version would be complex to support and enormously
inefficient, and I'm not in favour of Django shipping half baked features
with major holes in them. I certainly don't have the motivation to build
this.

Mark any relevant tests to be skipped unless you're using postgres, and run
postgres as well on your CI. While it's perfectly reasonable for your
developers to not be needing the extra complication of installing
additional databases etc, I see no reason why you shouldn't be checking
everything works on the main production databases. This is similar to the
contribution story for Django.

Given that your travis builds currently run in under 40 seconds, I don't
think their speed on postgres will be problematic for your pull requests
etc.

I would probably have the motivation to create a PR for DRF showing a
possible travis/testing setup for what I have proposed.

Marc

Aside: In my opinion, a third party app that does significant database work
should be testing with the same database(s) as its users are likely to use
in production.

On 5 February 2015 at 10:00, Tom Christie  wrote:

> I'm not sure if there'll be an actionable outcome of this, but wanted to
> raise it for discussion.
>
> We've started supporting some of the PostgreSQL specific fields in Django
> REST framework, and I ran into a roadblock when adding a new testcase.
> Unsurprisingly we're not able to test them without also switching the test
> database to PostgreSQL.
>
> As a third party app that's not something I want to have to do - it'd mean
> a bunch of work, an extra dependency, slower tests, and (unacceptablly)
> more complication for our contributors.
>
> The only way I can see to resolve it would be if we had support for those
> fields with the sqlite backend.
> Technically I assume that's feasible - use JSON encoding for storing the
> data (probably easy), and do awfully non-optimal in-memory filtering for
> the field-specific lookups (probably very hard).
> There'd also be the obstacle requiring someone with the time and
> motivation to make it happen.
>
> Options I can see:
>
> * The status quo - don't support fields these in SQLite. (I assume this is
> by far the most likely.)
> * Support the fields in SQLite, but don't support the lookups. (This'd
> actually hit the sweet spot for me - I can still test against these fields,
> and test cases will run just fine, so long as you're not hitting any field
> specific fitlering in querysets.)
> * Support the fields and lookups in SQLite. (Sounds highly unlikely.)
>
> Any thoughts?
>
> Cheers!
>
>Tom
>
>
> Aside: I'm not interested in the "you should be testing with the same
> database as you use in production" gumpf here. It's a third party app.
>
>  --
> 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 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.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/f08447af-395c-4fb0-9f01-d2af3b4b8504%40googlegroups.com
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>

-- 
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 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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAMwjO1EyVFTBxPP4sMQbPbR_Bb-O4Y12xOSocD1FE-zrDF6okQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: discontinue shipping tests with contrib apps?

[Marc Tamlyn]

+1 to removing tests from contrib itself, so long as they remain obviously
separated in the test section in case of future removals from core.

On 9 February 2015 at 15:44, Preston Timmons 
wrote:

> I think the "need" is mainly conceptual--whether tests are more
> appropriately grouped with their app or with the other tests. With the
> discover runner it's uncommon that contrib tests are included in any local
> test runs.
>
> I do prefer moving all tests into the tests directory. The logic to get
> test_modules in runtests.py would be simplified quite a bit from it.
>
>
>  --
> 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 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.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/ba79f1b9-678e-4fdf-8f7a-26319e5ac4d3%40googlegroups.com
> 
> .
>
> For more options, visit https://groups.google.com/d/optout.
>

-- 
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 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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAMwjO1EJWzd0G0noSAHFL3ZsOP9kc6He6%2Bb1a5%3DAe3KhxBBfVg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Relations to non-trivial fields

[Marc Tamlyn]

This issue is that the foreign key field (i.e. the foo_id field) does not
have its db_converters called, if they are defined in the backend rather
than in the field itself.

I've added a pull request (https://github.com/django/django/pull/4134) with
a possible approach to the problem. We may be able to do something better,
I'm going to investigate further.

Marc

On 14 February 2015 at 19:13, Collin Anderson  wrote:

> Long term, eventually we want the FK to use a real models.UUIDField under
> the hood, right?
>
> On Sat, Feb 14, 2015 at 1:17 PM, Shai Berger  wrote:
>
>> Hi all,
>>
>> This comes from trying to fix #24343[1] -- a problem where a UUIDField is
>> used
>> as a PK (legitimate and common practice), and we wish to test a FK to that
>> model. The problem is that, on database backends which do not support
>> native
>> UUIDFields (that is, all but postgres), the underlying field for an FK is
>> a
>> CharField, not a UUIDField. This is not a problem in most normal use, but
>> sometimes people do access the underlying field, and they're in for a
>> surprise
>> there.
>>
>> I am almost certain that a similar problem exists with any non-trivial
>> field --
>> e.g. if someone had reason to use a CommaSeparatedIntField as a PK, they
>> would
>> probably run into the same issue.
>>
>> Now, there are two essential ways to fix the test failure in the ticket:
>> One,
>> as suggested by Tim in a comment on the ticket, is to just deal with the
>> difference in the test. The other is to solve the deeper issue, which
>> could be
>> seen as a little disruptive at this point in the release cycle (and is, in
>> general, more disruptive).
>>
>> Note that, as Tim notes on the ticket, the test failure is Oracle only,
>> but
>> the real issue is everyone-but-postgres.
>>
>> Opinions?
>>
>> Thanks,
>> Shai.
>>
>> [1] https://code.djangoproject.com/ticket/24343
>>
>
>  --
> 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 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.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/CAFO84S4CF_qo%2BMmJ1ybUsOMfD%3DPTyVxQZy8wD3vYKC6rE5%3DDwQ%40mail.gmail.com
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>

-- 
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 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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAMwjO1Gfw8Y5rdwjPbo2todKubtHVAU%2B%3DoePp3s6UDxw%3D-NpKQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Psycopg2 version support

[Marc Tamlyn]

Hi all,

Related ticket - https://code.djangoproject.com/ticket/24335

Django 1.8 will necessarily be the first version with a true minimum
requirement on psycopg2 version. Historically we have never documented a
required version.

- The new UUIDField requires at least 2.0.9
- Some code which is currently contained in the backend, not in
contrib.postgres, but I think only relates to arrays of
(Generic)IPAddressFields requires 2.4.5. As yet I have not tried moving
this compat code so it only runs if contrib.postgres installed.
- Range fields (in contrib.postgres) require 2.5
- There may be other things I'm not responsible for I don't know about,
with different version requirements.

Release history for psycopg2:
- 2.0.9 is extremely old (date unknown)
- 2.4.5 was released in March 2012
- 2.5 was released in April 2013
- 2.6 was released this month (Feb 2015)

According to Claude, some distros have a python-psycopg2 package which is
still on 2.4.5 (or maybe older?).

We have several options:
- Ensure as much as possible works with old versions of psycopg2 by
shuffling code around and/or using conditional imports.
- Making sure everything *outside contrib* doesn't require newer psycopg2
that 2.0.9, and making contrib.postgres require 2.5. This may not be
possible, but I think it should be.
- Change nothing but docs, so outside contrib requires 2.4.5,
contrib.postgres requires 2.5.
- Just document that Django 1.8+ needs psycopg2 2.5 (pip install it...)

The latter would be my preferred option, but then I've never understood the
argument for distro packages instead of pip. In any case, I feel that any
distro not supporting a two year old version of psycopg2 is unlikely to be
distributing a brand new version of Django.

As far as I know we have no official policy on dependencies like this (we
don't have many).

Marc

-- 
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 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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAMwjO1EMgWZD3d%2B96E7KP7Ou9KumkOXuSJaxO87%2BQa%3Dqt7gp%3Dg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Drop the TEMPLATE_DEBUG setting

[Marc Tamlyn]

+1 to removing it
On 15 Feb 2015 14:16, "Aymeric Augustin" 
wrote:

> Hello,
>
> During the multiple template engines refactor, I didn’t touch
> TEMPLATE_DEBUG.
> The only purpose of this setting is to control whether Django stores the
> information required to display stack traces for exceptions that occur
> while
> rendering Django templatse. I think I should have deprecated it for the
> following reasons.
>
> 1) Having the debug option of Django template engines default to DEBUG
> instead
> of TEMPLATE_DEBUG will allow everyone to remove TEMPLATE_DEBUG = DEBUG from
> their settings.
>
> 2) For the uncommon situation where one needs TEMPLATE_DEBUG != DEBUG, the
> new
> TEMPLATES settings provides a solution:
>
> TEMPLATES = [
> {
> 'BACKEND': 'django.template.backends.django.DjangoTemplates',
> 'OPTIONS': {
> 'debug': True,
> },
> },
> ]
>
> There should be only one way to do it and TEMPLATES beats TEMPLATE_DEBUG.
>
> 3) That will save developers of third-party backends from thinking about
> the
> semantics of TEMPLATE_DEBUG vs. DEBUG. At best it's a pointless exercise
> and
> at worst it will introduce inconsistencies. For example the maintainer of
> django-jinja is about to diverge from Django in this regard:
> https://github.com/niwibe/django-jinja/issues/87
>
> I would like to update the DEP and make this change in Django 1.8 beta.
>
> What do you think?
>
> --
> Aymeric.
>
>
>  --
> 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 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.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/45CFE41A-16D5-4A6B-AF27-505C3E4BEA75%40polytechnique.org
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>

-- 
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 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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAMwjO1EaJQpsj4qitLyf0Ah77Fs_8_yFpbdJn%3DV8JwphUEvt4g%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Support for DATABASES['default'] = {}

[Marc Tamlyn]

It would seem more sensible to me to try to support DATABASES={}. There's
no reason why a Django site should have to run a database - a microservice
using redis or something similar is perfectly reasonable and you could want
to use Django for other reasons (e.g. shared templates).

Marc

On 24 February 2015 at 13:38, Marten Kenbeek  wrote:

> With recent bug reports (#24332
> , #24298
>  and now #24394
> ) all caused by setting
> `DATABASES['default'] = {}`, this makes me wonder if it should be supported
> at all.
> The documentation states:
>
> The DATABASES
>>  
>> setting
>> must configure a default database; any number of additional databases
>> may also be specified.[1]
>
>
> And indeed, if default is not set at all, an error is raised. If default
> does not provide valid database settings, it is set to use
> `django.db.backends.dummy`. This will raise a `NotImplementedError` as soon
> as it is used, but it seems you can work around this quite well and ensure
> that `default` is barely used. The exceptions to this are reported in the
> mentioned bug reports, most notably `manage.py test` uses the `default`
> database.
>
> Should the documentation be clarified that it not only requires `default`
> to be set, but that it requires a valid database configuration as well? Or
> should an empty `default` configuration be valid?
>
> In #24332 and #24398, both fixed now, there was the additional issue that
> the code was simply not using the database is was supposed to use.
>
> I think this mostly boils down to whether we want the `test` command to
> support an explicit non-default database, you should be able to manipulate
> all other code to only use non-default databases, save some similar bugs
> that might still be present. This would reduce `default` to simple
> semantics and would probably warrant that it is no longer required if you
> supply an otherwise valid database configuration. However, I don't see any
> drawbacks to requiring a valid database setup. At most this would require
> developers to copy the credentials from the database they are actually
> using to the `default` setting, but it would also be an incentive to
> actually use `default` as the default database.
>
> [1]  https://docs.djangoproject.com/en/dev/ref/settings/#databases
>
> --
> 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 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.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/756eefc2-1baf-4898-91bf-86d378a27b04%40googlegroups.com
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>

-- 
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 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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAMwjO1Eo3Z8Mt14FyNJcN0Tdo0%3DNefqYwoiFJGZEp4WSg26Wnw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Support for DATABASES['default'] = {}

[Marc Tamlyn]

In that case your proposal sounds perfectly reasonable.

On 24 February 2015 at 13:47, Marten Kenbeek  wrote:

> In fact, DATABASES={} is a valid configuration and merely sets 'default'
> as a dummy backend. An exception is only explicitly raised if you supply a
> non-empty setting that does not include `default`.
>
> On Tuesday, February 24, 2015 at 2:43:51 PM UTC+1, Marc Tamlyn wrote:
>>
>> It would seem more sensible to me to try to support DATABASES={}. There's
>> no reason why a Django site should have to run a database - a microservice
>> using redis or something similar is perfectly reasonable and you could want
>> to use Django for other reasons (e.g. shared templates).
>>
>> Marc
>>
>> On 24 February 2015 at 13:38, Marten Kenbeek  wrote:
>>
>>> With recent bug reports (#24332
>>> <https://code.djangoproject.com/ticket/24332>, #24298
>>> <https://code.djangoproject.com/ticket/24298> and now #24394
>>> <https://code.djangoproject.com/ticket/24394>) all caused by setting
>>> `DATABASES['default'] = {}`, this makes me wonder if it should be supported
>>> at all.
>>> The documentation states:
>>>
>>> The DATABASES
>>>> <https://docs.djangoproject.com/en/dev/ref/settings/#std:setting-DATABASES>
>>>>  setting
>>>> must configure a default database; any number of additional databases
>>>> may also be specified.[1]
>>>
>>>
>>> And indeed, if default is not set at all, an error is raised. If default
>>> does not provide valid database settings, it is set to use
>>> `django.db.backends.dummy`. This will raise a `NotImplementedError` as soon
>>> as it is used, but it seems you can work around this quite well and ensure
>>> that `default` is barely used. The exceptions to this are reported in the
>>> mentioned bug reports, most notably `manage.py test` uses the `default`
>>> database.
>>>
>>> Should the documentation be clarified that it not only requires
>>> `default` to be set, but that it requires a valid database configuration as
>>> well? Or should an empty `default` configuration be valid?
>>>
>>> In #24332 and #24398, both fixed now, there was the additional issue
>>> that the code was simply not using the database is was supposed to use.
>>>
>>> I think this mostly boils down to whether we want the `test` command to
>>> support an explicit non-default database, you should be able to manipulate
>>> all other code to only use non-default databases, save some similar bugs
>>> that might still be present. This would reduce `default` to simple
>>> semantics and would probably warrant that it is no longer required if you
>>> supply an otherwise valid database configuration. However, I don't see any
>>> drawbacks to requiring a valid database setup. At most this would require
>>> developers to copy the credentials from the database they are actually
>>> using to the `default` setting, but it would also be an incentive to
>>> actually use `default` as the default database.
>>>
>>> [1]  https://docs.djangoproject.com/en/dev/ref/settings/#databases
>>>
>>> --
>>> 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 it, send
>>> an email to django-develop...@googlegroups.com.
>>> To post to this group, send email to django-d...@googlegroups.com.
>>> Visit this group at http://groups.google.com/group/django-developers.
>>> To view this discussion on the web visit https://groups.google.com/d/
>>> msgid/django-developers/756eefc2-1baf-4898-91bf-
>>> 86d378a27b04%40googlegroups.com
>>> <https://groups.google.com/d/msgid/django-developers/756eefc2-1baf-4898-91bf-86d378a27b04%40googlegroups.com?utm_medium=email&utm_source=footer>
>>> .
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>>
>>  --
> 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 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.
> To view this discussion on the web visit

Re: Support for DATABASES['default'] = {}

[Marc Tamlyn]

I can't see why it is sensible to support an invalid database configuration
as the default. If you explicitly want the default to be a dummy, you
should configure that IMO.

On 24 February 2015 at 14:04, Marten Kenbeek  wrote:

> Which one? :P This was more intended as a question than as a proposal.
>
> I personally prefer a documentation change and strict checking of
> `default` if and only if the database configuration is not empty.
> django.db.connection relies on the default connection, and third-party apps
> which (intentionally or unintentionally) do not support multi-db setups
> might be using that. I can't think of a scenario where it hurts to have a
> default database. I'm easily swayed on this matter, though.
>
> On Tuesday, February 24, 2015 at 2:52:47 PM UTC+1, Marc Tamlyn wrote:
>>
>> In that case your proposal sounds perfectly reasonable.
>>
>> On 24 February 2015 at 13:47, Marten Kenbeek  wrote:
>>
>>> In fact, DATABASES={} is a valid configuration and merely sets 'default'
>>> as a dummy backend. An exception is only explicitly raised if you supply a
>>> non-empty setting that does not include `default`.
>>>
>>> On Tuesday, February 24, 2015 at 2:43:51 PM UTC+1, Marc Tamlyn wrote:
>>>>
>>>> It would seem more sensible to me to try to support DATABASES={}.
>>>> There's no reason why a Django site should have to run a database - a
>>>> microservice using redis or something similar is perfectly reasonable and
>>>> you could want to use Django for other reasons (e.g. shared templates).
>>>>
>>>> Marc
>>>>
>>>> On 24 February 2015 at 13:38, Marten Kenbeek 
>>>> wrote:
>>>>
>>>>> With recent bug reports (#24332
>>>>> <https://code.djangoproject.com/ticket/24332>, #24298
>>>>> <https://code.djangoproject.com/ticket/24298> and now #24394
>>>>> <https://code.djangoproject.com/ticket/24394>) all caused by setting
>>>>> `DATABASES['default'] = {}`, this makes me wonder if it should be 
>>>>> supported
>>>>> at all.
>>>>> The documentation states:
>>>>>
>>>>> The DATABASES
>>>>>> <https://docs.djangoproject.com/en/dev/ref/settings/#std:setting-DATABASES>
>>>>>>  setting
>>>>>> must configure a default database; any number of additional
>>>>>> databases may also be specified.[1]
>>>>>
>>>>>
>>>>> And indeed, if default is not set at all, an error is raised. If
>>>>> default does not provide valid database settings, it is set to use
>>>>> `django.db.backends.dummy`. This will raise a `NotImplementedError` as 
>>>>> soon
>>>>> as it is used, but it seems you can work around this quite well and ensure
>>>>> that `default` is barely used. The exceptions to this are reported in the
>>>>> mentioned bug reports, most notably `manage.py test` uses the `default`
>>>>> database.
>>>>>
>>>>> Should the documentation be clarified that it not only requires
>>>>> `default` to be set, but that it requires a valid database configuration 
>>>>> as
>>>>> well? Or should an empty `default` configuration be valid?
>>>>>
>>>>> In #24332 and #24398, both fixed now, there was the additional issue
>>>>> that the code was simply not using the database is was supposed to use.
>>>>>
>>>>> I think this mostly boils down to whether we want the `test` command
>>>>> to support an explicit non-default database, you should be able to
>>>>> manipulate all other code to only use non-default databases, save some
>>>>> similar bugs that might still be present. This would reduce `default` to
>>>>> simple semantics and would probably warrant that it is no longer required
>>>>> if you supply an otherwise valid database configuration. However, I don't
>>>>> see any drawbacks to requiring a valid database setup. At most this would
>>>>> require developers to copy the credentials from the database they are
>>>>> actually using to the `default` setting, but it would also be an incentive
>>>>> to actually use `default` as the default database.
>>>>>
>>>>> [1]  https://docs.djangoproject.com/en/dev/ref/settings/#databases
>>>>>
>>>>> --
&g

Re: django admin: open popups as modals instead of windows

[Marc Tamlyn]

I would suggest that a good modal implementation for these should still
support "open in new tab/window" properly, with control/command click not
detected by the overriding JavaScript. It may be possible to do this and
keep the popup functionality passing the new id back to the parent window.

>From a UX perspective, I have heard[citation needed] that modal windows are
not ideal, mainly due to their blocking nature. However inline ajax loaded
windows are much better. For "small" parent form objects, this would likely
be ideal - click the plus icon, it reveals a 3-4 field inline form, fill
that in or cancel it, by choosing an option from the dropdown etc. This
concept of an inline parent form would be generally useful, I've written a
few limited implementations but never had the time to consider all the edge
cases to make a third party project.

There are definitely better ways to deal with raw_id_fields than the popup
window in my opinion - utilising something like select2 with ajax loading
and a hook on the ModelAdmin would be ideal.

In any case, it is fairly trivial to add options like this to the
modeladmin and make them opt in if that is desired.

Overall, I'm probably -0 on morals, but +1 on supporting an optional
alternative way to handle add buttons on related objects.

Marc
On 24 Feb 2015 16:41, "Stan"  wrote:

>
> On Tuesday, February 24, 2015 at 4:18:36 PM UTC+1, Florian Apolloner wrote:
>>
>>
>>
>> On Tuesday, February 24, 2015 at 3:23:23 PM UTC+1, riccardo.magliocchetti
>> wrote:
>>>
>>> I'm no UI/UX expert but modals are more or less the standard today,
>>> windows looks like a relic from the 2000s.
>>>
>>
>> That argument is based on what? I'd personally argue that windows are
>> superior cause I can easily switch between the page and the window --
>> something that does not work with modals
>>
>>
>>
> As the "helpdesk guy" for applications we develop and a "power-user" of
> Django admin, I strongly agree with Florian here.
> The ability to open and switch to other tabs in the main window - which is
> not possible with modals, right ? - and to resize/move/scroll the popup
> window with native performance beats fancy modal windows IMHO.
>
> --
> Stan
>
>
>
> --
> 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 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.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/8d65957b-6e57-4b7a-a8b1-7ce3a2ee8a18%40googlegroups.com
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>

-- 
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 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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAMwjO1FOs-%2BtH6hm3OcKf%2B%3DU1%2BdG1%2B1rX%2BNO5rDU7UnUOwUY3w%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: enum fields in django

[Marc Tamlyn]

I kinda like the idea of enum fields, but I feel they are likely better in
theory than in practice. In theory I said I would introduce one as part of
contrib.postgres, but I've been putting it off as I'm unconvinced whether
it is necessarily ideal anyway when compared to choices or reference tables.

Database support: PG, MySQL and Oracle all have enum data types. However
postgres does treat them somewhat differently, requiring you to explicitly
create a new type allowing the same enum type to be used across multiple
tables. Which paradigm should we follow in migrations?

Python support: This isn't a major issue as some other "core" features like
timezones require third party packages (pytz), but we are still requiring
an external package for python < 3.4. *SAY NO TO VENDORING!* It's also
worth noting it's a relatively new python level concept and there may be
changes to it.

Ordering: I'm a little uncomfortable with the idea that you can do
.order_by('my_enum_field') but you can't do sorted(qs, key=lambda o:
o.my_enum_field), unless you use IntEnum, which the docs say you shouldn't.

Migration issues: Postgres does not support removing values from enum
fields, although has good support for adding values. I'm not sure Oracle
supports changing enums at all, and on MySQL changing the enum is an ill
defined process with some unexpected consequences (inevitably...), which is
also extremely slow. Obviously we have no such guarantee about anything
when using choices at the moment, however with an automatic migration
system associated to enums developers are likely to assume more
intelligence than is present. We go to great pains in db.migrations at the
moment to ensure this.

Philosophy: Like with choices, there are arguments against using enum at
all in favour of using reference tables. The most obvious of these being
the ability to add extra information to a reference table. On the other
side however, by allowing the right hand side of the enum in python to be
arbitrary objects (classes or something) then you can nicely encapsulate
the a bunch of extra information. For example consider a competition model
where there 3 or 4 different ways of working out the winner, then having an
enum with classes where you can do competition.winner_type.get_winner().
This functional call may need additional context.

Overall, I'm hovering around a -0 on a general implementation of EnumField
or similar. However, I'm +0 on either a) a good third party implementation
or b) a contrib.postgres specific implementation with well documented
caveats. An advantage of living in contrib.postgres is that you don't need
to concern yourself with automatic migrations, and contrib can have a more
lenient policy on external packages. You also get a guaranteed review (me!).

Marc

On 26 February 2015 at 02:53, Thomas Stephenson  wrote:

> As discussed in Issue 24342 ,
> I've got an implementation of EnumField that we've found useful when
> developing our django REST API that I'd like to add to django core. It was
> suggested I bring this issue up in the developers mailing list for
> discussion. Unfortunately, updates to the issue were delivered to my spam
> folder, so there has been some delay in actually raising the issue.
>
> Basically, the implementation consists of a new field type, and a new
> migration operation (to register the values associated with an enum type).
> The field takes an `enum_type` argument and registers a type with values
> taken from the enum value names. The actual values associated with the
> names are ignored, so support for IntEnum and other enum types comes as
> standard.
>
> In a real implementation, the enum type would have to be checked when
> running migrations to ensure that values haven't been added/removed from
> the python class. It's not something that we've needed to deal with in our
> in-house implementation.
>
> Any database which does not support an enum field natively would default
> to a CharField implementation.
>
> Useful addition? Or does it overlap too much with the choices API?
>
> Thomas
>
>  --
> 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 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.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/59072aa1-7e7a-4fcf-8dd1-effde66675c6%40googlegroups.com
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups 
"Dj

Re: enum fields in django

[Marc Tamlyn]

e dataset (eg. custom application
>> error code tables)), but when the dataset _is_ known in advance an
>> enum will save you a couple of joins per table lookup.
>>
>>
>> It depends what you guys want to do. I'm happy to put in the work to
>> make the implementation generic, but I'm not going to push for you
>> guys to implement something you don't want or don't think provides
>> real value for users. Contributing to contrib.postgres is a possible
>> option, but it's not really a postgres specific feature -- almost all
>> of the major database vendors support it (sqlite being as always the
>> obvious exception).
>>
>> Thomas
>>
>> On 26 February 2015 at 21:26, Marc Tamlyn  wrote:
>> > I kinda like the idea of enum fields, but I feel they are likely better
>> in
>> > theory than in practice. In theory I said I would introduce one as part
>> of
>> > contrib.postgres, but I've been putting it off as I'm unconvinced
>> whether it
>> > is necessarily ideal anyway when compared to choices or reference
>> tables.
>> >
>> > Database support: PG, MySQL and Oracle all have enum data types.
>> However
>> > postgres does treat them somewhat differently, requiring you to
>> explicitly
>> > create a new type allowing the same enum type to be used across
>> multiple
>> > tables. Which paradigm should we follow in migrations?
>> >
>> > Python support: This isn't a major issue as some other "core" features
>> like
>> > timezones require third party packages (pytz), but we are still
>> requiring an
>> > external package for python < 3.4. SAY NO TO VENDORING! It's also worth
>> > noting it's a relatively new python level concept and there may be
>> changes
>> > to it.
>> >
>> > Ordering: I'm a little uncomfortable with the idea that you can do
>> > .order_by('my_enum_field') but you can't do sorted(qs, key=lambda o:
>> > o.my_enum_field), unless you use IntEnum, which the docs say you
>> shouldn't.
>> >
>> > Migration issues: Postgres does not support removing values from enum
>> > fields, although has good support for adding values. I'm not sure
>> Oracle
>> > supports changing enums at all, and on MySQL changing the enum is an
>> ill
>> > defined process with some unexpected consequences (inevitably...),
>> which is
>> > also extremely slow. Obviously we have no such guarantee about anything
>> when
>> > using choices at the moment, however with an automatic migration system
>> > associated to enums developers are likely to assume more intelligence
>> than
>> > is present. We go to great pains in db.migrations at the moment to
>> ensure
>> > this.
>> >
>> > Philosophy: Like with choices, there are arguments against using enum
>> at all
>> > in favour of using reference tables. The most obvious of these being
>> the
>> > ability to add extra information to a reference table. On the other
>> side
>> > however, by allowing the right hand side of the enum in python to be
>> > arbitrary objects (classes or something) then you can nicely
>> encapsulate the
>> > a bunch of extra information. For example consider a competition model
>> where
>> > there 3 or 4 different ways of working out the winner, then having an
>> enum
>> > with classes where you can do competition.winner_type.get_winner().
>> This
>> > functional call may need additional context.
>> >
>> > Overall, I'm hovering around a -0 on a general implementation of
>> EnumField
>> > or similar. However, I'm +0 on either a) a good third party
>> implementation
>> > or b) a contrib.postgres specific implementation with well documented
>> > caveats. An advantage of living in contrib.postgres is that you don't
>> need
>> > to concern yourself with automatic migrations, and contrib can have a
>> more
>> > lenient policy on external packages. You also get a guaranteed review
>> (me!).
>> >
>> > Marc
>> >
>> > On 26 February 2015 at 02:53, Thomas Stephenson 
>> wrote:
>> >>
>> >> As discussed in Issue 24342, I've got an implementation of EnumField
>> that
>> >> we've found useful when developing our django REST API that I'd like
>> to add
>> >> to django core. It was suggested I bring this issue

Re: Extending the URL Dispatcher (GSoC 2015 proposal)

[Marc Tamlyn]

A collection of thoughts:

I think allowing the url dispatcher to inspect the database for the
existence of certain objects is potentially somewhat dangerous. However,
good support for a view raising a "continue resolving" exception along the
lines of https://github.com/jacobian-archive/django-multiurl might be
interesting. Related to this, a check for potentially conflicting url
mappings could be interesting.

Middleware currently has complex and unintuitive behaviour in the event of
exceptions. You talk about the middleware/decorator split, but not how to
make either make sense.

Supporting generic sets of views has some logic, although in my experience
it is extremely rare that you can sensibly use a generic view with no
alterations at all - it almost always needs extra context or some other
tweaks. I'm not really convinced that a one liner to get CRUD for a
particular model will actually be that useful in the wild - you're likely
to end up changing too many things. I don't find the "one line in a urlconf
for each view" convention to be particularly problematic, however writing
all the regexes is potentially more prone to problems.

If you are intending on introducing alternative URL resolvers, some example
ideas would be needed. The lack of a consistent way to reverse a slug for
example is a good idea to address, but we need to establish how.

How are you intending to support different resolvers in the same project?
It seems to me that it is rather inefficient in large projects to loop
through all resolvers for all urls.

Namespacing urls is currently over complex for the 90% use case, and the
docs are hard to understand as a result. Alternative designs in this area
could be interesting.

Overall there are lots of interesting starts of ideas here, but I feel one
or two dead ends. It's a potentially very varied project and the crux of
the proposal needs to focus on ensuring that some specific tasks are well
designed and achievable, with others being extensions later on.

Marc

On 2 March 2015 at 17:14, Tim Graham  wrote:

> Hi Marten,
>
> I think it would be helpful to motivate this with some pseudocode of
> specific use cases you are aiming to solve. Have you looked into whether
> there are any related third-party projects related to your ideas from which
> you could draw inspiration?
>
> Tim
>
>
> On Monday, March 2, 2015 at 11:57:24 AM UTC-5, Marten Kenbeek wrote:
>>
>> Hey all,
>>
>> I'm working on a proposal to extend the URL dispatcher. Here, I'd like to
>> provide a quick overview of the features I propose.
>>
>> I'd like to:
>> - Allow matching based on request attributes such as the subdomain or
>> protocol, and business logic such as the existence of a database object.
>> - Make middleware configurable for a subset of views. It should be easy
>> to add, reorder or replace middleware at any level in the (currently
>> recursive) matching algorithm.
>> - Provide conventions for common patterns, such as an easy-to-configure
>> URL router for all generic Model views. For generic views, this should be a
>> one-liner. For custom views and other non-default options, this should
>> still be relatively easy to configure compared to writing out all patterns.
>>
>> In the process, I'd like to formalize some classes used in the
>> dispatcher. Currently, the RegexURLPattern and RegexURLResolver classes
>> provide most of the functionality of the URL dispatcher. By abstracting
>> these classes, and factoring out the loading mechanism and some other
>> internals, I hope to provide an extensible dispatching framework for
>> third-party apps.
>>
>> The full, yet incomplete proposal can be found at
>> https://gist.github.com/knbk/325d415baa92094f1e93 if you want more
>> details. It currently contains a slightly more in-depth discussion of the
>> current dispatcher and the proposed features, and a start on the redesign
>> of the dispatcher.
>>
>> I'm mostly looking for some feedback on the general direction of these
>> features, though any feedback is welcome. I'm still working on it, so
>> details might change based on new insights.
>>
>> Thanks,
>> Marten
>>
>  --
> 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 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.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/34ebf9ed-9961-4b33-9f49-5e6a4f9c6469%40googlegroups.com
> 
> .
>
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google G

Re: Suggestion: add default "registration/login.html" to django.contrib.auth

[Marc Tamlyn]

I can see the merit of including our documented example as an actual
template as a starting point. It's unlikely to be used exactly as is very
often but it reduces getting started friction for some users - "huh this
view doesn't work, better go read the docs"

I'd perhaps be inclined to include it without styles even.

Marc

On 3 March 2015 at 14:22, Ilya Kazakevich  wrote:

> I do not think admin templates should used. But something very simple and
> dumb (that looks similar to browser HTTP auth window). Here is example:
> http://pastebin.com/nnX36RB6
> Css should be moved to static files, of course, to make this template
> cleaner and slightly more customizable.
>
> Imagine I need to create working solution as fast as I can. I really do
> not care about good UI now, because I need only a prototype to show it to
> my customer. I will not spent time creating nice login page: I just simply
> copy/paste template from Django documentation. And login page from contrib
> is great aid here. I will probably change login page UI later, but it is
> minor issue and priority is low. Many people in Intranet solutions
> (portals, CRMs and so on) are happy with browser HTTP auth window. They
> really do not care about how ugly is it.
>
>
>
>
> On Tuesday, March 3, 2015 at 4:36:52 PM UTC+3, Tim Graham wrote:
>>
>> The admin templates extend "admin/base_site.html" and rely on the
>> presence of specific template blocks so I don't think it's appropriate for
>> those dependencies to be added to contrib.auth. I'm curious to see what
>> content you would propose for a default template. Typically I've seen login
>> templates that extend from a project's base template so it inherits all the
>> project specific styles, JavaScript, etc. I'm not sure a default template
>> would actually be used much in practice.
>>
>> On Tuesday, March 3, 2015 at 8:18:39 AM UTC-5, Tino de Bruijn wrote:
>>>
>>> Yeah, or default to admin/login.html. The admin ships with all necessary
>>> "registration" templates, but for some reason only the login.html is
>>> included in the admin directory.
>>>
>>> On Tue, Mar 3, 2015 at 2:05 PM, Ilya Kazakevich 
>>> wrote:
>>>
 Hello,

 When I use Django auth, I need to provide login.html myself. But Django
 encourages applications to have default templates which can be overwritten
 by user (via filesystem.Loader, for example).
 I suggest to provide default login.html with simple HTML form. User may
 always overwrite it.

 --
 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 it, send
 an email to django-develop...@googlegroups.com.
 To post to this group, send email to django-d...@googlegroups.com.
 Visit this group at http://groups.google.com/group/django-developers.
 To view this discussion on the web visit https://groups.google.com/d/
 msgid/django-developers/9487d6c7-8ee2-4a64-aae6-
 9a05574c1464%40googlegroups.com
 
 .
 For more options, visit https://groups.google.com/d/optout.

>>>
>>>  --
> 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 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.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/aae4454c-7823-41cc-aaf2-914eb7b7c95f%40googlegroups.com
> 
> .
>
> For more options, visit https://groups.google.com/d/optout.
>

-- 
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 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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAMwjO1GiLB5igByW-F9JVpu0WicQ4G1nKsKYc-wjUenqE%3DG59w%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Suggestion: add default "registration/login.html" to django.contrib.auth

[Marc Tamlyn]

I believe we standardised priority order such that earlier in the list
always takes priority. Historically we had different orders for different
things (templates, template tags, static files etc).

In any case, I don't think this should be a blocker and I'm in favour of
including it as `registration/login.html`.

Ilya - You can find everything you need here:
https://docs.djangoproject.com/en/1.7/internals/contributing/new-contributors/

Marc

On 3 March 2015 at 18:16, Aymeric Augustin <
aymeric.augustin.2...@polytechnique.org> wrote:

> I agree: providing a default login template would help. Getting started
> with contrib apps should be as easy as possible.
>
> However the current proposal is backwards incompatible for users who
> define the login template in one of their apps that comes before
> django.contrib.auth in INSTALLED_APPS (if I remember the priority order
> correctly).
>
> I don't think that prevents us from making the change but it should be
> pointed out in the release notes.
>
> A more backwards-compatible alternative is to ship a default_login.html
> template and use select_template to fallback to that template when
> login.html isn't found.
>
> --
> Aymeric.
>
> Le 3 mars 2015 à 15:25, Marc Tamlyn  a écrit :
>
> I can see the merit of including our documented example as an actual
> template as a starting point. It's unlikely to be used exactly as is very
> often but it reduces getting started friction for some users - "huh this
> view doesn't work, better go read the docs"
>
> I'd perhaps be inclined to include it without styles even.
>
> Marc
>
> On 3 March 2015 at 14:22, Ilya Kazakevich 
> wrote:
>
>> I do not think admin templates should used. But something very simple and
>> dumb (that looks similar to browser HTTP auth window). Here is example:
>> http://pastebin.com/nnX36RB6
>> Css should be moved to static files, of course, to make this template
>> cleaner and slightly more customizable.
>>
>> Imagine I need to create working solution as fast as I can. I really do
>> not care about good UI now, because I need only a prototype to show it to
>> my customer. I will not spent time creating nice login page: I just simply
>> copy/paste template from Django documentation. And login page from contrib
>> is great aid here. I will probably change login page UI later, but it is
>> minor issue and priority is low. Many people in Intranet solutions
>> (portals, CRMs and so on) are happy with browser HTTP auth window. They
>> really do not care about how ugly is it.
>>
>>
>>
>>
>> On Tuesday, March 3, 2015 at 4:36:52 PM UTC+3, Tim Graham wrote:
>>>
>>> The admin templates extend "admin/base_site.html" and rely on the
>>> presence of specific template blocks so I don't think it's appropriate for
>>> those dependencies to be added to contrib.auth. I'm curious to see what
>>> content you would propose for a default template. Typically I've seen login
>>> templates that extend from a project's base template so it inherits all the
>>> project specific styles, JavaScript, etc. I'm not sure a default template
>>> would actually be used much in practice.
>>>
>>> On Tuesday, March 3, 2015 at 8:18:39 AM UTC-5, Tino de Bruijn wrote:
>>>>
>>>> Yeah, or default to admin/login.html. The admin ships with all
>>>> necessary "registration" templates, but for some reason only the login.html
>>>> is included in the admin directory.
>>>>
>>>> On Tue, Mar 3, 2015 at 2:05 PM, Ilya Kazakevich 
>>>> wrote:
>>>>
>>>>> Hello,
>>>>>
>>>>> When I use Django auth, I need to provide login.html myself. But
>>>>> Django encourages applications to have default templates which can be
>>>>> overwritten by user (via filesystem.Loader, for example).
>>>>> I suggest to provide default login.html with simple HTML form. User
>>>>> may always overwrite it.
>>>>>
>>>>> --
>>>>> 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 it, send
>>>>> an email to django-develop...@googlegroups.com.
>>>>> To post to this group, send email to django-d...@googlegroups.com.
>>>>> Visit this group at http://groups.google.com/group/django-developers.
>>>>

Re: Composite fields

[Marc Tamlyn]

I think `Model._meta` may well always want all the concrete underlying
fields included somehow, especially for migrations work. A possibility for
your external `MoneyField` could be to add other fields using
`contribute_to_class`, though this may be a bad idea...

On 5 March 2015 at 14:47, Thomas Stephenson  wrote:

>  > Turns out this was a bad idea, after around 1700 lines changed
> everything was broken and there were multiple hard to debug failures.
>
> Yeah, been in this situation too many times to count.
>
> > Split ForeignKey to a concrete field instance, and a related field
> instance. After this all related fields are purely virtual. This means that
> author = models.ForeignKey(Author) will automatically generate a author_id
> = IntegerField() on the model. Unfortunately this also means model._meta
> will now contains two fields for each foreign key defined on the model
> instead of just one.
>
> The foreign_key_id field could be a subfield of foreign key (then
> model._meta would not contain two entries for the foreign key).
> Unfortunately that would open the door to composite field inheritance, but
> it could be handled like enum inheritance is handled in python -- you can
> subclass as much as you want, but you can't declare additional fields on
> subclasses.
>
> If that happened, then composite foreign keys would be a lot easier (but
> still work that can be deferred).
>
> > Michal Petrucha did a lot of work to add composite fields to Django.
> The syntax he had was:
>
> I'm not exactly a fan of that syntax. It works for the unique_together and
> index_together use cases (and the primary key use case), but it puts all
> the subfields on model._meta and doesn't allow you encapsulate the
> behaviour of composite fields outside the model definition. So you can't,
> for example, define a reusable `MoneyField` that represents two columns in
> the target model.
>
>
> > The first part in the composite fields work should be making the point
> field example to work. This will mean supporting .filter(point__in=((1, 2),
> (2, 3))), and support for .values('point'). Both of these will be
> surprisingly complex to do correctly. In addition there will likely be a
> lot of work to do in other parts of Django, too (for example in
> migrations), so implementing just "simple" composite fields will be a lot
> of work.
>
> Well, I've already got that working (well, I've got point__exact working
> and I can add point__in easily enough, it's just a matter of adding the
> relevant lookup transformations to get_lookup_transform. There were some
> comments surrounding that function which suggest it needs a refactoring,
> but I don't think it does.
>
> Thomas
>
> On 5 March 2015 at 22:30, Anssi Kääriäinen  wrote:
>
>> I've started doing some refactorings to the fields/related.py. The
>> ultimate goal is to have field.rel (ForeignObjectRel) instances to be Field
>> subclasses.
>>
>> I first went ahead and did exactly this with the idea of changing
>> everything in one go. Turns out this was a bad idea, after around 1700
>> lines changed everything was broken and there were multiple hard to debug
>> failures.
>>
>> I did a fresh start, and my plan is now to do the following:
>>   - First, make ForeignObjectRel to act like a Field instance (part of
>> this is done in https://github.com/django/django/pull/4241)
>>   - Make ForeignObjectRel Field subclass. This will likely rename the
>> classes to something like ReverseForeignKey, ReverseManyToMany and so on.
>>   - Finally, add the new reverse field instances directly to the remote
>> model's _meta
>>
>> This is just clean-up in the fields/related.py. The composite fields work
>> doesn't need to rely on this. To get to a state where we have composite
>> primary keys and composite joins we should:
>>   - Split ForeignKey to a concrete field instance, and a related field
>> instance. After this all related fields are purely virtual. This means that
>> author = models.ForeignKey(Author) will automatically generate a author_id
>> = IntegerField() on the model. Unfortunately this also means model._meta
>> will now contains two fields for each foreign key defined on the model
>> instead of just one.
>>   - Add composite fields (but not yet composite foreign keys or primary
>> keys)
>>   - Add composite primary keys
>>   - Add composite foreign keys
>>
>> Addition of composite fields can be done at the same time with changes to
>> fields/related.py, so it should be possible to start working on composite
>> fields right away.
>>
>> Michal Petrucha did a lot of work to add composite fields to Django. The
>> syntax he had was:
>>
>> class MyModel(models.Model):
>> x = models.IntegerField()
>> y = models.IntegerField()
>> point = models.CompositeField(x, y)
>>
>> I think we should stick to that.
>>
>> It is essential that we don't try to do too much in one go. Even small
>> changes tend to be hard to do. Trying to do all this in one go will result
>> in a patch that will

Re: Adding an option on db_index to not create text/varchar_pattern_ops

[Marc Tamlyn]

I have some plans (see https://github.com/django/deps/pull/6) to rework
more widely how indexes are managed and allow finer control over them. It
pretty much includes all the things mentioned by Alex. I'm intending on
doing some work on it over the next few weeks.

Marc

On 20 March 2015 at 02:27, Alex Hill  wrote:

> I agree that this is a problem, and I'd like to see more control over
> indexes generally in Django.
>
> However, at first glance I suspect that fixing only your problem would
> mean adding special-case gunk to the Field class in addition to the
> Postgres schema editor where it currently lives[1]. It feels wrong to
> expand this special-casing when other types could benefit from having
> customisable indexes. For instance, the db_index parameter is useless for
> column types that don't work with a btree index, like jsonb and tsvector.
>
> To fix your immediate problem, can't you avoid creating the extra indexes
> by just setting db_index=False, and then use django-json-dbindex to define
> the indexes you DO want?
>
> I would like to see an index API that allowed Field subclasses to specify,
> per-backend, the indexes that should be created if db_index is True. Those
> defaults should be overridable by the user, perhaps by passing a sequence
> of some Index type as the db_index parameter instead of simply True or
> False.
>
> Not all indexes relate to a single field, so it would make sense to also
> be able to register indexes in a model's Meta as well. The Index type
> should be able to use Expressions to create functional and multi-column
> indexes.
>
> So, that's my wishlist. All that said if you can come up with a patch that
> fixes your problem in a sane way, great! :)
>
> Cheers,
> Alex
>
> [1]
> https://github.com/django/django/blob/35b3158d52a5fe51d3b52aec1109a30a73c5abe9/django/db/backends/postgresql_psycopg2/schema.py#L22
>
> On Friday, March 20, 2015 at 3:44:58 AM UTC+8, rodolphe.q...@novapost.fr
> wrote:
>>
>> As proposed by timgraham in https://code.djangoproject.com/ticket/24507
>> I open the discussion here.
>>
>> When adding db_index=True on a CharField Django automatically create 2
>> indexes on some backends as PostgreSQL. But in usage the second index is
>> not always necessary if you never use contains() or similar queries. As you
>> can see here I extracted indexes usages statistics from one of our
>> production server.
>>
>> The index *foo_bar_email_from_create_like* is never use even if
>> *foo_bar_email_from_create* is, and if we look on our queries this is
>> totally logic and regular. And it's the same for *foo_bar_tech_id* and
>> *foo_bar_user_type*, and it's the same on the other table.
>>
>> indexrelname  |  idx_scan  | idx_tup_read |
>> idx_tup_fetch
>> --++
>> --+--
>> foo_bar_address_like  |  0 |0 |
>> 0
>> foo_bar_current_profile_id|   1846 |  617 |
>>   236
>> foo_bar_date_delete   |  0 |0 |
>> 0
>> foo_bar_email_from_create |  31209 |90886 |
>> 21903
>> foo_bar_email_from_create_like|  0 |0 |
>> 0
>> foo_bar_entity_id |   8026 |28957 |
>>14
>> foo_bar_pkey  | 1258565593 |   1418841848 |
>> 1194873240
>> foo_bar_site_id   |4495829 |  51000840065 |
>>  3564
>> foo_bar_tech_id   |   25045160 | 28233693 |
>> 25087324
>> foo_bar_tech_id_like  |  0 |0 |
>> 0
>> foo_bar_user_type |  21428 |263769329 |
>> 216686751
>> foo_bar_user_type_like|  0 |0 |
>> 0
>> foo_bar_uuid_like |  0 |0 |
>> 0
>> foo_bar_uuid_uniq |   13134415 | 13157636 |
>> 12928178
>>
>> A last point is each index on this table is consumming more the 2Gb on
>> disk.
>>
>> Even if we can suppress the indexes, and this is what we do with (
>> https://github.com/novafloss/django-json-dbindex) on bigger one realy
>> problematic, we'd prefer to not create them.
>>
>> Thanks for your time and this wonderful project Django is.
>>
>  --
> 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 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.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/ad3c-dc43-498b-a9f3-382330bbedc2%40googlegroups.com
> 

Re: Two phase cleaning of models/forms

[Marc Tamlyn]

In particular it is worth noting the addition of form.add_error[1] in
Django 1.7 which makes long clean methods much nicer to handle.

[1]
https://docs.djangoproject.com/en/1.7/ref/forms/api/#django.forms.Form.add_error

On 25 March 2015 at 16:11, Carl Meyer  wrote:

> Hi Thomas,
>
> On 03/25/2015 03:37 AM, Thomas Güttler wrote:
> > Up to now the validation/cleaning of a attribute can not access the
> > value of an other attribute.
> >
> > The work around is to override the clean() method of the form/model.
> >
> > A team mate and I talked about it, and we asked ourself, if
> > a two phase cleaning would help here.
> >
> > Our idea:
> >
> >  - The first clean phase works like the current implementation
> >
> >  - The second clean phase is optional and does nothing except the user
> > implements it.
> >
> >  - In the second clean phase your are allowed to peek into
> >the results of the first clean phase.
> >The clean method for the second phase would need to get the other
> > values passed in.
> >
> >
> > I would like to have this on model level, not only for forms.
> >
> > Example:
> >
> > class Issue(models.Model):
> > state=models.CharField(choices=[('in_progress', 'In progress'),
> > ('wait_until_due_date', 'Wait until due date')])
> > due_date=models.DateField(null=True)
> >
> >
> > We want to implement this constraint:
> >
> >  - due date must be set, if the state is "wait_until_due_date".
> >  - due date must not be set, if state is different from
> > "wait_until_due_date".
> >
> > We know that we can use the clean() method of the model, but a field
> > based solution would
> > be more preferred.
>
> Why?
>
> > class Issue(models.Model):
> > state = models.CharField(choices=[('in_progress', 'In progress'),
> > ('wait_until_due_date', 'Wait until due date')])
> > due_date = models.DateField(null=True,
> > validators2=[check_state_and_due_date_match])
> >
> > def check_state_and_due_date_match(due_date, all_fields):
> > state = all_fields['state']
> > if due_date:
> > if state != 'wait_until_due_date':
> > raise ValidationError('If due date is set, state must be
> > "wait_until_due_date"')
> > return
> > if  state != 'wait_until_due_date':
> > raise  ValidationError('If no due date is set, state must be
> > "wait_until_due_date")
> >
> >
> > Open questions: I am unsure if this should be used only for validation,
> > or if it should be possible
> > to alter values, too.
> >
> > What do you think?
> >
> > Other solutions or improvements?
>
> I think this is unnecessary complexity to add to the validation process.
> There is nothing that this proposal makes possible that isn't already
> possible using the clean() method. In cases where the clean() method
> becomes too long or convoluted, you can break it up into smaller methods
> yourself.
>
> In fact, I would guess that your proposal could be entirely implemented
> on top of current Django, by overriding the clean() method to implement
> what you've outlined above.
>
> Carl
>
> --
> 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 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.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/5512DE42.8000800%40oddbird.net
> .
> For more options, visit https://groups.google.com/d/optout.
>

-- 
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 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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAMwjO1Gnhfp3XkOwEgaqhjbTBzGTxF3uv7-dgDF9drMCmt_%3Dhg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Pre-DEP: community support of unmaintained versions of Django

[Marc Tamlyn]

Sounds broadly good to me. I'd be happy for it to be pushed to pypi under
django-legacy or similar name.

Marc
On 27 Mar 2015 16:36, "Tim Graham"  wrote:

> Sounds good to me.
>
> On Friday, March 27, 2015 at 12:28:09 PM UTC-4, Carl Meyer wrote:
>>
>> Hi Christian,
>>
>> On 03/26/2015 05:11 PM, Christian Hammond wrote:
>> > I know you guys are still sorting out how you want to run this, but I
>> > wanted to let you know that, given our current dependence on Python
>> 2.6,
>> > I'm willing to do what's needed to maintain security backports for
>> > either an official or unofficial fork.
>> >
>> > I'd love to know some further thoughts on the logistics for this.
>> Things
>> > like how versioning would work, what you'd need from me, what kind of
>> > timeframes we'd have to work with, any legalese needed to be notified
>> of
>> > security issues, etc.
>>
>> Tim pointed you to the details for requesting security pre-notification.
>> We pre-notify a week in advance, so that's the timeframe you'd have
>> available to get a patch (or patches) prepped to apply to your fork.
>> Obviously we'd expect that you wouldn't push any patches to a public
>> fork until the embargo ends with our release announcement; you could
>> manage that by simply staging patches on a local machine, or by
>> coordinating patches during the embargo in a private GitHub repo.
>>
>> Carl
>>
>>  --
> 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 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.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/3eaf7467-90bc-41d6-b903-6b3198bd38d2%40googlegroups.com
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>

-- 
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 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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAMwjO1EizLpYtKMjrshPLn%3DspjuyjtnW04LwEH23v0NyJFckSg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Using AbstractBaseUser without django.contrib.auth

[Marc Tamlyn]

Moving them into another module won't make much difference as their
definition requires Permission and Group and therefore they'd still need to
import Permission and Group. We'd need an "AbstractAbstractBaseUser" which
would be silly.

Of course, there is no requirement to use AbstractBaseUser for your custom
model at all, though this does result in some otherwise unnecessary code
duplication. I would say your choice is either two empty tables in your
database, or code duplication between Django's source and your custom user.
Personally I'd prefer the former.

On 2 April 2015 at 07:09, Shai Berger  wrote:

> On Thursday 02 April 2015 05:50:04 Curtis Maloney wrote:
> > Does your model inherit from PermissionsMixin?
> >
> > If you're using Admin, or any of Django's permissions machinery, you will
> > need django.contrib.auth in there to use the Group and Permission models.
> >
>
> The problem is not with permissions; the problem is that you can't import
> AbstractBaseUser without importing the concrete Permission, Group and User
> models,  because they're all in the same module.
>
> > On 2 April 2015 at 13:47, Dan Watson wrote:
> >>
> >> /Users/dcwatson/Documents/Environments/reader/lib/python3.4/site-
> packages/django/contrib/auth/models.py:41:
> >> RemovedInDjango19Warning: Model class
> django.contrib.auth.models.Permission
> >> doesn't declare an explicit app_label and either isn't in an
> application in
> >> INSTALLED_APPS or else was imported before its application was loaded.
> This
> >> will no longer be supported in Django 1.9.
> >>   class Permission(models.Model):
> >>
> >> Same thing for User and Group.
>
> I am not sure what the proper fix should be; on one hand, you are using
> code
> from django.contib.auth, so it makes some sense to require it to be
> installed.
> On the other hand, that forces two redundant tables on you (Group and
> Permission are not swappable).
>
> Please do open a ticket -- my instinct is that django.contrib.auth will
> need
> to be installed, but the impact of installing it should be minimised.
>
> Shai.
>

-- 
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 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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAMwjO1E5-Fh9u%3Dh7yucyAcSz4TKBbWjvwVyjHv1FyPRN5NnhPQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Using AbstractBaseUser without django.contrib.auth

[Marc Tamlyn]

Apologies, I was confusing abstract base user and abstract user there.
Seems your proposal should work. Have you opened a ticket?

On 2 April 2015 at 14:28, Dan Watson  wrote:

> On Thursday, April 2, 2015 at 2:27:51 AM UTC-4, Marc Tamlyn wrote:
>>
>> Moving them into another module won't make much difference as their
>> definition requires Permission and Group and therefore they'd still need to
>> import Permission and Group. We'd need an "AbstractAbstractBaseUser" which
>> would be silly.
>>
>>
>  AbstractBaseUser doesn't require any models from contrib.auth (as opposed
> to AbstractUser, which inherits PermissionsMixin), and I'm fine with
> leaving PermissionsMixin in models.py since it does require Group and
> Permission.
>
> Of course, there is no requirement to use AbstractBaseUser for your custom
>> model at all, though this does result in some otherwise unnecessary code
>> duplication. I would say your choice is either two empty tables in your
>> database, or code duplication between Django's source and your custom user.
>> Personally I'd prefer the former.
>>
>
> Very true, but it seems like AbstractBaseUser was designed to be used by
> systems not wanting Django's permission structure. It's even documented[1]
> how to make AbstractBaseUser subclasses work with the admin. I can live
> with either wart (copying code or empty tables) if need be, just wanted to
> explore some alternatives. I'll open a ticket.
>
> [1]
> https://docs.djangoproject.com/en/1.8/topics/auth/customizing/#custom-users-and-django-contrib-admin
>
> --
> 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 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.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/297c3eb4-7832-424a-a269-4af471eae23a%40googlegroups.com
> <https://groups.google.com/d/msgid/django-developers/297c3eb4-7832-424a-a269-4af471eae23a%40googlegroups.com?utm_medium=email&utm_source=footer>
> .
>
> For more options, visit https://groups.google.com/d/optout.
>

-- 
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 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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAMwjO1FAdmDoOmH5Gh2O26Obwz879di9vodKCHu73hWKbZ53Kg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Fate of sql* management commands

[Marc Tamlyn]

As far as I'm aware, we have some code paths which still work in 1.9 which
generate tables directly from the models. We use this when running Django's
own test suite, and it is also used now by djangobench. I haven't looked
into exactly how to turn this into logged SQL rather than run SQL but it
should be possible.

I think we should document such a tool as a debugging tool rather than a
development tool, but it would be useful nonetheless. Something like
`sqlmigrate --from-clean` might be appropriate.

Marc
On 2 Apr 2015 21:50, "Aymeric Augustin" 
wrote:

> On 30 mars 2015, at 23:10, Carl Meyer  wrote:
>
> > So it is not true that the Python models are the canonical
> > representation of your schema, and the SQL DDL is just a translation of
> > them. In fact, your migrations are the (only) canonical representation
> > of your schema, which may include things (specialized indices, views,
> > SQL functions, triggers...) that don't have any direct representation in
> > the Python models at all. The Python models just need to be in-sync
> > enough to generate the correct SQL for queries at run-time, but they
> > often will not fully represent your schema.
>
> While I understand this argument in theory, I'm not sure we can stop there
> in
> practice. I know that anecdote != data but here's my story and what I
> think it
> means for Django.
>
> I started a moderately complex Django-based e-commerce project about one
> year
> ago. We switched to Django 1.7 right after it was released and went live a
> few
> days later. We made the most basic use of migrations: add a model here, run
> makemigrations, commit; change a field there, run makemigrations, commit.
>
> We did only one complicated thing. We moved our custom user model because
> of a
> circular import problem. (Pro-tip #1: put your custom user model in an app
> that doesn't depend on anything else. Perhaps we should document that.) We
> papered over the resulting mess by squashing migrations and life was good.
> (Pro-tip #2: if you change AUTH_USER_MODEL, throw your migrations history
> away
> and regenerate it. It's easy. We should definitely document how to do
> that.)
>
> A few weeks ago, we ran into issues I can't describe exactly when
> generating
> or applying new migrations. I'm sorry, I don't remember the details because
> I'm not monitoring development very closely. Judging by how much time had
> been
> spent on the issue and how messy it looked, I decided to simply scratch our
> migrations history, which we should have done earlier. (See pro-tip #2.)
>
> I wanted to check that the resulting schema matched what we had in
> production
> in order to make sure that I wouldn't introduce inconsistencies. On my
> machine, I emptied all migrations folders, ran makemigrations, created a
> fresh
> database, ran migrate, and dumped the schema. Then I grabbed a dump of the
> production schema. The dumps were about 11 000 lines long. The diff
> produced
> by apgdiff -- a great tool -- was 2 000 lines long.
>
> Much of the diff was noise created by non-deterministic index and
> constraint
> names. I'm almost sure we fixed that in 1.8. I hacked a script to
> renormalize
> hashes and was still left with significant differences. Oops.
>
> These differences happen when Django produces a different schema:
>
> - if you simply create a model
> - if you make a series of changes that result in the same model
>
> These differences appear not only when you reset migrations like I did, but
> also if you squash migrations, since the squashed migration is pretty much
> a
> fresh migration that declares that it replaces a bunch of previous
> migrations.
> The history of migrations runs a series of alterations. The squashed
> migration
> runs a simple creation.
>
> Here are the differences I found and couldn't explain by problems in our
> code:
>
> - Sequences aren't handled correctly when changing an AutoField into an
>   IntegerField. I filed #24533. This could result in different behavior in
>   dev/test and production, which I find dangerous. I could probably
> present it
>   as a crashing or data loss issue.
>
> - Some unique indexes on OneToOne fields were missing. This may be a
> variant
>   of #24163. I haven't investigated it fully. This is about as bad as the
>   previous one.
>
> - Many varchar_pattern_ops indexes were missing in production. See #23954.
>   This could result in performance issues.
>
> - I had a constraint generated twice locally, once in prod. I'm not sure
> why.
>
> Given that basic use of makemigrations & migrate can result in significant
> errors in the resulting database schema, in the current state of
> migrations,
> we cannot promote them as the single way to manage the database schema. The
> risk of not creating the expected schema -- or, worse, not having created
> the
> expected schema in the past -- is simply too high. Every project that ever
> used 1.7 or 1.7.1 suffers from such issues.
>
> Therefore I think we must document how our user

Re: 1.9 release planning

[Marc Tamlyn]

This looks like a good plan to me. The main reason for shortening it before
as far as I could tell was the lengthy alpha to final process, which hasn't
happened this time and hopefully will be rather less frequent in future.

Marc

On 7 April 2015 at 00:21, Tim Graham  wrote:

> With a 9 month schedule, here is what the future might look like:
>
> 1.8 - April 2015
> 1.9 - January 2016
> 2.0 - October 2016
> 2.1 - July 2017 (LTS, and might be the last version to support Python 2.7
> since 3 years of LTS support would cover until the 2020 sunset.)
> 2.2 - April 2018
>
> Do you think there would be any value in putting together a short survey
> for the community to get a wider consensus?
>
>
> On Monday, April 6, 2015 at 5:30:40 PM UTC-4, Shai Berger wrote:
>>
>> On Monday 06 April 2015 23:34:09 Chris Foresman wrote:
>> > I'm really curious to know if the version to follow 1.9 is planned to
>> be
>> > 2.0 or 1.10. I feel as though 1.x releases have had a lot of major
>> feature
>> > changes. Maybe it's time to start thinking about features in terms of
>> > major, minor, and bugfix/security patch, and start saving major
>> features
>> > for a 2.0 release that could be LTS. In the meantime, minor features
>> could
>> > be added to 1.9, 1.10, 1.11, etc, and breaking API changes should be
>> added
>> > to 2.x, or 3.x, etc. This would make it (IMO) easier to evaluate
>> upgrade
>> > paths, while maintaining the six-month cadence for .x releases of minor
>> > features.
>> >
>> This was decided a little before 1.7 was released: the version after 1.9
>> will
>> be called 2.0, but it is not going to break things more than earlier
>> releases
>> (there are already warning classes named RemovedInDjango20Warning and
>> RemovedInDjango21Warning in the sources, anticipating the releases after
>> 1.9).
>>
>> Shai.
>>
>  --
> 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 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.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/56675028-6c26-4f72-9491-98f2db0f529e%40googlegroups.com
> 
> .
>
> For more options, visit https://groups.google.com/d/optout.
>

-- 
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 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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAMwjO1FBi1f1wOYXAThzT0OfZt9JekO5g53jcy5uOtn%2B9uw58g%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: render_to_response in Django 1.8 missing a request parameter?

[Marc Tamlyn]

This is probably a slight error in the documentation, however what you
really want to use is the `render()` function when you want a request
context.

See https://docs.djangoproject.com/en/1.8/topics/http/shortcuts/#render

On 7 April 2015 at 11:28, Stephen Brooks  wrote:

> I note from the release notes for Django 1.8
> https://docs.djangoproject.com/en/1.8/releases/1.8/ the remark under the
> section:
> "dictionary and context_instance arguments of rendering functions" (which
> includes django.shortcuts.render_to_response())
>
> "If you’re passing a Context
> 
> in context_instance, pass a dict
>  in the context
> parameter instead. If you’re passing a RequestContext
> ,
> pass the request separately in the *request *parameter."
>
> However, render_to_response* does not have a request parameter*. Is that
> an omission?
>
> I use the following idiom quite a lot:
>
> response = render_to_response('some_template.html', {'foo': 'bar'},
> RequestContext(request))
>
> If the passing of a context_instance is now to be avoided, I would expect
> to be able pass in the request object directly to render_to_response.
> Otherwise how are the context processors to do their job?
>
> -- Stephen
>
> --
> 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 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.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/e9b54373-9901-4a5a-8101-89b6a7cedaf6%40googlegroups.com
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>

-- 
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 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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAMwjO1HqvgMm0_RKdYqt2XVbb%3DsKEjzvb6f0Vpsw_J2kifAcXw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: render_to_response in Django 1.8 missing a request parameter?

[Marc Tamlyn]

The purpose of render_to_response is "render without a request context" now
as far as I can tell. There are reasons why you would do this, whether they
justify the existence of the shortcut is another question.

On 7 April 2015 at 11:37, Stephen Brooks  wrote:

> In that case the render_to_response shortcut has little value and should
> probably be removed in Django 2.0 ??
>
> On Tuesday, 7 April 2015 11:31:24 UTC+1, Marc Tamlyn wrote:
>>
>> This is probably a slight error in the documentation, however what you
>> really want to use is the `render()` function when you want a request
>> context.
>>
>> See https://docs.djangoproject.com/en/1.8/topics/http/shortcuts/#render
>>
>> On 7 April 2015 at 11:28, Stephen Brooks  wrote:
>>
>>> I note from the release notes for Django 1.8 https://docs.djangoproject.
>>> com/en/1.8/releases/1.8/ the remark under the section:
>>> "dictionary and context_instance arguments of rendering functions" (which
>>> includes django.shortcuts.render_to_response())
>>>
>>> "If you’re passing a Context
>>> <https://docs.djangoproject.com/en/1.8/ref/templates/api/#django.template.Context>
>>> in context_instance, pass a dict
>>> <https://docs.python.org/3/library/stdtypes.html#dict> in the context
>>> parameter instead. If you’re passing a RequestContext
>>> <https://docs.djangoproject.com/en/1.8/ref/templates/api/#django.template.RequestContext>,
>>> pass the request separately in the *request *parameter."
>>>
>>> However, render_to_response* does not have a request parameter*. Is
>>> that an omission?
>>>
>>> I use the following idiom quite a lot:
>>>
>>> response = render_to_response('some_template.html', {'foo': 'bar'},
>>> RequestContext(request))
>>>
>>> If the passing of a context_instance is now to be avoided, I would
>>> expect to be able pass in the request object directly to
>>> render_to_response. Otherwise how are the context processors to do their
>>> job?
>>>
>>> -- Stephen
>>>
>>> --
>>> 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 it, send
>>> an email to django-develop...@googlegroups.com.
>>> To post to this group, send email to django-d...@googlegroups.com.
>>> Visit this group at http://groups.google.com/group/django-developers.
>>> To view this discussion on the web visit https://groups.google.com/d/
>>> msgid/django-developers/e9b54373-9901-4a5a-8101-
>>> 89b6a7cedaf6%40googlegroups.com
>>> <https://groups.google.com/d/msgid/django-developers/e9b54373-9901-4a5a-8101-89b6a7cedaf6%40googlegroups.com?utm_medium=email&utm_source=footer>
>>> .
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>>
>>  --
> 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 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.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/2066cb5c-514e-4ccb-bd5e-442f7b2d60ea%40googlegroups.com
> <https://groups.google.com/d/msgid/django-developers/2066cb5c-514e-4ccb-bd5e-442f7b2d60ea%40googlegroups.com?utm_medium=email&utm_source=footer>
> .
>
> For more options, visit https://groups.google.com/d/optout.
>

-- 
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 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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAMwjO1Ejtx%2BaQvSczLAR%3DdAPq%3D3nLMiBgZo68bj40WryOZw2LA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Django Admin New Look

[Marc Tamlyn]

Django's master is the correct branch for 1.9 development now.

Flat icons would be good, and I agree personally with your earlier
suggestion to use font awesome icons. I do think this is a separate issue
we could add later.

The primary questions to establish answers to before a possible merge in my
opinion are:
- Do we ship both, or just the new one and release the old one as a third
party package?
- How could we identify the difference for third party app developers who
integrate with both versions, at least across the 1.8/1.9 release cycle?
The easy answer here would be to add a new body class, potentially to both
versions.

My suggestion would be that we should publicise via this mailing list (and
django-users etc) that we are planning to integrate this, and you can use
it now via your app. This should hopefully get you more bug reports early
and we can merge it in a more finished state for the 1.9 alpha.

On 7 April 2015 at 16:16, elky  wrote:

> Hi everyone. As you can see there is less activity now in this thread.
> With the latest 0.9.3 release I just think CSS work is over until anyone
> report a bug or suggestion to improvement.
>
> There is big interest from the community:
> - 1736 downloads in the last month from PyPi
> 
> - 334 unique visitors of the repo
>  and 117 stars
>
> People actively use this theme so it's time to think what do to next.
>
> I would like to make Pull Request in Django 1.9 branch when it starts -
> but I need feedback and suggestions before. Please share your thoughts,
> guys.
>
> I manually found interesting discussion here
> . Few
> words on flat icons - I think it requires markup change but if people
> really want to see flat icons I suggest to use one of the popular icon font
> library (like I suggested in October
> ).
> Any thoughts?
>
> Thanks,
> Alex
>
>  --
> 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 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.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/8e0d0669-6c37-4c44-9d07-6ac625413492%40googlegroups.com
> 
> .
>
> For more options, visit https://groups.google.com/d/optout.
>

-- 
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 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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAMwjO1H6rLP8uFh6bHVjeTdnrx3jNXfwqkQWvX9cqk%2BoCuYgdw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Django Admin New Look

[Marc Tamlyn]

We would modify our base admin template when we merge it. There are a
number of third party applications which provide modified versions of their
admin pages (FeinCMS is a good example of a moderately complex one). They
would normally support two versions of Django (maybe also an LTS now), and
so would need to provide one code base which works with both. So the
shipping of and old one doesn't make third party app developers headache
any worse.

We will need to release the old one as a third party app, or ship both for
a deprecation period because of users own admin style changes and overrides
they may have made.

I'm not sure the best approach for swapping between the two, even if they
are shipped separately. Perhaps the easiest option is to ship both
versions, add an AdminSite.theme parameter set to the new one. The main
issue I can see with this would be two lots of static files collected every
time (annoying for S3 users), but this is liveable with.

On 7 April 2015 at 16:52, elky  wrote:

> On Tuesday, 7 April 2015 20:23:28 UTC+5, Collin Anderson wrote:
>>
>> There's a ticket about icons here: https://code.djangoproject.
>> com/ticket/20597
>>
>
> Thanks Collin.
>
>
> On Tuesday, 7 April 2015 20:25:57 UTC+5, Marc Tamlyn wrote:
>>
>> The primary questions to establish answers to before a possible merge in
>> my opinion are:
>> - Do we ship both, or just the new one and release the old one as a third
>> party package?
>>
>
> If we release old one as a third-party app we need to support it as well.
> And it is additional headache for the third-party apps developers.
>
>
>> - How could we identify the difference for third party app developers who
>> integrate with both versions, at least across the 1.8/1.9 release cycle?
>> The easy answer here would be to add a new body class, potentially to both
>> versions.
>>
>
> How we can add this class? Someone suggested a setting to enable new
> theme. Ideally Django needs something like CSS framework because as far as
> I can see most of apps just uses their own styles and markup.
>
>
>> My suggestion would be that we should publicise via this mailing list
>> (and django-users etc) that we are planning to integrate this, and you can
>> use it now via your app. This should hopefully get you more bug reports
>> early and we can merge it in a more finished state for the 1.9 alpha.
>>
>
> That would be great.
>
>  --
> 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 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.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/0a3c2428-fe8e-48de-9b25-c658446548a5%40googlegroups.com
> <https://groups.google.com/d/msgid/django-developers/0a3c2428-fe8e-48de-9b25-c658446548a5%40googlegroups.com?utm_medium=email&utm_source=footer>
> .
>
> For more options, visit https://groups.google.com/d/optout.
>

-- 
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 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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAMwjO1FDmk%3DXZsTiJ5hxJ3utjXW_HCyDu1TKoSRnzwPsv2E13g%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Removing global database converters and adapters for datetimes

[Marc Tamlyn]

I think this is likely a good plan. There are a number of other places
where we globally register converters/adapters (at least in postgres land)
rather than explicitly registering them on each connection. I'm not sure if
they're an issue in the same way though.

Marc

On 13 April 2015 at 20:11, Carl Meyer  wrote:

> On 04/13/2015 12:13 PM, Aymeric Augustin wrote:
> [snip]
> > Do you think the backwards-incompatibilities are acceptable?
>
> I think so, yes. It really isn't good behavior for Django to be
> automatically installing such global adapters and converters.
>
> Perhaps the release notes documenting this backwards-incompatible change
> could also provide sample code for users to install these
> adapters/converters themselves, in order to restore the previous
> behavior, if they are using datetimes in raw SQL queries with
> cursor.execute()?
>
> It would also be possible to put the silent-data-loss aspect of this
> change through a deprecation path, by having the existing adapters raise
> a deprecation warning on receiving any non-UTC aware datetime for a
> couple releases (presuming the ORM is updated to always send only UTC,
> the adapter should only receive non-UTC on direct cursor.execute()).
>
> Carl
>
> --
> 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 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.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/552C14C9.90200%40oddbird.net
> .
> For more options, visit https://groups.google.com/d/optout.
>

-- 
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 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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAMwjO1EUzoj5gCm6jiHP0xsHB9Mpx4FezZBzvfeziqTJob0iWA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Why deprecate the ability to reverse using the Python path?

[Marc Tamlyn]

Hi Thomas,

I appreciate your concern, and it's a significant change for your
application, which is obviously very large and has been in development for
some time. I've been involved with similarly painful processes such as the
transition to the {% url %} tag requiring a string.

First a note on the pace: Django urls have had names since at least Django
1.1, I can't find docs for them before that. We have been recommending the
use of url names in the tutorial and everywhere else in the documentation
since Django 1.5. We could have deprecated it at the same time as we did
this, but chose to delay that by a couple of years. When we then proposed
it for deprecation, a newer contributor expressed surprise that the feature
actually existed, as it hasn't been prominent in the documentation for some
time.

The feature has just been deprecated now, it will not be removed until
Django 2.0, at least a year from now. Django 1.8 is also an LTS, so you can
rely on that for at least 3 years if you need to.

Regarding the motivation for the change, I should expand on why I think
it's a bad idea. For the sake of clarity, when I say it's "just a bad
idea", I mean "I cannot find a redeeming feature for this idea, it's just
plain bad".

Firstly, it relies on automatic imports via strings, something Django has
done far too much of historically and we are trying to move away from. In
settings it is hard to avoid, elsewhere it pays to be more explicit. We
have addressed some security concerns in this area, but that does not mean
that they are all avoided. Secondly, It restricts your ability to move
views around, especially in a third party application. If you decide your
views file needs splitting up, you have to then reimport everything into
the init.py or rewrite all the reversing. In the prototyping phase of a new
project, I've often found  It's an unnecessary level of coupling for most
applications, with very little work to avoid it. Thirdly, the whole feature
doesn't work for class based views which are now in common usage throughout
a lot of the Django ecosystem, and having a shortcut which only works for a
part of the system doesn't make sense. Finally, it makes overriding urls
from external packages a huge amount harder. With naming, you can
deliberately override the name and url pattern of a given view, and
anything pointing at the old one will now point at yours.

The general consensus in conversations held in person or on IRC was that
naming was a far better design decision and probably should have been
enforced from the start. There were at least 6 members of the core team
involved in the decision at the time, two of them on the technical board.
We don't consider "give URLs a name" to be a wagon, we consider it to be
the only correct way to do it.

In terms of what you can do, you have a few options. The first proposal is
a good one by Tim, to implement a custom url() or patterns() function in
your project which infers either by using the passed string or inspecting
the actual function where the view lives, and constructs the name
`myapp.views.foo` out of it. This means a small piece of code to write, and
a small change in each of your urls.py files. Another alternative is to
update all your urls.py to add the name `myapp.views.foo`. If you've got
1000 url mappings this is a bit of work, although depending on how
succinctly formatted your files are you can probably mostly do it with sed.
This was your original suggestion. There aren't any restrictions on the
name of a url except that it probably shouldn't contain `:` as that is used
for namespaced url patterns.

A more complete solution would be to define your own new project
convention. It seems something like `myapp-foo` would suit you well. This
would require more work to update, although again large chunks of the work
could be done with sed. Your exact mileage may vary.

In summary, we feel that it enforces good practice, at a relatively small
upgrade cost for existing sites who use the "old" way. It simplifies the
code, and removes some unpleasant side effects. I hope this explanation
helps.

Marc

On 16 April 2015 at 09:33, Raphael Michel  wrote:

> Am Thu, 16 Apr 2015 01:21:04 -0700 (PDT)
> schrieb guettli :
> > We never jumped on the "give the URLs a name" wagon.
>
> Why don't you go with Tim's idea to implement a custom url() method to
> automatically give the views their path as URL names? This should be
> rather easy and you should be able to do the migration in half an our
> without any drawbacks.
>
> Best regards,
> Raphael
>
> --
> 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 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.
> To view

Re: CSRF_COOKIE_HTTPONLY is misleading and not useful

[Marc Tamlyn]

I'm not a security expert, but one thing I could suggest is that this
setting does mean that only javascript on a page with a POST form can
access the CSRF token. Depending on the nature of your site, this could be
a significant proportion of pages.

On 17 April 2015 at 21:22, Gavin Wahl  wrote:

> Ticket #15808 added the CSRF_COOKIE_HTTPONLY setting to set the
> HttpOnly attribute on the csrftoken cookie. The HttpOnly attribute is
> intended to prevent accessing a cookie through the DOM interface, only
> sending it over HTTP. This improves security for session cookies
> because it prevents XSS attacks from accessing the session id.
>
> The CSRF token is used through the DOM though, by embedding it in the
> HTML of a form, so it's always accesible through JavaScript anyway.
> The docs even suggest how to negate the effect of the setting:
>
> > This can help prevent malicious JavaScript from bypassing CSRF
> protection. If you enable this and need to send the value of the CSRF token
> with Ajax requests, your JavaScript will need to pull the value from a
> hidden CSRF token form input on the page instead of from the cookie.
>
> The first sentence isn't actually true. HttpOnly can't prevent
> JavaScript from obtaining the csrftoken, because the csrftoken has to
> be in the DOM anyway. The second sentence suggests doing something
> that completely negates the effect of the setting, so why use it at
> all?
>
> I understand that this setting may exist only to satisfy misguided
> security scanners and not to actually improve security. If that's the
> case, the implication that this setting improves security should be
> removed from the docs.
>
> --
> 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 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.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/CACPudh1Nn-Cz5hJivvTVcfD%3DSSB2E9ZC2s-2mnje88kARKjBfA%40mail.gmail.com
> .
> For more options, visit https://groups.google.com/d/optout.
>

-- 
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 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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAMwjO1GGJEB5FMkMtuFGnjAEAWN3Pw_HTVPdvQXr5Ysr-XLABA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Writing some tests for new feature

[Marc Tamlyn]

It's quite possible this is an area which is untested - partly because when
it was originally written we didn't have the mock library to prevent the
external url call. Adding tests would be wonderful.

Marc

On 22 April 2015 at 17:29, ST LEON  wrote:

> I want to contribute one new feature to Django (doing this first time).
>
> I reading this  and
> have one question.
>
> First, write tests. I want to improve work of ping_google()
> 
>  and
> add some new behavior.
>
> But I can't find any tests that cover this function.
>
> I think, that it might be here
> , but
> I can't find tests for *ping_google()*.
>
> So, what should I do? That test needs me to see, how they works, change
> some of them and write new ones.
>
> My changes aren't be so serious: just a very simple 2-3 new lines.
>
> Please, help.
>
> Thanks!
>
> --
> 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 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.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/474b740a-adb2-4c72-b297-e91941bc3e63%40googlegroups.com
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>

-- 
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 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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAMwjO1FHEp5s82afzhNRqxtnJJJfidTutxHM9TOWTgQLeaQ6Ag%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Idea/request for help: Django Developers Community Survey

[Marc Tamlyn]

I would suggest IRC and/or Github should be options on the "I follow Django
development" question.

I'd also suggest we ask a couple of open ended questions along the line of
"What's your favourite thing about Django" and "What's your least favourite
thing about Django". I've found interesting responses from people before
along those lines.

Marc

On 25 April 2015 at 13:29, Tim Graham  wrote:

> Aymeric and I put together a draft:
>
>
> https://docs.google.com/forms/d/1Owv-Y_beohyCm9o2xPamdBnvjreNYoWai3rDloKZxWw/viewform
>
> All questions are optional so you can just click through it to view the
> questions. We'll probably clear any responses before its finalized anyway.
>
> Let us know if you think we should make any additions or changes.
>
>
> On Wednesday, April 22, 2015 at 4:03:44 AM UTC-4, Federico Capoano wrote:
>>
>> Great idea.
>> The questions look good enough to me.
>>
>> I love django-apps or libraries shipped in python packages. One of the
>> reason I love Django is the fact that it didn't frenetically add stuff to
>> the framework just because it's cool.
>> The good thing of python packages is that you can get some data from pypi
>> (downloads) and github (clones). But we can't do that with contrib apps
>> unfortunately.
>>
>> Federico
>>
>>
>> On Saturday, April 18, 2015 at 1:00:13 AM UTC+2, Tim Graham wrote:
>>>
>>> I had an idea to conduct a survey to get a sense of how developers are
>>> using Django. I first had the idea when the question of maintenance of the
>>> Oracle GIS backend came up. We really have no idea whether or not anyone is
>>> actually using that backend, and it would be helpful to know so we are not
>>> wasting resources on unused features. Also there's the question of how
>>> often to release Django. I think it would be nice to make that decision
>>> based on some data from the community.
>>>
>>> Is anyone is interested in coordinating such a survey (collating
>>> questions, preparing the online survey, etc.).
>>>
>>> Some question ideas to get started:
>>>
>>> Which database backend(s) do you use?
>>> [ ] Checkbox for each one
>>>
>>> Which contrib apps do you use?
>>> [ ] Checkbox for each one
>>>
>>> How often would you like to see new major version of Django released?
>>> [ ] List some options, probably between 6 and 9 months.
>>>
>>> Describe which version of Django you use (check all the apply):
>>> [ ] I only use long-term support releases.
>>> [ ] I upgrade to the latest stable version as quickly as possible.
>>> [ ] I run off of master.
>>> [ ] I upgrade Django when the version I am using is nearing the end of
>>> its support (or after).
>>> [ ] I don't bother upgrading Django, even if it becomes unsupported.
>>>
>>  --
> 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 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.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/f14071d1-c570-483a-abd2-833e1b47ab4d%40googlegroups.com
> 
> .
>
> For more options, visit https://groups.google.com/d/optout.
>

-- 
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 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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAMwjO1EiqZOaUm2g%2BCuwMDvDG_%2ByWVUayymAhZ-7jK5syLNarg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: one patch to fix a Django 1.8 issue for merging legacy database

[Marc Tamlyn]

The automatic ID field would not be added if you have a primary key. I'm
not sure if inspectdb does pick up primary keys, I believe it does though.

I feel this discussion may be more suited to django-users, our forum for
helping debugging user issues.

Marc

On 28 April 2015 at 07:48, Ben L  wrote:

> Issue: I have an existing database, so the guide in
> https://docs.djangoproject.com/en/1.8/howto/legacy-databases/ to inspect
> db and created models.py .
>
> That table does NOT have an 'id' column, and the created models.py doesn't
> have 'id' either, and the class is unmanaged (managed=False). But when I
> use Django to create page, the system failed, saying the 'id' is not found
> in the table. Somehow the query included 'id' in the select fields.
>
> After a little bit of digging, I changed
> /usr/local/lib/python2.7/dist-packages/django/db/models/options.py:
> Old:
> line 284-287:
> else:
> auto = AutoField(verbose_name='ID', primary_key=True,
> auto_created=True)
> model.add_to_class('id', auto)
>
> New:
> else:
> if self.managed:
> auto = AutoField(verbose_name='ID', primary_key=True,
> auto_created=True)
> model.add_to_class('id', auto)
>
> Then my class will not get into this "AutoField" action to add 'id' in the
> query.
>
> Looks like an apparent bug. This change works well for me. Please check
> and confirm whether this should be commit into you code base.
>
> Thanks.
>
>
>  --
> 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 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.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/7dd7a80b-3b7c-4cb1-ab31-219c6c3ad3c5%40googlegroups.com
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>

-- 
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 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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAMwjO1HBgpHwwMQvNOE0GkKK%3D3EQE_jAF7SnUR5nnOJE6%2Bmzeg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Guessable entry points

[Marc Tamlyn]

Yes to python -m django
No to django as another alias for django-admin. After all, someone who is
just "guessing" will probably type dj and get django-admin[.py] anyway.

On 1 May 2015 at 15:03, Aymeric Augustin  wrote:

> On 1 mai 2015, at 15:51, Enrique Paredes  wrote:
>
> > So along this line of thought,  `django-admin` is a good command name?
>
> Well, it’s a reasonably unambiguous way to refer to the django-admin
> command, which is good for the docs.
>
> “django” is more ambiguous: it can refer to the framework itself (although
> incorrectly capitalized) or to the top-level Python package.
>
> --
> Aymeric.
>
>
>
>
> --
> 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 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.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/98213CAF-69E0-4CDF-AD66-86F3B3A2D5C6%40polytechnique.org
> .
> For more options, visit https://groups.google.com/d/optout.
>

-- 
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 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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAMwjO1FKc4RJaSkT1V9ZVKskGWt1tFE5o4pOVZfZxpc2W84ALQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Improving Test Speed for Projects that use django.contrib.postgres

[Marc Tamlyn]

One of the main questions is to work out what is slow. You can often gain a
lot by using the new --keep-db option which maintains the test database
between runs meaning you don't have the DDL time each run.

A brute force approach which can have an impact is to install postgres on a
RAM disk, this does have some significant performance implications.

If you are running linux or a brew-installed postgres, it's also possible
that your postgres instance is configured poorly for local development.
Christophe Pettus gave a talk a while back (slides[1]) which gives an
overview of some of the common flags you may want to change from their
1990s defaults. In particular the section on memory may be appropriate.

The ideal way to avoid this though is simply to not use the database as
much as possible. There are various ways to approach this, from mocking it
out, to unit testing various objects, to building ORM objects without ever
calling .save() on them. There are a number of resources online for this.

Personally, I tend not to worry too much about my overall test suite's
speed, so long as I can run the tests for the section I'm working on well I
then rely on the CI to deliver my final answers. As a side note, your CI
should always be trying to mimic live as much as possible - even if you
were to use SQLite locally for testing Django cannot guarantee all
behaviour is completely db agnostic, especially when it comes to constraint
checking.

Marc

[1] http://thebuild.com/presentations/not-your-job.pdf

On 4 May 2015 at 18:00, David Muller  wrote:

> Hi everybody,
>
> Recently I've begun to use the PostgreSQL specific fields introduced in
> Django 1.8.  My codebase actually uses the special fields (HStoreField and
> ArrayField mostly) frequently enough such that I cannot run my test suite
> on an in memory SQLite database -- I have to run on a PostgreSQL instance.
>
> Running my tests on PostgreSQL is fine, but I miss the zippy performance
> of an in memory SQLite database.  If, say, my test code *cannot *be
> refactored itself, what would be your suggested route for test speed
> improvement?  I see this outstanding django ticket for UNLOGGED postgres
> tables , and also some work
> by aaugustin towards adding a `--parallel` option to the django tests
> .  Another thought I had
> would be creating "dumb" versions of the PostgreSQL fields that worked in
> SQLite.
>
> I realize, of course, that by using `django.contrib.postgres`, I should
> expect to sacrifice Django's "plug and play database backends" -- still
> curious as to your thoughts of improving test speed for projects that use
> postgres specific fields.
>
> Thanks!
>
> --
> 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 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.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/32aa98c9-a05f-456f-bd0e-96d324104448%40googlegroups.com
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>

-- 
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 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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAMwjO1EXzPaoTS%2BSwTc4chQS-g-KA%2BG2S6WJnnbmhKhN4zSxtw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: An easier path to upgrade from one LTS release to another

[Marc Tamlyn]

I'm not sure that would be a wise move - for people who don't keep up with
deprecation warnings but otherwise move one version at a time it would make
upgrading from an LTS to the following release 3 times harder than normal,
encouraging stagnation. This also affects third party applications who will
have similar problems.

Marc

On 7 May 2015 at 09:18, Anssi Kääriäinen  wrote:

> One approach worth consideration is dropping deprecated features only
> after next LTS. This would mean that any non-deprecated feature that
> is available in current LTS will also be available (but possibly
> deprecated) in the next LTS. This should make a development model
> where code is developed using latest stable release, and supported
> using latest LTS a lot easier.
>
> I don't belileve we can offer an official LTS-to-LTS upgrade guide
> (maintaining one is simply too much work). You can of course try to do
> that, but you'll likely get a better result by upgrading one point
> release at a time.
>
>  - Anssi
>
> On Thu, May 7, 2015 at 11:04 AM, Abdullah Esmail
>  wrote:
> > Hello,
> > I apologize if this has been discussed already. I searched the topics,
> but
> > didn't find anything.
> > First, I'd like to thank all of you for the truly amazing framework. I've
> > been using django since 1.0 and it made my life much more easier and
> > enjoyable and _stable_.
> >
> > The reason why I love django is that stability is a high priority,
> > backward-compatibility is well maintained and clear, crystal-clear and
> > extra-detailed documentation, the "batteries-included" aspect, based on
> > python, and the steady and stable evolution of the framework. Everything
> is
> > well put together in an almost-perfect package. Thank you.
> >
> > To my main issue, have you explored the possibility of creating a direct
> > path from one LTS release to the next?
> > I think the "official" way of doing this now is to go through all
> releases
> > in-between (1.4 -> 1.5 -> 1.6 -> 1.7 -> 1.8).
> > It would be really great if there was a direct LTS-to-LTS path (1.4 ->
> 1.8).
> >
> > I'm not sure if the new system check framework can play a role here to
> make
> > this easier than before.
> > This might add a whole new layer of complexity and extra work, but I
> believe
> > it's worth it.
> > If it makes any difference, I don't mind helping with this and actually
> > bringing this feature to life.
> > I'm not that familiar with the internals of django, but I'm willing to
> learn
> > and get my hands dirty.
> >
> > I guess I should ask, is there a good reason why there is no direct
> upgrade
> > path between LTS releases?
> > Do you guys think it's not worth the extra effort and the current way is
> an
> > acceptable trade-off?
> >
> > Thank you,
> >
> > --
> > 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 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.
> > To view this discussion on the web visit
> >
> https://groups.google.com/d/msgid/django-developers/96e73e82-93fe-4ef7-92c4-ba67abb35b37%40googlegroups.com
> .
> > For more options, visit https://groups.google.com/d/optout.
>
> --
> 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 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.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/CALMtK1E-F8i4_%2BYLH6KRzWMvuJEmr8geDDU9mUY9MFRudhLw0Q%40mail.gmail.com
> .
> For more options, visit https://groups.google.com/d/optout.
>

-- 
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 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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAMwjO1HbBcZUddv8pNXXR%3DMz3S2vEHOK990yKqhCGzQ7Tb5XSA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: An easier path to upgrade from one LTS release to another

[Marc Tamlyn]

You only get painless upgrades from one LTS to the next *if* you don't have
any deprecation warnings in your code on the previous LTS. Whilst the
"getting it working" step from one LTS direct to the next should be fairly
easy, you're likely to be faced with just as large a set of deprecation
issues on that new LTS issues you would have had to fix to get it working.
This does have some benefit for a quick update for security support or
similar, however I think there's a good chance it will make the *next* LTS
more painful as those warnings will not have been eliminated.

Then again, I don't work in an LTS environment, and no one has been working
in such a setup with django through several LTS versions to see what
happens.

On 7 May 2015 at 12:41, Anssi Kääriäinen  wrote:

> On Thu, May 7, 2015 at 11:34 AM, Marc Tamlyn 
> wrote:
> > I'm not sure that would be a wise move - for people who don't keep up
> with
> > deprecation warnings but otherwise move one version at a time it would
> make
> > upgrading from an LTS to the following release 3 times harder than
> normal,
> > encouraging stagnation.
>
> The other side of this coin is that you get painless upgrades to the
> latest LTS from the latest stable version. So, with a bit of
> exaggeration, one could say that our current model encourages
> stagnation to non-LTS versions.
>
>
>  - Anssi
>
> --
> 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 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.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/CALMtK1EC%2B9nakK2MjW%2B5mV3Nyt10XbQi2vTw6_WCfDwQ2GQLJQ%40mail.gmail.com
> .
> For more options, visit https://groups.google.com/d/optout.
>

-- 
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 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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAMwjO1GR31cYY-yq0A4RcacgAn%3DO2g4kwgmLWm_fR40iQ%2B4R6Q%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Is improving Django's communication with Oracle databases on the roadmap?

[Marc Tamlyn]

I can't comment on the specifics of this issue, but I would like to mention
that there is no roadmap for Django development in general. Oracle
expertise is an area we struggle with compared to other backends, and all
outside enthusiasm for improving the Oracle backend is gratefully received!

On 15 May 2015 at 02:02, Josh Smeaton  wrote:

> Hi Daniel,
>
> Can you provide links to the patches and discussion you're referring to?
> It'll be easier to provide some feedback if we have the detail in front of
> us.
>
> I'm all for improving performance for the Oracle backend - as long as
> backwards compatibility or correctness doesn't suffer. If either of those
> are concerns, perhaps we can find a way to overcome them.
>
> Cheers
>
> On Friday, 15 May 2015 08:24:10 UTC+10, Daniel Porter wrote:
>>
>> Hi list,
>>
>> I recently started working in the research wing of Moffitt Cancer Center,
>> and our shop uses django for +10 in-house applications, running almost
>> exclusively against oracle applications. Django has enabled building some
>> great applications, but the performance is kind of terrible when run
>> against an oracle backend. Asking on the cx_oracle list, Shai Berger told
>> me it was probably due to the known problem where numbers get converted to
>> strings and then back to numbers. Shai also pointed me to a patch he wrote
>> that might mitigate it, which I haven't had time to work with but am
>> optimistic about.
>>
>> Reading the thread he linked, it seemed like there was a decision not to
>> make the fix - I'm hazy on the technical details, but I think it was
>> because the fix required a loss of precision from an oracle-specific type
>> of decimal field, and cx_oracle didn't allow a way to differentiate between
>> this field type and other number types. I'm getting some free time towards
>> the end of the month where I can dig more into the patch/explore causes
>> more fully, but I wanted to ask here - has that decision been revisited, or
>> does it stand?
>>
>> If Shai's patch improves performance, then I'm sure we can just keep our
>> own, patched version of django. I would be stoked for there to be a main
>> branch solution, though.
>>
>> Thanks!
>> Daniel
>>
>  --
> 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 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.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/951372c6-2780-45a1-9082-ae356bff193b%40googlegroups.com
> 
> .
>
> For more options, visit https://groups.google.com/d/optout.
>

-- 
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 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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAMwjO1EasfEk9s9DhkHdxi9_pvQppYj8cXqn8zOFvugAmvD8oQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Proposal: Manually login without authenticate

[Marc Tamlyn]

Here is a related ticket for doing this in tests, where frankly I don't
care about authentication. https://code.djangoproject.com/ticket/20916

On 22 May 2015 at 17:30, Paulo Gabriel Poiati 
wrote:

> Good point James,
>
> It make sense if you could login the user without the credentials
> (proposal).
>
>
> On Fri, May 22, 2015 at 1:21 PM James Brewer 
> wrote:
>
>> Hey Paulo,
>>
>> As you mentioned, the raw password should still be present in the form,
>> along with the username. You can use these as parameters for
>> `authenticate()`.
>>
>> More to your original point, I would be interested in knowing why
>> `authenticate()` and `login()` are separate methods. There is no
>> information on this in the docs (that I could find). Is there a use case
>> where you want to authenticate a user without logging them in?
>>
>> On Fri, May 22, 2015 at 8:57 AM, Paulo Gabriel Poiati <
>> paulogpoi...@gmail.com> wrote:
>>
>>> Maybe this is not the perfect example because we have the plain password
>>> in the form. Another one is if a backoffice user can log as any user of the
>>> system.
>>>
>>> On Fri, May 22, 2015 at 12:53 PM Paulo Gabriel Poiati <
>>> paulogpoi...@gmail.com> wrote:
>>>
 Of course Tim,

 One instance is if you need to login the user after registration:

 class RegistrationView(CreateView):
 ...
 def form_valid(self, form):
 user = form.save()
 login(self.request, user)
 # redirect


 I don't have the user password because it's an one way hash and thus I 
 can't call `authenticate`. The only solution I can think is hacking the 
 auth system (setting the backend manually in the user model).


 On Fri, May 22, 2015 at 12:44 PM Tim Graham 
 wrote:

> Could you elaborate on what use case you are trying to solve?
>
>
> On Friday, May 22, 2015 at 11:36:21 AM UTC-4, poiati wrote:
>>
>> Hello guys,
>>
>> I want to discuss the current login workflow in django. As it is we
>> need to call `authenticate` before `login` because we need to set the
>> authentication backend in the user model. We can use login without
>> authenticate if we set the backend attr manually, but this need some
>> implementation knowledge of how authentication backends works.
>>
>> *PROPOSAL*
>>
>> *django.contrib.auth.login*
>> Only set the backend in the http session if the user has the attr.
>>
>> request.session[SESSION_KEY] = user._meta.pk.value_to_string(user)
>> request.session[HASH_SESSION_KEY] = session_auth_hashif hasattr(user, 
>> 'backend'):
>> request.session[BACKEND_SESSION_KEY] = user.backend
>>
>>
>> *django.contrib.auth.get_user*
>>
>> If the backend is not set iterate over all the backends in 
>> `settings.AUTHENTICATION_BACKENDS` and return the first found.
>>
>>
>> I can think in two drawbacks of this implementation but as far as my 
>> knowledge goes neither of them is a big deal.
>>
>>
>> - Performance, in the worst case we are trying all the backends this can 
>> take some time depending on the backend provider.
>>
>>
>> - Two backends can share the same user identifier and thus we will be 
>> using the first declared in the settings.
>>
>>
>> What do you guys think?
>>
>>
>> Thanks,
>>
>> Paulo Poiati.
>>
>>
>>
>>
>>
>>
>>  --
> 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 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.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/fbbd5579-a5e9-4370-8943-75204f334016%40googlegroups.com
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>
  --
>>> 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 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.
>>>
>> To view this discussion on the web visit
>>> https://groups.google.com/d/msgid/django-developers/CABqSV%3D%2B5Vr%2B-JC2_yXdzwUpj9Y%2B1XwNOKf3_Fhc5h%3Dw4kuK%2BpQ%40mail.gmail.com
>>> 

Re: Proposal: Manually login without authenticate

[Marc Tamlyn]

>
> If the backend is inferred by a single value in the settings and not
> stored alongside the user ID, what would happen to existing users who are
> already logged in when a second backend is added to the settings and
> deployed? Django would no longer know which backend to use to fetch the
> authenticated user?
>

I believe the intention would be to store the single backend against the
user ID on login, so this would be safe for sessions loaded after a second
backend is added. Obviously code using this convention would need to be
updated when more than one backend is used.

I think this would be a good plan, I reckon that most sites use only one
auth backend anyway.



>
> Cheers.
> Tai.
>
>
> On Saturday, May 23, 2015 at 6:58:35 AM UTC+10, Unai Zalakain wrote:
>>
>> Hi Paulo!
>>
>> >If the application has only one backend we always infer it in the login
>> >function. If it isn't, the client needs to provide one explicitly.
>>
>> Why not pass the single auth backend into the login function? It makes
>> the design and the documentation much simpler.
>>
>> --
>> unai
>>
>  --
> 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 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.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/0319a35d-b870-4edd-8805-a2707a8b0f58%40googlegroups.com
> 
> .
>
> For more options, visit https://groups.google.com/d/optout.
>

-- 
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 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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAMwjO1EB_QFhmWkyOwgeYRDQsi8Q8bLzGH0vRTShG-SzLccCFw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Feature request - models.TextInAParagraphField

[Marc Tamlyn]

Hi Reiner.

You'll get answers to questions like this on the django-users email list, <
django-developers@googlegroups.com> - the web interface is <
https://groups.google.com/forum/#!forum/django-users>.

The list you've posted to is django-developers, which is for the discussion
of the development of Django itself.

You might also find the #django IRC channel on irc.freenode.net helpful.

As a start point, you may also wish to read the docs for help_text
.

Marc

On 30 May 2015 at 23:06,  wrote:

> Hello,
>
> It would be very helpful to create forms in the model only. The thing I
> miss
> is a simple text in the model that would appear in the output form exactly
> on the position from the model as text e.g. in a Paragraph.
>
> I fail to do it myself from documentation.
>
> Example :
>
> in models.py
>
> class Example(models.Model):
> Name   =
> models.CharField(max_length=100,blank=True,null=True)
> # Now a field that needs no DB representation
> Question_TIW =
> models.TextInAParagraphField(verbose_name='Some informational Text')
> # or assign verbose_name later in view
> Ans1_OKH   = models.BooleanField(default=False)
> Ans2_OKH   = models.BooleanField(default=False)
> Ans3_OKH   = models.BooleanField(default=False)
>
> in views.py
>
> class ExampleNew(MyCreateView):
> # I use model based views only
> # Here Labels get added and Texts for Information get added to the
> context
> #
> form_class = ExampleForm
>
> in forms.py
>
> class ExampleForm(BootstrapForm):
> # class based form
> # In BootstrapForm attributes are added to widgets and Tooltips get
> added for Popovers
> #
> Meta=BootstrapMeta(Example)
> #
> # In BootstrapMeta widgets and renderers get assigned / I use it
> this way
> # endswith '_OKH' is a horizontal SelectButton with Label to the
> right as DIV row
> # to endswith '_TIW' I would assign a new TextInWellRenderer :)
> #
>
> urls.py
>
> url(r'^example/$', ExampleNew.as_view(mymodel=Example),   name='example'),
>
> 
>
> So 6 lines of code per Form (maybe 4, as I use the same view for many
> models)
>  + One line each Field
>  + Generic code
>
> Result should be a Form
>
> with a Name input,
> followed by the text,
> followed by Select Buttons to click
> followed by a submit button
>
> /example
>
> I think that would make forms in Django a lot easier to use and more
> effective
> with less work to do.
>
> kind regards
> Reiner
>
> --
> 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 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.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/4d7640ff-c064-4db5-8d3c-50b2db10e142%40googlegroups.com
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>

-- 
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 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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAMwjO1G40Hvjb4-ePn7shGM9OG6v0g647t7Q32njTHLxU25qEA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Deprecate internal syncdb in 1.9 ?

[Marc Tamlyn]

Maintaining some ability for test applications to have no migrations is
very important for Django's own test suite and also other tools such as
djangobench. If we're going to maintain some form of code path for that, we
should expose it publicly as well.

Marc

On 3 June 2015 at 14:29, Markus Holtermann  wrote:

> After some discussion with other members of the core team, we think that
> we might re-evaluate the point of dropping support for apps without
> migrations. But this highly depends on the outcome of what Andrew is going
> to achieve in https://code.djangoproject.com/ticket/24481#comment:6 with
> regards to the last point. Depending on the actual overhead that comes up
> there we'll may or may not enforce migrations for all apps at some point.
>
> The deprecation timeline marks the removal of support for apps without
> migration a part of 1.9. However, since the reason for putting that on the
> deprecation timeline was that syncdb used to use the old DDL code, this
> argument does not hold anymore. syncdb uses the same DDL code as migrations.
>
> /Markus
>
>
> On Wednesday, June 3, 2015 at 1:16:37 PM UTC+2, Andriy Sokolovskiy
> (coldmind) wrote:
>>
>> After discussion with Markus Holtermann, we decided that we need to
>> deprecate internal syncdb in 1.9 (
>> https://github.com/django/django/blob/7c637a3aaec311269bf863c220bf894eebbe7c7c/django/core/management/commands/migrate.py#L136
>> )
>> The fact that apps without migrations are not supported, which is
>> documented for current master, is not fully right, because migrate command
>> is still calling syncdb inside.
>> I think it is time to drop support of apps without migrations internally,
>> so in 2.0, after users will be warned in 1.9, we can remove syncdb and
>> create
>> schema only from migrations and require all installed apps with models to
>> have migrations.
>>
>  --
> 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 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.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/7d2fd535-40b3-4c83-845b-72d248096587%40googlegroups.com
> 
> .
>
> For more options, visit https://groups.google.com/d/optout.
>

-- 
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 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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAMwjO1EwpYDEqVF%2BtKxvtt2xWHzYUWpmoCbx3LwppYnUHCReTw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Provide free, simple, small-scale hosting for new users

[Marc Tamlyn]

Heroku also offers free hosting of a sort. The DSF has nowhere near the
financial muscle or human resources to provide such a service. There could
be an argument to document possible free hosting platforms, but the django
project generally avoids advertising any particular company (or third party
package for that matter).

On 4 June 2015 at 16:23, Tim Graham  wrote:

> PythonAnyware provides free hosting and that's what the Django Girls
> tutorial uses: http://tutorial.djangogirls.org/en/deploy/README.html
>
> I don't think the Django Software Foundation needs to build a service like
> that.
>
>
> On Thursday, June 4, 2015 at 11:08:01 AM UTC-4, Markus Amalthea Magnuson
> wrote:
>>
>> Had discussions on an idea during DjangoCon Europe that I thought I'd
>> just throw out there on this list as well:
>>
>> What if the Django project provided free hosting for small projects, so
>> that any newcomer who went through the tutorial or similar could actually
>> deploy their application somewhere in as few steps as possible, a
>> mini-Heroku of sorts. I think it could be of immense value for someone who
>> built their first thing to show it to their friends without having to delve
>> deep into devops. This could be coupled with easy instructions on how to
>> move that application to proper hosting such as Heroku or AWS.
>>
>> There are so many aspects of this that would have to be solved (how to
>> limit, auth, etc.), so this is just testing the idea. What do you think?
>>
>  --
> 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 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.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/23d32e1c-d31f-4043-81b9-0338c0298cf8%40googlegroups.com
> 
> .
>
> For more options, visit https://groups.google.com/d/optout.
>

-- 
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 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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAMwjO1HKMY6NohAjwhrg0tm%2BQErp5Yd7eCtTKbwugJkuZnM-Kw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Extending contrib.admindocs functionality

[Marc Tamlyn]

This seems like a good idea to me. I'm not convinced that the original use
case for admin docs (documenting features which only work in templates for
the template author) is valid any more - especially with a Django in which
you can use jinja2 easily where function calls are allowed. The separation
between backend and template developers I tend to find is also much less
clear than it once was, partly because it's trivial to write template code
using documented features or properties which will quickly destroy
performance. The use case of "quick and dirty docs for the team" seems more
likely.

So overall, I'm in favour of adding this, possibly just by default not
hidden. The hidden adds a level of backwards incompatibility which is nice.

Have you opened a ticket for this change? You may also wish to review
the contributing
guide .

Marc

On 4 June 2015 at 14:51, Žan Anderle  wrote:

> contrib.admindocs will only document template tags and functions that can
> be invoked from templates. Therefore it has limited use. It would be really
> useful to be able to document all of the functions in the models (not just
> the ones that don't take any arguments). contrib.admindocs is a neat way of
> creating some basic documentation without any extra effort other than
> docstrings. By adding this feature, this potential could be fulfilled.
> Basically, you would get at least some documentation, just by writing
> docstrings (which you should be doing in the first place).
>
> Because there might be need to keep the current functionality, I suggest
> the following solution. By default the docs would stay the same as they are
> now (show only the functions that can be invoked from templates), but we
> would add a "Show more" button, which would show all the functions instead.
>
> This makes it easy, because there is no need for an extra setting in
> settings.py and it allows both new extended functionality and old
> functionality.
>
> PS This is my first time suggesting a new feature, so please let me know,
> if I missed something!
>
>  --
> 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 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.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/fdba020d-486e-4e6f-8660-dcea7b7f5d38%40googlegroups.com
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>

-- 
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 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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAMwjO1FQiNVoPYUDp2K6EhT0ajg77QsDVLc7G9wiS22oj6UNsw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Django Admin - ModelAdmin exclude

[Marc Tamlyn]

I don't think we should add this. Exclude is passed to the form, and we
already have a way of changing the form based on the request. I'd rather
see changes made to reduce some of the many many ways to select fields in
the admin. By my count at present we have:

ModelAdmin.fields
ModelAdmin.get_fields()
ModelAdmin.exclude
ModelAdmin.fieldsets
ModelAdmin.get_fieldsets()
ModelAdmin.readonly_fields
ModelAdmin.get_readonly_fields()
ModelAdmin.form concrete fields
ModelAdmin.form.Meta.fields
ModelAdmin.form.Meta.exclude
ModelAdmin.get_form()

There's an argument the only one missing here is get_exclude(), but I think
the current API is silly. Personally, I'd like to see us moving towards us
encouraging doing more work in the form (and defining the form) rather than
doing so much in the ModelAdmin class. This may well require better support
for fieldsets in django.forms.

Marc

On 6 June 2015 at 05:06, Peter Farrell  wrote:

> We are writing a custom admin for CleanerVersion that subclasses
> ModelAdmin. Just about every attribute has a hook method which makes
> extension easier. For example, list_display has get_list_display().
> However, exclude doesn't have one implemented and it seems like an
> oversight. I'm proposing we add one.
>
> Our current work seeking is to write a property descriptor for exclude but
> then the admin check fails with it not being a tuple or list. Then you have
> to create a custom admin checks class to suppress the exclude check error
> because it's not a tuple or list (but really a descriptor).
>
> If this is ok, I'Ill write a PR.
>
> --
> 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 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.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/c1e8762d-1c9f-47e9-8fe7-e9761c27e057%40googlegroups.com
> .
> For more options, visit https://groups.google.com/d/optout.
>

-- 
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 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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAMwjO1HKDr6T9BKf-%2B4rNm6775S7akyHfC%2BNEk4sqSDw8cOb%2Bg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Making management forms for formsets optional

[Marc Tamlyn]

I believe the complaint is mostly that an invalid formset will raise a 500
whereas an invalid form (should) never. There was a patch to display an
error if not. My complaint is that this error can only occur if the dev has
rendered the form by hand missing the management form. It's likely they
would also miss the non form error output this way and so the end result is
we display back empty forms to the user with no useful error event though
they filled in values. This is hard to debug and bad ux - a 500 is better.

Equally, every time a security crawler posts an empty body to a page
triggering a 500 is irritating noise. We don't report invalid forms as 500s
either...

This brought up the question of whether the management form is needed at
all.

Unrelated arguments: It also streamlines testing user formsets massively,
and significantly reduces the complexity of js to add more forms.

Marc
On 6 Jun 2015 17:00, "Florian Apolloner"  wrote:

> What about instead of trying to guess the forms from the input, just fix
> the one condition which causes the error and return 0 as totalformcount +
> an error marker to reraise the error in clean of the modelform?
>
> On Friday, June 5, 2015 at 11:29:21 AM UTC+1, Patryk Zawadzki wrote:
>>
>> Hi folks,
>>
>> I've talked to Marc about fixing the case where a formset will raise
>> an uncaught ValidationError when instantiated with a missing or broken
>> management form. This has caused us great pain when dealing with
>> vulnerability scanners that tend to POST random crap to each endpoint
>> they find as it means formsets—unlike forms—are not safe to
>> instantiate with untrusted data.
>>
>> Now wrapping each and every formset instance in a try/except block and
>> having to manually handle the fallback case is not fun. But as Marc
>> pointed out, forgetting a management form is one of the most common
>> pitfalls people run into when dealing with formsets.
>>
>> Therefore I propose making the management form optional. The only case
>> that requires an explicit TOTAL_FORMS variable are forms that consist
>> of nothing but checkboxes (as unchecked checkboxes are not included in
>> POST data). In other cases (including all ModelFormSets as they always
>> contain a hidden PK field) we can deduct the number of submitted forms
>> from the data itself.
>>
>> Ideally I would get rid of the management form entirely and document
>> that a form that is nothing but checkboxes is an unsupported case and
>> that a workaround would be to include an extra hidden field. Honza may
>> or may not kill me for suggesting that.
>>
>> For now, I would like to make the formset optional and document the
>> cases where you need to include it. If included, it would take
>> precedence to keep the existing deployments working.
>>
>> Thoughts?
>>
>> --
>> Patryk Zawadzki
>> I solve problems.
>>
>  --
> 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 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.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/de9e5a03-7f14-42e8-bf76-9405440ecf94%40googlegroups.com
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>

-- 
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 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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAMwjO1E9BmmPoxp8d3qcbbf01kJ1Qx19fZV9hXLghLRG%3D7omdQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: how to deal with inspect.getargspec() deprecation?

[Marc Tamlyn]

I'm not sure how similar the return values are, is it possible to write
(and contribute upstream) a six move? Perhaps this is impossible without
funcsigs though.

Marc

On 10 June 2015 at 20:09, Carl Meyer  wrote:

> On 06/10/2015 12:49 PM, Tim Graham wrote:
> > inspect.getargspec() was deprecated in Python 3.0 and will be removed in
> > 3.6 (ETA late 2016). It started throwing a deprecation warning in Python
> > 3.5 which causes some test failures when we check the number of
> > deprecation warnings so I'd like to deal with it now and avoid
> > introducing more usages.
> >
> > Its replacement is inspect.signature() which is in all the versions of
> > Python 3 we support, but not 2.7. Options I see:
> > 1. Add a dependency for the funcsigs backport [1] (only needed on Python
> 2)
> > 2. Vendor funcsigs in django.utils (about 1k LOC) (this has been the
> > historical approach)
> > 3. Write different code for Python 2 & 3
> >
> > [1] https://github.com/aliles/funcsigs
>
> I'd say either 1 or 2. Personally I feel the ecosystem is ready for
> Django to have dependencies, and we could go with 1. But maybe a 1k LOC
> back-compat lib, which would likely be trivial to vendor, isn't the best
> case for that first required dependency.
>
> Carl
>
> --
> 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 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.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/55788B4E.2060409%40oddbird.net
> .
> For more options, visit https://groups.google.com/d/optout.
>

-- 
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 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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAMwjO1HgqEqjoU8%3DypQJpQJP%2BW1_xE0f1Q%3DH4CQv-_NoW2bYwQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Django Admin - list_display default value

[Marc Tamlyn]

Agree this is not an appropriate default, although I could see an argument
for supporting __all__ like in forms. This isn't very hard as a third party
solution though so I'm not super keen on that idea.

M
On 15 Jun 2015 22:03, "Shai Berger"  wrote:

> (I received the message I'm replying to here with an empty subject, and
> detached from the thread. Google Groups being funny?)
>
> On Monday 15 June 2015 22:52:09 Rick van Hattem wrote:
> > On 15 June 2015 at 21:34, Florian Apolloner 
> wrote:
> > > On Monday, June 15, 2015 at 7:07:38 PM UTC+2, Rick van Hattem (wolph)
> > >
> > > wrote:
> > >> Would anyone oppose a pull request like this?
> > >
> > > Yes, it is highly backwards incompatible for not much gain, I am also
> > > usually just fine with one/two fields for list_display. You could just
> > > use your own admin subclass for that.
> >
> > Can you clarify on that? I don't see the backwards incompatibility here.
> >
>
> It could quite easily cause breakage for specific client-side code,
> although I
> wouldn't consider that "highly" incompatible.
>
> However, it could also easily lead to inappropriate data exposure -- where
> people who are supposed to get an "opaque" view of some objects will, upon
> upgrade, be able to see all their details. I consider that risk to weigh
> much
> more than the potential gains.
> >
> > The discussion here shouldn't be whether you can or cannot fix it
> yourself
> > (obviously, you can, that's not the issue), it's what a good/sane default
> > would be. For brand new Django users, would it be more convenient to
> have 1
> > column or just all local columns and make it slightly more usable?
> >
> Beside "convenient", you should also consider "safe", and besides brand new
> users, there are also established users with significant codebases. Now,
> arguably, if we were starting the Django project today, we could use the
> default you propose, people would be aware of it, and if they wanted to
> limit
> access, they would. One could still argue that "whitelisting" is better
> than
> "blacklisting", and we could have a whole discussion about this. But
> having a
> Django upgrade just expose more data by default, even in the Admin, would
> be a
> serious breach of our users' trust IMO.
>
> Shai.
>

-- 
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 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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAMwjO1HhkaHEGL%2BQaPc3_43%3DBJP84%2B-4XZMVs%3DK%2Bx8u6Q7c_Ow%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Password validation in Django revisited

[Marc Tamlyn]

This seems like a great example of something which can live as an external
package, and you document how to use it with `AUTH_PASSWORD_VALIDATORS`.
You could add a minimum entropy parameter as an option which can be passed
in the dict.

On 17 June 2015 at 03:38, Alex Becker  wrote:

> Hi Erik,
>
> I've done some work on pattern-based password validation in python,
> something intermediate in complexity between these validators and zxcvbn.
> The rough version is on github[1]. I was thinking of turning this into a
> password validator for django, one which would not be turned on by default.
> Thoughts?
>
> Alex Becker
>
> [1] https://github.com/alexbecker/password-strength
>
> Disclaimer: this is my first post to django-developers or any other oss
> mailing list for that matter. I apologize in advance for any breach of
> protocol.
>
> On Saturday, April 11, 2015 at 5:35:03 AM UTC-5, Erik Romijn wrote:
>>
>> Hi all,
>>
>> The PR [1] has now been extended taking much of the feedback into account
>> and adding docs and tests. I have also added a validator for common
>> passwords, based on a list of 1000 most common passwords. So I think the PR
>> is ready for another round of review - I’m sure there is still room for
>> improvement. Only current open task is to add release notes.
>>
>> We now have three validators, all enabled by default in new projects: the
>> common password validator, a validator that simply checks whether the
>> password meets a minimum length, and one that compares the password to the
>> user’s attributes, such as their name or e-mail address. The latter has
>> limits in it’s comparison - a more thorough method is provided, for
>> example, by zxcvbn [2]. However, I think vendoring a Python port of zxcvbn
>> is a little too much - I do intend to create a third party package with a
>> validator that ties to zxcvbn.
>>
>> There was a suggestion for a character class validator, e.g. requiring
>> that the password contains digits or uppercase characters. I’m not very
>> fond of that. Although quite common, I have strong doubts about whether it
>> actually improves passwords: my impression is that requiring users to add a
>> number will often mean they’ll add a 1 to the end, and requiring them to
>> add an uppercase character will mean they uppercase the first character. If
>> that is true, such a requirement would actually reduce password entropy, as
>> one could assume that the last character of a password is almost always 1,
>> etc. Unfortunately, I haven’t been able to find any research to support
>> that (or the contrary), so I can’t back this up with anything solid.
>>
>> For clarity, by default we do not enable any validators in existing
>> projects when they upgrade, as that would be breaking backwards
>> compatibility.
>>
>> Erik
>>
>> [1] https://github.com/django/django/pull/4276
>> [2] https://github.com/dropbox/zxcvbn
>>
>> On 14 Mar 2015, at 15:26, Erik Romijn  wrote:
>>
>> Hi all,
>>
>> Thanks for all the feedback. Good to see this seems to be heading in the
>> right direction. The suggestions make sense to me and I’ll work on those.
>>
>> There were two particular design suggestions: instead of tying the
>> validator to the password field, tying this to the authentication backend,
>> which would prevent having to add a setting, and allow different security
>> requirements for different backends. Another suggestion was to add
>> configurable password fields instead, which could also include other
>> functionality.
>>
>> My concern with tying the validator to the auth backend instead, is that
>> it would mean there is absolutely no way to circumvent the validation,
>> whereas in the current scenario I’ve intentionally not included validation
>> in User.set_password() by default - but only in the user-facing elements. I
>> think it will be easier to get wider adoption of password validation, if we
>> still leave an opportunity open to avoid it in special cases. Also, I’m not
>> sure whether we could still easily and cleanly provide the appropriate help
>> text to the user.
>>
>> If someone would want validation that depends on the auth backend, this
>> is possible with undocumented APIs. If my memory serves me right, the user
>> object that the validator has access to will have an attribute that
>> identifies the backend used to authenticate the user. The validator could
>> make different choices based on that, or even call a method on a backend.
>> That’s not with a currently documented API though.
>>
>> Replaceable password fields are themselves interesting, but I think it
>> would be too limited for password validation in general. A specific wish
>> was to also be able to tie validation into a REST API, for example. The
>> current validator design allows trivial integration of a validator into
>> absolutely anything. Custom password fields are already not too hard - all
>> you have to do is create your own form, override the password fields and
>> pass that form to the appropriat

Re: 1.9 release planning

[Marc Tamlyn]

+1 to 1.11

It was an arbitrary decision not to use 2.0 in the first place because we
were not going to do special version numbers. Now Y.0 is a special version
(dropping backwards compat after the LTS) it makes more sense.

Marc
On 22 Jun 2015 19:28, "Tim Graham"  wrote:

> Done that in https://github.com/django/django/pull/4908
>
> On Monday, June 22, 2015 at 1:35:19 PM UTC-4, Loïc Bistuer wrote:
>>
>> We can just leave RemovedInDjango20Warning as an alias (not a subclass)
>> to PendingDeprecationWarning in 1.8. As long as we don't refer to it in the
>> rest of the codebase it isn't ambiguous.
>>
>> --
>> Loïc
>>
>> > On Jun 23, 2015, at 00:21, Collin Anderson  wrote:
>> >
>> > People import the warning in order to silence them, right?
>> >
>> > On Monday, June 22, 2015 at 1:19:51 PM UTC-4, Markus Holtermann wrote:
>> > +1 -- Going with 1.8, 1.9, 1.10, 1.11 (LTS), 2.0 sounds like a solid
>> > plan. I don't think any of the (Pending)DeprecationWarnings are much of
>> > a public API. I've never seen them in the wild.
>> >
>> > /Markus
>> >
>> > On Mon, Jun 22, 2015 at 11:20:52AM -0400, Michael Manfre wrote:
>> > >+1. I really don't like the idea of 2.x being odd.
>> > >
>> > >On Mon, Jun 22, 2015 at 10:33 AM, Loïc Bistuer 
>> > >wrote:
>> > >
>> > >> Just when we thought we had a winner... I'd like to make a final
>> proposal.
>> > >>
>> > >> Instead of delaying adoption of SemVer to 3.0 we could do so in 2.0
>> by
>> > >> introducing the 1.10 and 1.11LTS releases.
>> > >>
>> > >> The upside is that the new policy applies right away and we avoid
>> the
>> > >> oddball 2.0 and 2.1 releases.
>> > >>
>> > >> It's much less invasive than the previous idea of renaming 1.9 to
>> 2.0, but
>> > >> it still requires renaming PendingDeprecationWarnings in 1.8, and
>> both
>> > >> warnings in 1.9.
>> > >>
>> > >> What do you think?
>> > >>
>> > >> --
>> > >> Loïc
>> > >>
>> > >> > On Jun 17, 2015, at 08:47, Josh Smeaton 
>> wrote:
>> > >> >
>> > >> > I'm also +1 on the proposal as it stands, and neutral on when the
>> semver
>> > >> versioning should begin.
>> > >> >
>> > >> > On Wednesday, 17 June 2015 05:03:47 UTC+10, Michael Manfre wrote:
>> > >> > I'm +1 on the Google doc proposal and like Markus, I support
>> relabeling
>> > >> 1.9 to 2.0 to line the versions up with the new paradigm without the
>> X.1
>> > >> LTS oddball.
>> > >> >
>> > >> > Regards,
>> > >> > Michael Manfre
>> > >> >
>> > >> > On Tue, Jun 16, 2015 at 12:34 PM, Collin Anderson <
>> cmawe...@gmail.com>
>> > >> wrote:
>> > >> > I also like the gdoc as it is. (1.8 LTS, 1.9, 2.0, 2.1 LTS, 3.0,
>> 3.1,
>> > >> 3.2 LTS, 4.0, etc.) LTS is the final of a major version number, and
>> we
>> > >> sacrifice a little bit of strict semver, but it give some nice
>> meaning to
>> > >> the version numbers.
>> > >> >
>> > >> >
>> > >> > On Tuesday, June 16, 2015 at 12:22:44 PM UTC-4, Carl Meyer wrote:
>> > >> > Thanks Loïc,
>> > >> >
>> > >> > On 06/16/2015 01:15 AM, Loïc Bistuer wrote:
>> > >> > > I've attempted to summarize the history of this thread. Note
>> that I
>> > >> > > marked as +1 any generally positive feedback towards a given
>> > >> > > proposal, please correct if you feel misrepresented.
>> > >> > >
>> > >> > [snip]
>> > >> > >
>> > >> > > # Third iteration:
>> > >> > >
>> > >> > > 5/ Switching to Semantic Versioning
>> > >> > >
>> > >> > > Donald mentioned SemVer on IRC a few days ago. Since then
>> various
>> > >> > > proposal were made to reconcile it with our release policy. So
>> far
>> > >> > > Collin, Carl, Loïc, Tim, and Josh have expressed positive
>> feedback to
>> > >> > > various proposals in that direction but I don't think we have
>> yet
>> > >> > > reached consensus on a specific one. Tim updated the Google doc
>> to
>> > >> > > reflect my latest proposal, so including me that's 2 formal +1
>> for
>> > >> > > it, but I'd say we should wait for at least a couple more votes
>> > >> > > before taking it to the technical board.
>> > >> > >
>> > >> > > Refs: - http://semver.org/ - Carl's analysis
>> > >> > >
>> > >>
>> https://groups.google.com/d/msg/django-developers/MTvOPDNQXLI/Ojov2QBROg8J
>> > >> > >
>> > >> > >
>> > >> > - Ryan's proposals
>> > >> >
>> > >>
>> https://groups.google.com/d/msg/django-developers/MTvOPDNQXLI/lBLWrhKJ6DIJ
>> > >> > > - Loïc's proposal
>> > >> > >
>> > >>
>> https://groups.google.com/d/msg/django-developers/MTvOPDNQXLI/y2QbPVzSs6cJ
>> > >> >
>> > >> > FWIW, I am also +1 on your proposal, as currently documented in
>> the
>> > >> > Google doc.
>> > >> >
>> > >> > I was trying to come up with a proposal where LTS == major release
>> for
>> > >> > the sake of argument, since it seemed like that was intuitive to
>> at
>> > >> > least some people, but it's not worth the required lengthening of
>> > >> > deprecation paths. Your proposal is much better. (And it does make
>> some
>> > >> > intuitive sense for the _last_ minor release in a major series to
>> be LTS
>> > >> > rather than the first).
>> > >> >
>> >

Re: Config file for startproject.

[Marc Tamlyn]

You may also want to look into cookiecutter as a way of managing more
complex templates for projects.

Marc
On 23 Jun 2015 05:26, "Hiroki Kiyohara"  wrote:

> Thanks, Josh.
>
> * I thought the config (.djangorc) should be included in project template
> it's own.
> * bash alias is OK, but it's not easy to share this way with lots of
> developers like "Hey, when you start development, please type `alias
> mystartproject...` (so long)."
>
> anyway, I got it. I'll create some aliases or wrapper commands if it's
> necessary.
>
>
> On Tue, Jun 23, 2015 at 12:08 PM, Josh Smeaton 
> wrote:
>
>> There are a couple of problems with this proposal IMO.
>>
>> 1) The .djangorc file would need to be somewhere on the file system (like
>> ~/.djangorc), because you want it for the startproject command, it can't be
>> deployed with startproject
>> 2) It doesn't seem to provide that big a benefit
>> 3) A simple bash alias can achieve the exact same result
>>
>> I just don't think this is something that Django needs to take on when
>> it's very easy to create your own alias that does exactly what you need.
>>
>> Regards,
>>
>>
>> On Tuesday, 23 June 2015 12:38:24 UTC+10, Hiroki Kiyohara wrote:
>>>
>>> Hi all.
>>>
>>> I propose a new feature `.djangorc`.
>>> It should be included in root of project template.
>>> You can write down configations for `startproject --template=...`
>>>
>>> ## Motivation
>>>
>>> I always use custom project template, but it requires a lot of arguments
>>> like...
>>>
>>> django-admin startproject --template=/path/to/template
>>> --extension=py,md,rst,ini,cfg --name=.coveragerc 
>>>
>>> Actually I use this `startproject` feature to create 'repository
>>> skeleton' not only django's project directory.
>>> 'repository skeleton' contains like README.md, tox.ini, .coveragerc, and
>>> django's project direcotry and so on.
>>>
>>> I know this usage of `startproject` is little tricky. but I think some
>>> of django users use like this and
>>> want this `.djangorc` feature (not to pass a lot of argument).
>>>
>>> ## Proposal
>>>
>>> `.djangorc` will contain some of this.
>>>
>>> ```
>>> [startproject]
>>> extension=py,md,rst,ini,cfg
>>> name=.coveragerc
>>> ```
>>>
>>> and If some project template contains this file, startproject command
>>> follow this config on creation process.
>>>
>>> How do you think about it?
>>> It's just my idea and there's no implementation.
>>> I want your feedback, thank you.
>>>
>>>  --
>> You received this message because you are subscribed to a topic in the
>> Google Groups "Django developers (Contributions to Django itself)" group.
>> To unsubscribe from this topic, visit
>> https://groups.google.com/d/topic/django-developers/mOMTohdfVOI/unsubscribe
>> .
>> To unsubscribe from this group and all its topics, 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.
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/django-developers/c4da9a61-fc06-4992-acff-12db064c91de%40googlegroups.com
>> 
>> .
>>
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>  --
> 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 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.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/CAPYpbLUWr2sPtyS8V7KwrgbyBnxs-Mko%2B_3dendHY-y-a3eEhQ%40mail.gmail.com
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>

-- 
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 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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAMwjO1FE1Eq1r4D6Gzyvt93u0Z7FY5BLajFKo1cq8MMaDXC%2BoQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [django.contrib.postgres] Would this be accepted and how hard would it be to do?

[Marc Tamlyn]

In that case the ability to support it would depend on the support in
psycopg2 and how safe we consider their implementation.

Marc
On 29 Jun 2015 16:01, "Collin Anderson"  wrote:

> I think XMLField was removed because the security of xml parsing and
> validating is hard to get right.
>
> On Sunday, June 28, 2015 at 7:51:22 PM UTC-4, Russell Keith-Magee wrote:
>>
>>
>> On Mon, Jun 29, 2015 at 7:32 AM, Josh Smeaton 
>> wrote:
>>
>>> I'm not quite up to date on XML in databases (I've never had to use XML
>>> in a database), but don't the majority of core backends support XML in some
>>> way? If so, I'd probably like to see an attempt to build out XML support
>>> such that all/most core databases could benefit from the new feature,
>>> rather than being locked away in contrib.postgres.
>>>
>>
>> Heh...
>>
>>
>> https://github.com/django/django/blob/stable/1.3.x/django/db/models/fields/__init__.py#L1135
>>
>> So, to answer your questions:
>>>
>>> Is this a project that;
>>> a) would be accepted - Probably, if someone were to implement it and
>>> drive it until quality was acceptable
>>> b) would be fairly straight forward and - I'm not sure how
>>> straightforward it would be. The addition of Lookups and Transforms will
>>> help tremendously though.
>>> c) would be useful to the wider community? - Not for me personally, but
>>> I'm sure there'd be others that would find good use for XML support.
>>> Hopefully we can get some more feedback to accurately determine that though.
>>>
>>
>> Broadly, I agree with Josh.
>>
>> Given that we have contrib.postgres, we should be aiming at 100% coverage
>> of PostgreSQL features in core (not saying that is possible or likely, but
>> it's an aspirational goal).
>>
>> In cases where it is plausible to implement a feature for all backends,
>> we should aim to do that.
>>
>> However, I don't think we should be cross platform at all costs. It would
>> be possible to implement XMLField as a light layer over TextField (hey - we
>> used to do exactly this), but if that's the only way to implement it, I
>> don't think we should implement it at all. I'm not in favour of
>> implementing known-to-be-slow design patterns for core features. Unless
>> SQLite and MySQL offer a native XML data type, with reasonably rich query
>> syntax, then I don't think a cross-platform is desirable.
>>
>> Yours,
>> Russ Magee %-)
>>
>>  --
> 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 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.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/72777a63-a357-44ba-a067-34a7a4af1b1f%40googlegroups.com
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>

-- 
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 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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAMwjO1ECgJ40qT-qAdzQV5vravjKduj5Aeywf6gMEsxb-tM%3D%3DA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Inheritance in admin classes

[Marc Tamlyn]

It's a symptom of the poor design of ModelAdmin (especially compared to
View). It is just "normal" python classes, but it has methods on it which
feel request specific so it's very easy to fall into the trap of thinking
of it as a request level object not a process level object. Model
instances, form instances, view instances etc are all request level, so
it's natural to assume that modeladmin would match that. In fact it
doesn't, and there's an easy class of user bugs you can create by setting
things onto `self` in modeladmin methods (or in this case modifying
something on self) and it leaks to following requests.

I don't think is a trivial issue to fix, the correct approach would be that
we have a request level object with a slightly different level of
abstraction I think - making the entire ModelAdmin request level would be
problematic as it is instantiated to (for example) work out which models
are available in the admin and which URLs exist - data which should be
stored at process level.

Fixing this specific issue may be possible, but it's a band aid for a
broken leg...

Marc

On 2 July 2015 at 13:56, Collin Anderson  wrote:

> Hi All,
>
> It seems to me this is just how class inheritance works in Python. Nothing
> special in Django here, it just might not be intuitive.
>
> I do think deepcopy has too much overhead to warrant a deepcopy by default
> in Django for everyone, but it may help you to use it in your code.
>
> Collin
>
> On Thursday, July 2, 2015 at 6:46:37 AM UTC-4, Jani Tiainen wrote:
>>
>> Hi,
>>
>> I had my fun when I tried to add more inline stuff to a Admin form, and I
>> ended up doing thiskind of stuff:
>>
>>
>> https://janimagik.wordpress.com/2015/05/05/django-admin-and-inline-chaining/
>>
>> I guess problem is how Django admin uses metaclass to do some magic
>> behind the scenes.
>>
>> On Thu, 2 Jul 2015 03:30:59 -0700 (PDT)
>> kny...@knyg.ht wrote:
>>
>> > I think it could be - if not the exact same issue - one that would be
>> fixed
>> > by the same patch. My specific use case is something like this:
>> >
>> > class MyUserAdmin(UserAdmin):
>> > def get_fieldsets(self, request, obj=None):
>> > fieldsets = super().get_fieldsets(request, obj)
>> > fieldsets[0][1]['fields'] = list(fieldsets[0][1]['fields'])
>> > fieldsets[0][1]['fields'].append('category')
>> >
>> > which is already pretty ugly, but needs uglifying further:
>> >
>> > class MyUserAdmin(UserAdmin):
>> > def get_fieldsets(self, request, obj=None):
>> > fieldsets = super().get_fieldsets(request, obj)
>> > fieldsets[0][1]['fields'] = list(fieldsets[0][1]['fields'])
>> >
>> > if 'category' not in fieldsets[0][1]['fields'][-1]:
>> > fieldsets[0][1]['fields'].append('category')
>> >
>> > Logically, they could be the same issue, but I haven't dug in to see if
>> > this is the case. Is it really the case that the overhead of deepcopy()
>> is
>> > too much here?
>> >
>> >
>> > On Thursday, July 2, 2015 at 2:33:24 AM UTC+1, Tim Graham wrote:
>> > >
>> > > Could it be https://code.djangoproject.com/ticket/22828 ?
>> > >
>> > > On Wednesday, July 1, 2015 at 5:32:48 PM UTC-4, kny...@knyg.ht
>> wrote:
>> > >>
>> > >> Hello all,
>> > >>
>> > >> So, I was talking to kezabelle on IRC some months back about a
>> problem I
>> > >> was having, and finally remembered to post something.
>> > >>
>> > >> If I inherit from an admin class, and override something like
>> > >> get_fields(), I was getting back duplicates of fields if I used
>> super() to
>> > >> get the existing fields and add to them. And if I reload the page, I
>> would
>> > >> get more and more fields until I restarted the dev server. Something
>> about
>> > >> ModelAdmin being one instance per process. It seems very
>> counter-intuitive
>> > >> to me, and I was wondering if anyone was considering fixing this?
>> I'm under
>> > >> the impression it might be some work to do.
>> > >>
>> > >> Cheers,
>> > >> Tom
>> > >>
>> > >
>> >
>> > --
>> > 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 it, send
>> an email to django-develop...@googlegroups.com.
>> > To post to this group, send email to django-d...@googlegroups.com.
>> > Visit this group at http://groups.google.com/group/django-developers.
>> > To view this discussion on the web visit
>> https://groups.google.com/d/msgid/django-developers/bd375dce-428f-4ca3-a2bc-2533f47134db%40googlegroups.com.
>>
>> > For more options, visit https://groups.google.com/d/optout.
>>
>>
>> --
>> Jani Tiainen
>>
>  --
> 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 it, send an
> email to django-developers+unsubscr...@googlegroups.com.
> To post to this group, send email to

Re: Django 1.9 - JSONField

[Marc Tamlyn]

Agreed, as other databases catch up with the feature set offered in
contrib.postgres I think moving this field into core is likely - it's a
field that a number of databases are working on adding. It's worth noting
that the PG implementation is 9.4+ only, the 9.2/9.3 implementation of json
should not be used.

There are many suitable third party apps which do a simple dumps/loads
around a text blob. There isn't really any benefit in adding this to core
in my opinion.

On 7 July 2015 at 15:38, Michael Manfre  wrote:

> The django-contrib-postgres JSONField takes advantage of JSON being a
> native type that allows it's data fields to be used by the ORM, instead of
> just a text field that wraps json.dumps() and json.loads(). All of the core
> supported backends seem to have some flavor of native JSON support (MS SQL
> is adding native JSON in SQL Server 2016). I haven't investigated whether
> or not they could be sanely implemented as a common field. That might be a
> worthwhile change to target for Django 1.10, guarded by a DatabaseFeature
> for all of the earlier versions of each database that don't support it.
>
> Regards,
> Michael Manfre
>
>
> On Tue, Jul 7, 2015 at 9:57 AM,  wrote:
>
>>
>> Hi all,
>>
>> I'd like to know why this feature will be only available on postgres and
>> not as a Field for any database, like this product? This Field would be
>> very usefull for many users I think.
>>
>> https://github.com/bradjasper/django-jsonfield
>>
>>
>> https://docs.djangoproject.com/en/dev/releases/1.9/#django-contrib-postgres
>>
>> By.
>>
>> Enviado via UCSMail.
>>
>> --
>> 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 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.
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/django-developers/0459e983-7098-475c-9e3f-14a076513f4a%40googlegroups.com
>> 
>> .
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>
>
> --
> GPG Fingerprint: 74DE D158 BAD0 EDF8
> keybase.io/manfre
>
> --
> 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 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.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/CAGdCwBtTHj6dVgnUO2z_jojwRBMYwZT5YGWQxTdf1%2B7X3yBTmA%40mail.gmail.com
> 
> .
>
> For more options, visit https://groups.google.com/d/optout.
>

-- 
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 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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAMwjO1FtEpseeOOJsAob9t-nA6okRVj3J8uBXD%2BnB26QABdL2A%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: And again about permission to view

[Marc Tamlyn]

A general can_view permission not respected by the admin is not a good idea.

However an easy way to add a general permission to every model in the
system in one go would be interesting - a hook into
https://github.com/django/django/blob/7da3923ba0c569aa23d0ab0a47a124af60a18f5b/django/contrib/auth/management/__init__.py
somehow which allows a couple of lines to add you automatic "can_view", but
could also be useful for a general "can_escalate_to_legal", "can_unarchive"
or whatever domain specific logic is relevant to most models in a system
without having to explicitly add it for every model.

On 8 July 2015 at 05:37, Григорий Крамаренко  wrote:

> Whether I don't understand you, or you me.
>
> Permissions in the admin work on the principle of:
>
> access = is_stuff and True in (add_perm, change_perm, delete_perm)
>
> "view" absolutly not affect to the admin panel, just as do not affect to
> it other custom permissions.
> Take a look at this permission as a custom, but installed by default for
> all models.
> Don't think of it as the permissions for the admin.
> This permission is for writing business applications or complex web-sites
> using Django. Using more serious administrative panel than contrib.admin.
> Let's write this clearly in the documentation. And just.
>
> P.S.: Who would want to use "view" in contrib.auth - do it youself. It
> will be very easy.
>
> среда, 8 июля 2015 г., 1:54:53 UTC+10 пользователь Florian Apolloner
> написал:
>>
>> It absolutely does, cause if you assign the "view" permission to a user
>> he should be able to see the changelist, which wouldn't be the case, see
>> https://github.com/django/django/blob/master/django/contrib/admin/options.py#L1447-L1448
>> -- similar issues would pop up on the app overview etc…
>>
>  --
> 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 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.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/39249ee0-b10b-4ee9-b7bb-ee8aac39e374%40googlegroups.com
> 
> .
>
> For more options, visit https://groups.google.com/d/optout.
>

-- 
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 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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAMwjO1HryB9Ygec%3DoS6%3Dhw2rfKecrsLR%3DHPTdYYJMmy7DQfKsQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: URL dispatcher API

[Marc Tamlyn]

+100 for django.urls. resolving and reversing functions should be located
in the same namespace.

M
On 10 Jul 2015 15:55, "Marten Kenbeek"  wrote:

> Hi James,
>
> Thanks for taking a look at this, I really appreciate it.
>
> *Major bug:* the `request` object needs to be passed into `resolve()`
>> here:
>> https://github.com/knbk/django/blob/4a9d2a05bb76c9ad996921b9efadd8dad877540e/django/core/handlers/base.py#L134
>> - otherwise host and scheme constraints cannot work. I believe there are
>> other instances of `resolve()` not getting `request`, but mostly in tests.
>> Is there a way for `request` to be a required parameter instead of
>> defaulting to `None`?
>>
>
> Damn... I'll fix this asap. I haven't implemented any request-based
> constraints yet, which allowed this to slip through without any test
> failures. I'm afraid I can't just make `request` a required parameter, as
> it needs to maintain backwards compatibility. With that said, the current
> function signature of `resolve()` is just... awkward. One option is to
> change it to `resolve(request_or_path, urlconf=None)`, and get the
> path_info from the request if a request is supplied. `resolve()` might
> still be called in a context where there is not request available, so I
> think we need to maintain the ability to resolve just the path.
>
>
>> *Minor bug:* Given two subdomains, my.example.com and localhost:8000,
>> going to a url using the 'localhost:8000' subdomain that only exists on
>> the 'my' subdomain (ie. http://my.example.com/test3/ exists, but you try
>> to go to http://localhost:8000/test3/), the debug mode 'patterns tried
>> list' is a series of blank lines. See image below:
>>
>
> I would've expected at least the regexes here. I'll look into this.
>
> *​Nice to have:* When attempting to use multiple constraints (ie. list or
>> tuple of constraints), using `RegexPattern` seems to be required when
>> doing pattern matching - otherwise it messes up while calling `construct`.
>> First glance says this is by design? I think it would be nice to still be
>> able to use the old r'' (without wrapping in `RegexPattern`)
>> syntax as well. Not critical, as the multi-constraints is NOT breaking
>> behaviour, just new.
>>
>
> Yes, this is more or less by design. While in the case of a single
> constraint it's nice and concise. Once you use a list of constraints you'll
> have to start counting brackets to see if that string is a RegexPattern or
> a parameter to another constraint, or you'll put each constraint on a new
> line and it doesn't matter as much imo. It isn't set in stone, so if you
> have any compelling arguments to change this, let me know.
>
>
>> *Nice to have:* I realise this isn't likely to happen at all, but it
>> would be nice if when `reverse()` and `{% url %}` are called, it would be
>> good to be able to automatically drop the scheme and host when
>> reconstituting an absolute URL if the scheme and host of the current
>> request match.  However, I'm pretty sure that this is not possible, given
>> the various scenarios in which these methods can be called. Obviously, this
>> is not required, as the resulting URL (with scheme/host or without when
>> matching) will still work regardless!
>>
>
> I'll probably implement something like this before it is merged. I've been
> struggling to implement the `URL` class in a way that provided such methods
> in a way that fully conformed RFC 3986, but it was taking up too much of my
> time and I dropped it for now. I'm not sure I'll get it to conform to RFC
> 3986, but I'll surely write some basic implementation to output urls
> relative to the current host and scheme. Of course it won't cover 100% of
> the cases as the "current" host and scheme are not always available, but in
> the basic cases it should be doable.
>
> Op vrijdag 10 juli 2015 15:21:36 UTC+2 schreef Tim Graham:
>>
>> Marten, did you consider putting the new API in `django.urls` instead of
>> `django.core.urls`? I don't need there's a need to namespace it under
>> "core", but others might be able to confirm the philosophy behind this.
>>
>
> That's certainly worth considering, in fact, I quite like the idea. If
> there are no objections (philosophical or otherwise) I'll move it to
> `django.urls`.
>
> Marten
>
> --
> 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 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.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/a8174a99-2364-4e52-9368-320e94810c62%40googlegroups.com
> 
> .

Re: Proposal: deprecate and remove egg template loader

[Marc Tamlyn]

+1

On 12 July 2015 at 15:53, James Bennett  wrote:

> There's not much to this, really, except what's in the subject line of
> this message.
>
> The problem of providing a single-file, no-build-step format for
> distributing and installing Python packages has been solved by wheels, and
> wheels also don't cause the pile of weirdness that comes with using eggs.
>
> So Django should really stop encouraging/supporting the use of eggs. At a
> minimum, this should involve Django 1.9 starting the deprecation process
> for the egg template loader, and any other parts of Django which contain
> special-case workarounds to deal with eggs.
>
> --
> 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 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.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/CAL13Cg-Y8OXrJvF%2BeXof9v0uBKCJ76owqH4dMzrShVKwVoLxUg%40mail.gmail.com
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>

-- 
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 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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAMwjO1H4228j0SBHE32HVrn7YzHMipv_XtP1EU%2BG-c1BLFwOUw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Major features for 1.9

[Marc Tamlyn]

That one has already landed

On 17 July 2015 at 18:43, Christian Schmitt 
wrote:

> Didn't you missed jsonb from Marc Tamlyn aswell? It's one of the greatest
> features for Postgresql
>
> Am Freitag, 17. Juli 2015 19:19:38 UTC+2 schrieb Tim Graham:
>>
>> Currently we have two items on the roadmap:
>> https://code.djangoproject.com/wiki/Version1.9Roadmap
>>
>> PostgreSQL Full Text Search <https://github.com/django/django/pull/4726>
>> (Marc Tamlyn)
>> Custom indexes <https://github.com/django/deps/pull/6> (Marc Tamlyn)
>>
>> Hopefully we can add Marten's URLs GSoC project to this list.
>>
>> I removed composite fields as Thomas indicated he doesn't plan to
>> continue work on it.
>>
>> We have about two months until the alpha feature freeze (planned for
>> September 21). If anyone is planning any ambitious patches, let us know!
>>
>  --
> 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 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.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/db629ea7-cdb0-4951-b52c-98dd1cf24485%40googlegroups.com
> <https://groups.google.com/d/msgid/django-developers/db629ea7-cdb0-4951-b52c-98dd1cf24485%40googlegroups.com?utm_medium=email&utm_source=footer>
> .
>
> For more options, visit https://groups.google.com/d/optout.
>

-- 
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 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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAMwjO1EF%3DA_%3DCLnWH5f4kfx-fwt%2BDtCN0oFd2quUFMBE9fYtbg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: A modest proposal - more blocks in admin templates

[Marc Tamlyn]

I actually think documenting which blocks we have is a good way to be able
to change them ironically - we currently don't allow much change in admin
templates to avoid breakage elsewhere, this would give us at least a way to
say "the HTML generated in block X in template Y is changing". There could
be backwards compat switch available for a couple of versions potentially
at the modeladmin or adminsite level.

On 24 July 2015 at 15:55, Tim Graham  wrote:

> I'd start small, for example, by fixing the existing ticket I pointed out
> and any others that are related. Create a new ticket for any other changes.
>
> I think there might be a tiny performance penalty to parsing blocks
> (someone else can probably speak better to this). Also, too many blocks
> might cause difficulties with backwards compatibility if we need to
> restructure things in the future. Those are the only controversial points I
> can think of. Send a pull request after changing a few templates so we can
> get a flavor and see if you are on the right track.
>
> We don't have a big problem with trivial patches like this languishing.
>
>
> On Friday, July 24, 2015 at 10:43:38 AM UTC-4, Andy Baker wrote:
>>
>> In terms of increasing the likelihood of a patch that will get merged:
>>
>> 1. Is it better to leave the documentation issue to one side for now?
>> 2. Would it be better to tackle a subset of the admin templates first or
>> is it better to try and swallow this whole?
>> 3. Would a core committer need to adopt this to make sure it doesn't
>> languish?
>>
>> On Friday, 24 July 2015 14:51:44 UTC+1, Tim Graham wrote:
>>>
>>> As in something like, "We won't make changes to template blocks without
>>> a mention in the release notes."? If we need to make a change for a good
>>> reason, I am not sure what a deprecation would look like, if at all
>>> possible.
>>>
>>> On Friday, July 24, 2015 at 9:37:18 AM UTC-4, Collin Anderson wrote:

 The documentation could give better backwards compatibility guarantees.

 On Friday, July 24, 2015, Tim Graham  wrote:

> There is at least one ticket about adding more blocks to the admin
> templates: https://code.djangoproject.com/ticket/14810
>
> You can browse the "contrib.admin" component in Trac to find related
> issues:
> https://code.djangoproject.com/query?status=assigned&status=new&component=contrib.admin&stage=Accepted&page=2&col=id&col=summary&col=status&col=owner&col=type&col=version&desc=1&order=id
>
> I am not sure how much value documentation would be as it seems if you
> are overriding the template, you will probably need to look at the whole
> thing anyway.
>
> On Friday, July 24, 2015 at 5:35:28 AM UTC-4, Andy Baker wrote:
>>
>> Happy to do some work on this but wanted to get some feedback first.
>>
>> Loose methodology:
>>
>> 1. Skim the most popular admin extensions that exist on
>> django-packages etc
>> 2. Look out for places where they've had to copy entire admin
>> templates to only override a small part
>> 3. Add new {% blocks%}  into the original templates where there
>> appears to be a demonstrable need.
>>
>> Additionally - would there be some value in a new page in the docs
>> listing admin templates and their respective blocks?
>>
>  --
> 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 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.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/2ecc568c-0aa9-4a67-af31-f8c877699c92%40googlegroups.com
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>
  --
> 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 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.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/992b0be7-7d38-4600-aa51-2463aa9fe915%40googlegroups.com
> 
> .
>
> For more options, visit https://groups.google.com/d/optout.
>

-- 
Y

Re: Django Admin New Look

[Marc Tamlyn]

Font Awesome is not GPL - the code is MIT and the font itself is SIL OFL
both of which are fine to include with Django.

On 29 July 2015 at 12:13, elky  wrote:

> Hi guys,
>
> I'm glad to say I finished work on replacing image icons with font. I used 
> Font
> Awesome  (GPL licence) kit to
> do it.
>
> I'll appreciate if you test new icons in your project and report any
> issues here . You can
> do it by running:
> pip install git+https://github.com/elky/django-flat-theme.git@flat-icons
> --upgrade
>
> There are couple of questions I wanna discuss in this thread:
>
> 1. Font Awesome kit contains about 600 icons - obviously we don't need all
> of them in Django. I can create small kit which will contain only icons
> that used in the project - it will allow us to save about 70KB. But the
> question is - how to support this kit in future if someone decide to add
> new icons?
>
> 2. Do we support IE8 and less? If yes - I'll need to add additional font
> files.
>
> Thank you,
> Alex D.
>
>  --
> 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 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.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/849a70d3-3157-4491-b74e-f504fea891f7%40googlegroups.com
> 
> .
>
> For more options, visit https://groups.google.com/d/optout.
>

-- 
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 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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAMwjO1F%3D5xHz_ZuJksKFj-naJasd%2Bxm5k70kVgihwpR_eip3ow%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: default values on database level

[Marc Tamlyn]

Debatably this situation should throw an error at model validation time -
assuming the expression does error out when trying to build that database.
Otherwise it will error at migrate time.

I would like this - it would be very good for UUID as PK

On 29 July 2015 at 16:42, Podrigal, Aron  wrote:

> Hi Loic,
>
> Agree with having a db_default kwarg.
>
> I am not using multiple databases so no experiance with db routers. So how
> would should we handle routing between different databases when the
> db_default value is not compatible with that backend? for example
> Model.save(using='mysql_db') should we than use the Field.default to
> generate the default value (which is not how it works today, that the
> default is computed at instance creation). I would prefer in such a case to
> rely on the database to handle the situation by omitting that field from
> the columns list, so mysql for example would set a non nullable varchar
> column to an empty string, where with other databases it would cause an
> IntegrityError exception. and that db_default and default kwargs cannot be
> used togethor.
> On Jul 29, 2015 1:55 AM, "Loïc Bistuer"  wrote:
>
>> Hi Aron,
>>
>> +1 on db defaults as well, I've actually started experimenting on this
>> last week. It's a bit tricky because migrations do use db defaults in some
>> operations (and drop them once they are done) so we have to ensure that the
>> new feature doesn't interfere with them.
>>
>> However I don't think we should create them by default, instead I propose
>> the introduction of a db_default kwarg, which should be either a constant,
>> or an expression (e.g.
>> db_default=contrib.postgres.functions.TransactionNow).
>>
>> Cheers,
>> Loïc
>>
>> > On Jul 29, 2015, at 12:04, Podrigal, Aron 
>> wrote:
>> >
>> > I would like to propose making Fields.default to rely on the database
>> generated defaults where possible. This could be implemented by having
>> some  constants like fields.CURRENT_TIMESTAMP, etc.  The tricky part here
>> is to detect database backend specific capabilities and have a python
>> equivalent fallback.
>> >
>> > Any thoughts?
>> >
>> >
>> > --
>> > 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 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.
>> > To view this discussion on the web visit
>> https://groups.google.com/d/msgid/django-developers/CANJp-yi5%2Bu%3DW8PdUXtcot%2BO8%3Df35dVLbStwVArJhU7gDnaNXoA%40mail.gmail.com
>> .
>> > For more options, visit https://groups.google.com/d/optout.
>>
>> --
>> 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 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.
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/django-developers/125BCDAB-728B-4BAA-A8AB-38BA0842B709%40gmail.com
>> .
>> For more options, visit https://groups.google.com/d/optout.
>>
>  --
> 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 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.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/CANJp-yjsEthdkNQUaUKW3DfgyeigtjyZMYQoGteX%2BQ4MM4uPAw%40mail.gmail.com
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>

-- 
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 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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAMwjO1F_X21yEd8bwaRBEiJASjccAm-RtftJ-9mjgSfn532a-Q%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Django Admin New Look

[Marc Tamlyn]

One thing that might be nice to do with the admin, especially in the
context of the fonts but also with jQuery, is to give an easy override to
use CDN versions of the files. Django still needs to bundle them for
offline work, and the default should be to include Django's own ones, but
it would be good on production sites to use CDNs (probably google, or make
it configurable). It may be that this is more work than it's worth, but as
some of these files, especially jQuery, font awesome and Roboto are widely
used around the internet now many users would already have them cached -
even if it's just from another Django admin.

On 30 July 2015 at 09:55, Aymeric Augustin <
aymeric.augustin.2...@polytechnique.org> wrote:

> Le 29 juil. 2015 à 13:13, elky  a écrit :
> >
> > I can create small kit which will contain only icons that used in the
> project - it will allow us to save about 70KB. But the question is - how to
> support this kit in future if someone decide to add new icons ?
>
> Indeed, it could be difficult to maintain in the medium term.
>
> If I remember correctly, the new theme already adds ~300kB of fonts.
> Saving 70kB of icons doesn't change that much.
>
> Shipping the entire set sounds easier at this point.
>
> --
> Aymeric.
>
> --
> 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 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.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/89C4715B-4CED-469F-A5D7-2F3251CB3AD5%40polytechnique.org
> .
> For more options, visit https://groups.google.com/d/optout.
>

-- 
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 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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAMwjO1E0grw%3D3MVo6i81mt%2BfmrYn7UZ9dK_FO7%3D3gXAPuSZVVA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: future of QuerySet.extra()?

[Marc Tamlyn]

I don't know about unmaintained, but I think there's a consensus that
.extra() has a horrible API and we should do away with it eventually. That
said I think there are still enough things that can't be done without it at
present. A lot fewer now we have expressions, but still some.

I'd be happy to put a moratorium on improving it, but we can't deprecate it
yet.

On 31 July 2015 at 18:58, Tim Graham  wrote:

> In light of the new expressions API, the idea of deprecating
> QuerySet.extra() has been informally discussed in IRC and elsewhere. I
> wonder if there is consensus to mark extra() as "unmaintained" and to
> suggest filing feature requests for functionality that can be performed
> through extra() but not through other existing QuerySet methods? There are
> at least several tickets (examples below) of edge cases that don't work
> with extra(). It seems like a waste of time to leave these tickets as
> accepted and to triage new issues with extra() if they won't be fixed.
>
> https://code.djangoproject.com/ticket/24142
> https://code.djangoproject.com/ticket/19434
> https://code.djangoproject.com/ticket/12890
>
> --
> 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 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.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/6e1be326-3b17-49ca-accf-03eec5ad41ef%40googlegroups.com
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>

-- 
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 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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAMwjO1EL3TMnP%2BrtkKDMt1%3D8wwXpRV%2Btfn%3DRQA5tYC0bkQzMAw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: future of QuerySet.extra()?

[Marc Tamlyn]

Sounds good to me.

On 31 July 2015 at 21:00, Tim Graham  wrote:

> I had in mind a documentation note like this:
>
> Use this method as a last resort
>
>
> This is an old API that we aim to deprecate at some point in the future.
> Use it only if you cannot express your query using other queryset methods.
> If you do need to use it, please file a ticket with your use case so that
> we can enhance the QuerySet API to allow removing extra(). We are no
> longer improving or fixing bugs for this method.
>
> On Friday, July 31, 2015 at 2:07:34 PM UTC-4, Collin Anderson wrote:
>>
>> I wonder if there's a way in the docs we can deprecate it as in "we don't
>> recommend you use it", but not actually schedule it for removal.
>>
>> On Friday, July 31, 2015 at 2:01:20 PM UTC-4, Marc Tamlyn wrote:
>>>
>>> I don't know about unmaintained, but I think there's a consensus that
>>> .extra() has a horrible API and we should do away with it eventually. That
>>> said I think there are still enough things that can't be done without it at
>>> present. A lot fewer now we have expressions, but still some.
>>>
>>> I'd be happy to put a moratorium on improving it, but we can't deprecate
>>> it yet.
>>>
>>> On 31 July 2015 at 18:58, Tim Graham  wrote:
>>>
>>>> In light of the new expressions API, the idea of deprecating
>>>> QuerySet.extra() has been informally discussed in IRC and elsewhere. I
>>>> wonder if there is consensus to mark extra() as "unmaintained" and to
>>>> suggest filing feature requests for functionality that can be performed
>>>> through extra() but not through other existing QuerySet methods? There are
>>>> at least several tickets (examples below) of edge cases that don't work
>>>> with extra(). It seems like a waste of time to leave these tickets as
>>>> accepted and to triage new issues with extra() if they won't be fixed.
>>>>
>>>> https://code.djangoproject.com/ticket/24142
>>>> https://code.djangoproject.com/ticket/19434
>>>> https://code.djangoproject.com/ticket/12890
>>>>
>>>> --
>>>> 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 it, send
>>>> an email to django-develop...@googlegroups.com.
>>>> To post to this group, send email to django-d...@googlegroups.com.
>>>> Visit this group at http://groups.google.com/group/django-developers.
>>>> To view this discussion on the web visit
>>>> https://groups.google.com/d/msgid/django-developers/6e1be326-3b17-49ca-accf-03eec5ad41ef%40googlegroups.com
>>>> <https://groups.google.com/d/msgid/django-developers/6e1be326-3b17-49ca-accf-03eec5ad41ef%40googlegroups.com?utm_medium=email&utm_source=footer>
>>>> .
>>>> For more options, visit https://groups.google.com/d/optout.
>>>>
>>>
>>> --
> 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 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.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/7c1568b6-f7f1-4aab-9263-af447e45af45%40googlegroups.com
> <https://groups.google.com/d/msgid/django-developers/7c1568b6-f7f1-4aab-9263-af447e45af45%40googlegroups.com?utm_medium=email&utm_source=footer>
> .
>
> For more options, visit https://groups.google.com/d/optout.
>

-- 
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 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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAMwjO1FQAJqrXu3HcSpP3xDF%2BA%3DsyG%3DHP90V%3DzrKBHJ%3Dg%3DcfDg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.