Re: status of 1.8 release blockers

2015-02-18 Thread Loïc Bistuer
>From my point of view #24351 is ready for a final sanity check and merging.

-- 
Loïc

> On Feb 19, 2015, at 10:10, Tim Graham  wrote:
> 
> 3 issues remain. I haven't confirmed with the owners, but it seems to me 
> there may be a good chance to wrap them up tomorrow.
> 
> 
> #24351  RunPython/RunSQL operations in contrib migrations and 
> multi-db routers.
> Owner: Loic
> Status: In review.
> 
> 
> #24328 The new Options._get_fields() method needs to be cleaned up
> Owner: Anssi
> Status: In review.
> 
> #24343 UUID foreign key accessor returns inconsistent type
> 
> Owner: Marc
> Status: Marc to polish patch.
> 
> -- 
> 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/170625d3-1bb5-4b9d-ab74-501fd5dea86b%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/136699C8-42D8-47E9-B0A6-78C8E7BA96A3%40gmail.com.
For more options, visit https://groups.google.com/d/optout.


Re: status of 1.8 release blockers

2015-02-18 Thread Tim Graham
3 issues remain. I haven't confirmed with the owners, but it seems to me 
there may be a good chance to wrap them up tomorrow.


#24351    RunPython/RunSQL 
operations in contrib migrations and multi-db routers. 
Owner: Loic
Status: In review.


#24328  The new 
Options._get_fields() method needs to be cleaned up 

Owner: Anssi
Status: In review.

#24343  UUID foreign key 
accessor returns inconsistent type 
Owner: Marc
Status: Marc to polish patch.

-- 
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/170625d3-1bb5-4b9d-ab74-501fd5dea86b%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: Formalizing template loader and debug api's

2015-02-18 Thread Preston Timmons


> In that case, would it be possible to do the caching improvements before 
> the main
> refactoring? I'm trying to keep patches at a reviewable size :-)
>
> -- 
> Aymeric.
>

Maybe. The existing loaders don't provide a nice way to add 
Origin.uptodate. It would
require an informal hack that only supported Django builtin loaders 
initially.

I'll start by separating out some of the cleanup/groundwork changes I did 
into separate
PRs. If those can go in first, then there'll be a lot less noise in the 
patch.

At the moment, I think it will be easiest to land the cache improvements 
after the
loaders are updated.

-- 
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/db492cc9-082c-4d76-9a8f-3aff14b5d018%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: Signature of the allow_migrate database router.

2015-02-18 Thread Aymeric Augustin
2015-02-18 14:07 GMT+01:00 Loïc Bistuer :

> Individual routers don't have a base class but we can add it to the master
> router `django.db.router`. I've updated the PR with a
> `router.allow_migrate_model` method. I don't know if we should document
> this just yet.
>

Good. Unless I missed something that's an implementation detail. There's no
need to document it.


> Internally we now treat anything other than `app_label` as a hint, but I
> guess we should still document `model_name=None` as part of the official
> signature.
>

Yes.


> Speaking about `model_name`, it seems to be the lowercase version of
> `_meta.object_name` (which is basically __name__). I didn't investigate
> further, can you confirm that `_meta.model_name` is what we want?
>

The alternative is model._meta.object_name. object_name is __name__ and
model_name is object_name.lower().

Since model_name should be treated as case-insensitive — that's how Django
works, most likely for no good reason — passing the lowercase version is
less error-prone. If the developer doesn't account for case insensitivity,
their code will fail immediately, since model class names are usually
written in CamelCase.

-- 
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/CANE-7mUM-SEzfBR0S_CtCvhVNbd45%3DfC2F2aoDcim%3D2hX_GkoA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.


Re: Signature of the allow_migrate database router.

2015-02-18 Thread Marten Kenbeek
Loïc, the model_name is indeed the lower-case version of the 
object_name: 
https://github.com/django/django/blob/master/django/db/models/options.py#L203

On Wednesday, February 18, 2015 at 2:07:28 PM UTC+1, Loïc Bistuer wrote:
>
> Individual routers don't have a base class but we can add it to the master 
> router `django.db.router`. I've updated the PR with a 
> `router.allow_migrate_model` method. I don't know if we should document 
> this just yet. 
>
> Internally we now treat anything other than `app_label` as a hint, but I 
> guess we should still document `model_name=None` as part of the official 
> signature. 
>
> Speaking about `model_name`, it seems to be the lowercase version of 
> `_meta.object_name` (which is basically __name__). I didn't investigate 
> further, can you confirm that `_meta.model_name` is what we want? 
>
> > On Feb 18, 2015, at 15:41, Aymeric Augustin <
> aymeric@polytechnique.org > wrote: 
> > 
> > 2015-02-18 6:34 GMT+01:00 Loïc Bistuer  >: 
> > Another option would be to make the signature `allow_migrate(self, db, 
> app_label, model_name=None, **hints)` and to put the model class in the 
> hints dict, the same way we pass `instance` as hint to the other routers. 
> > 
> > Yes, that's what I wanted to suggest after Andrew confirmed my suspicion 
> that we have to account for historical models. 
> > 
> > Perhaps the following convenience function can help factoring out the 
> arguments in the common case: 
> > 
> > def allow_migrate_model(router, db, model): 
> > return router.allow_migrate(db, model._meta.app_label, 
> model._meta.model_name, model=model) 
> > 
> > (This isn't a router method because there isn't a base class for 
> routers.) 
> > 
> > -- 
> > 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-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/CANE-7mVJpobigSdmEQt1NdkXOyjDWdPoEZJz4TVdVDeG9g%2BS2w%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/9e07c5d3-7706-4873-bb7a-9224af94c35f%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: Signature of the allow_migrate database router.

2015-02-18 Thread Loïc Bistuer
Individual routers don't have a base class but we can add it to the master 
router `django.db.router`. I've updated the PR with a 
`router.allow_migrate_model` method. I don't know if we should document this 
just yet.

Internally we now treat anything other than `app_label` as a hint, but I guess 
we should still document `model_name=None` as part of the official signature.

Speaking about `model_name`, it seems to be the lowercase version of 
`_meta.object_name` (which is basically __name__). I didn't investigate 
further, can you confirm that `_meta.model_name` is what we want?

> On Feb 18, 2015, at 15:41, Aymeric Augustin 
>  wrote:
> 
> 2015-02-18 6:34 GMT+01:00 Loïc Bistuer :
> Another option would be to make the signature `allow_migrate(self, db, 
> app_label, model_name=None, **hints)` and to put the model class in the hints 
> dict, the same way we pass `instance` as hint to the other routers.
> 
> Yes, that's what I wanted to suggest after Andrew confirmed my suspicion that 
> we have to account for historical models.
> 
> Perhaps the following convenience function can help factoring out the 
> arguments in the common case:
> 
> def allow_migrate_model(router, db, model):
> return router.allow_migrate(db, model._meta.app_label, 
> model._meta.model_name, model=model)
> 
> (This isn't a router method because there isn't a base class for routers.)
> 
> -- 
> 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/CANE-7mVJpobigSdmEQt1NdkXOyjDWdPoEZJz4TVdVDeG9g%2BS2w%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/A38EDB7A-9099-49A1-B4EA-86BBF393B792%40gmail.com.
For more options, visit https://groups.google.com/d/optout.


Re: Drop the TEMPLATE_DEBUG setting

2015-02-18 Thread Curtis Maloney
Just to chip in here... when TEMPLATE_DEBUG=True the template engine uses a
substantially different Lexer, based on re.finditer() instead of re.split().

There are about 10 hooks in the Parser class, too, that exist almost
exclusively to allow the DebugParser to change behavior.

If we always store the debug information [and do all the other parsing
checks] it's likely the template parsing will become _faster_, just because
of avoiding method calls.

For giggles, I'll run up a fork and see if I can get some meaningful
results from Preston's very welcome template benchmark tool.

--
Curtis


On 17 February 2015 at 16:03, Preston Timmons 
wrote:

> Here are some benchmarks I added here:
>
> https://github.com/prestontimmons/templatebench
>
> This is the cumulative time to do 1000 iterations:
>
> Basic.do_init: 0.1423451900
> BasicDebug.do_init: 0.1941769123
> 35% increase in parsing time
>
> Basic.do_parse_complex: 1.2230978012
> BasicDebug.do_parse_complex: 1.4190740585
> 15.5% increase in parsing time
>
> FileSystem.do_get_template_complex: 1.4923889637
> FileSystemDebug.do_get_template_complex: 1.7524909973
> 17.4% increase in parsing time
>
> FileSystem.do_get_template_index: 0.5193221569
> FileSystemDebug.do_get_template_index: 0.5603711605
> 9.8% increase
>
> If my benchmarks are right, the increase is measurable, although probably
> not enough to notice in most usage of Django templates. Increasing parsing
> time isn't ideal, though, since that's where Django templates seems to
> spend most of their cpu time.
>
>>   --
> 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/9cc2bb2d-0335-4d49-8529-9c3dbdd07467%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/CAG_XiSAtfngAGb9TKhugJuxg%2B6Og50%2BMP3V25kfZACuaMwsqiA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.


Re: Feature proposal: Conditional block tags

2015-02-18 Thread Tino de Bruijn
Hi,

On Tue, Feb 17, 2015 at 9:04 PM, Preston Timmons 
wrote:

> After looking at this, there's nothing special about blocks compared to
> any other node. They could just as well be evaluated at render time.
>
> Here's a branch that implements this change:
>
>
> https://github.com/prestontimmons/django/compare/conditional-blocks?expand=1
>
> Before returning blocks into block_context to be used as overrides, it
> loops through any if nodes and checks the conditions.
>
> The one case that's kinda funny is if you do something like:
>
> {% if var %}
> {% block content %}...{% endblock %}
> {% else %}
> {% block content %}...{% endblock %}
> {% endif %}
>
> Currently, the second block node will raise a TemplateSyntaxError because
> it's defined twice. Does that matter?
>

I don't think it does. The construct is useless anyway. The only use case I
could think of is:

{% if var %}
var specific content
{% block content %}...{% endblock %}
{% else %}
{% block content %}...{% endblock %}
{% endif %}

But that could also be created with the block outside the if statement. You
would probably use it in the sense of "only include this block if", or "if
a, block, else block b". Redefining the content block does not seem to make
sense to me in those cases.

Tino

-- 
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/CANQFsQA-ao9ER0ha7DBjYnRS-PmZsh7rOtp9Kj64GEgOpmj7aQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.


Re: Signature of the allow_migrate database router.

2015-02-18 Thread Aymeric Augustin
2015-02-18 6:34 GMT+01:00 Loïc Bistuer :

> Another option would be to make the signature `allow_migrate(self, db,
> app_label, model_name=None, **hints)` and to put the model class in the
> hints dict, the same way we pass `instance` as hint to the other routers.


Yes, that's what I wanted to suggest after Andrew confirmed my suspicion
that we have to account for historical models.

Perhaps the following convenience function can help factoring out the
arguments in the common case:

def allow_migrate_model(router, db, model):
return router.allow_migrate(db, model._meta.app_label,
model._meta.model_name, model=model)

(This isn't a router method because there isn't a base class for routers.)

-- 
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/CANE-7mVJpobigSdmEQt1NdkXOyjDWdPoEZJz4TVdVDeG9g%2BS2w%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.


Re: Formalizing template loader and debug api's

2015-02-18 Thread Aymeric Augustin
2015-02-17 23:47 GMT+01:00 Preston Timmons :

> It depends. The cached loader is what I'm least happy with in my
> refactoring. This
> internal cache idea I think is simpler, more performant, and easier to
> understand.
> Adding it makes the cached loader changes unnecessary.
>

In that case, would it be possible to do the caching improvements before
the main
refactoring? I'm trying to keep patches at a reviewable size :-)

-- 
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/CANE-7mX3G6XqVLWBi%2BOoLAn%2BKspYmZb8QgOU4oNcvZXyDiXSaQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.