Re: Would AssertMaxQueries (similar to AssertNumQueries) be a useful addition

[Roger Hunwicks]

On Sunday, August 17, 2014 8:39:17 PM UTC+6, James Bennett wrote:
>
> Not sure about the feasibility, though; would you be willing to work up a 
> rough implementation of it?
>

Implementation of the assertion is straightforward, because it can be a 
direct copy of AssertNumQueries with:

self.test_case.assertLessEqual(

  executed, self.num, "%d queries executed, %d or less expected" % (

  executed, self.num

  )

instead of the the assertEqual in AssertNumQueries.

Regarding it's use, I run it with a low default and then make exceptions 
for specific urls that I know have more queries:

max_queries = {'admin:app1_model1_change': 50,

 'admin:app1_model2_add': 100,

 'admin:app2_model1_changelist': 100}



for model in get_models():

  if model in admin.site._registry:

  try:

 if admin.site._registry[model].has_add_permission(type(
"request", (), {"user": user})):

route = "admin:%s_%s_add" % (model._meta.app_label, 
model._meta.module_name)

  url = reverse(route)

  with self.assertMaxQueries(max_queries.get(route, 10
)):

  response = self.client.get(url, follow=True)

I'm happy to create a GitHub pull request for the Assertion and the 
required documentation changes
 

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/3d490eaa-d6a5-4025-b46b-28f14dddfcaf%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: GSoC Meta refactor: Bikeshedding time!!

[Russell Keith-Magee]

Hi Shai,

On Sun, Aug 17, 2014 at 3:44 AM, Shai Berger  wrote:

> Hi,
>
> It seems to me that the taxonomy doesn't handle well FileField and
> ImageField.
> It could be bundled in with ForeignKey (as the data it really represents is
> only pointed at by the related column data), but not with the current
> wording.
>
> For ImageField, there is -- in addition to the above -- the relation to
> height_field and width_field. It would appear to be a mix between a pure
> field
> and a virtual field.
>

I'm not sure this is a problem.

I agree that conceptually, part of the data for a FileField/ImageField is
held "externally"; but it's a different kind of external. From the
database's perspective, the record is complete and correct when you're
storing a string. The fact that the string represents a file system path is
a very significant implementation detail - after all, you need to know to
show a file browsing dialog (or whatever UI you want) - but then, the same
is true of a date field needing a date picker, and a boolean field needing
a checkbox. It doesn't affect the way the database needs to interact with
the data it is storing.

However, this might be a manifestation of the sort of problem Anssi raised
- that the taxonomy I've suggested is too rich, and that we need to
simplify to the practical use cases, rather than try and build a complex
and descriptive API.

Russ %-)

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

Re: GSoC Meta refactor: Bikeshedding time!!

[Russell Keith-Magee]

Hi Anssi,

On Sun, Aug 17, 2014 at 3:06 AM, Anssi Kääriäinen 
wrote:

> On Saturday, August 16, 2014 4:38:30 AM UTC+3, Russell Keith-Magee wrote:
>>
>> b) "Relating" data fields - This means ForeignKey. Fields that manifest
>> as a single column, but represent a relation to another model.
>>
>
> This definition will not work when multicolumn foreign keys are
> introduced. Especially not with the name foreign_key_fields. This would
> either mean that relating data fields do contain fields that have more than
> single backing column, or that foreign_key_fields do not contain all
> foreign key fields.
>
> Michal Petrucha's work on virtual fields aims to make ForeignKeys virtual
> fields - they have one or more backing pure data fields, and then the
> relation is handled by a virtual fields. The work done by him shows that
> this way works well. The patch was actually close to committable already
> during 1.7 development, but as it didn't play well with migrations we had
> to defer it. The point here is that I expect that we will want to make
> ForeignKeys virtual fields soonish. This doesn't play well with the
> categorization.
>

Interesting.


> d) "Relating" external fields - This means ManyToMany fields. Fields that
>> are manifested as an external table, but represent a relation to a
>> different model.
>>
>
> Should we define this category as m2m fields? Calling it
> many_to_many_fields, but defining it as including all external storage
> fields seems a bit problematic.
>

That's exactly what I proposed in my formal naming scheme. I was being
deliberately abstract in the descriptions, but in practice, I agree (d) is
"many_to_many_fields", and the API should say this (unless someone can
think of a good reason why it shouldn't) - like a "relating external field"
that isn't an m2m relation.


> So - firstly, we need a sanity check. Does this taxonomy capture all field
>> types that you can think of? Are there any interpretations of composite
>> fields, or any other esoteric field type (existing or imagined) that don't
>> fit in this taxonomy?
>>
>
> It seems the proposed API has fields in one, and only one category. Maybe
> it would be better to have categorization where fields fall in to multiple
> categories? The categories could be data, virtual, relation,
> reverse_relation and m2m.
>
> For example m2m field would be virtual, related or reverse_related and of
> course m2m. In the future a foreign key would create a backing data field.
> The foreign key itself would be virtual relation field. The reverse side of
> the foreign key would be virtual and reverse_related. GenericForeignKey
> would also be a virtual related field (with two backing data fields).
>

I understand what you're driving at here, and I've had similar thoughts
over the course of the SoC. The catch is that this makes the API for
get_fields() fairly complicated.

If every field fits into one specific type, then get_fields() just requires
a single boolean flag (do I include fields of type X) for each field type.
We can also easily add new field types by adding new booleans to the API.

However, if a field fits into multiple categories, then it's impossible
(or, at least, exceedingly complicated) to make a single call to
get_fields() that will specify all your field requirements. "Get me all
non-virtual data fields" requires "virtual=False, data=True, m2m=False",
but "Get all virtual data fields that represent m2ms" requires
"virtual=True, data=False, m2m=True". You can't pass in both sets of
arguments at the same time, so you either have to make multiple calls to
get_fields(), or you have to invent some sort of query syntax for
get_fields() that allows union queries.

Plus, at the end of the day, get_fields() is abstracted behind highly
cached and optimised properties for key lookups. These properties are
effectively a cached call to get_fields() with a specific set of arguments
- so even if get_fields() doesn't expose a "one category per field"
requirement, the API will require, at some level, names that have clear
(and preferably non-overlapping) membership.

I don't see how a TranslationField would fit into the above categorization.
> A TranslationField is defined as a field that gets a single translation
> from related translations table. So, it is the reverse side of a foreign
> key with an additional restriction on language (in effect generating a join
> condition JOIN article_translations ON article.id =
> article_translations.article_id AND article_translations.language = 'fi').
> At least as defined this isn't in category g as it doesn't return all
> reverse objects of category b. It doesn't fit in to any other category
> either. So, we need some changes to the wording.
>
> As another example we might someday want to allow fully custom join
> condition fields. These fields wouldn't be foreign key, external data nor
> many to many fields nor the reverse of those categories
>
> Comments welcome. Obviously, this has enormous potent

Re: Proposal new Django Admin css style

[Daniel Greenfeld]

Thanks for the mention, but I haven't had time to work or maintain that for 
months. I'm not sure how it works with the upcoming Django 1.7.  Also, for 
the sake of simplicity, the default skin for it is bootstrap 3. Any CSS in 
there is per skin, and probably doesn't belong in this discussion.

On Sunday, August 17, 2014 11:18:33 AM UTC-3, Danilo Bargen wrote:
>
> Just for the record, there's also 
> https://github.com/pydanny/django-admin2, another project that attempts 
> to create a more modular and extensible admin. 
>
> Danilo 
>

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/e5697a3c-aca2-4517-9632-29939bce66c2%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Wiki Home Page

[Russell Keith-Magee]

FYI - I've just made this change (and restored the homepage content again,
which seemed to go missing...)

Yours,
Russ Magee %-)


On Sun, Aug 17, 2014 at 8:55 AM, Russell Keith-Magee <
russ...@keith-magee.com> wrote:

> Hi Colin,
>
> Good suggestion - and kinda obvious now you mention it! I'll make the
> change when I get a chance.
>
> Yours,
> Russ Magee %-)
>
>
> On Sunday, August 17, 2014, Collin Anderson  wrote:
>
>> Hi Russ,
>>
>> I like the new wiki home page. Would it make sense to have a link to
>> Github? People who click "Code" in the top right might be looking for the
>> source code.
>>
>> Thanks,
>> Collin
>>
>>  --
>> 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.
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/django-developers/8bcbd166-b82f-4f13-8efe-ad290494df26%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" 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/CAJxq84_nNFmn5QVqXb6e3TBmKRW-jAT9P-0Tkbgm0pSiAKx0dw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Support HTML5 syntax

[Jesús Lucas Flores]

You can use Django Crispyforms
El 17/08/2014 22:43, "Florian Apolloner"  escribió:

>
>
> On Sunday, August 17, 2014 7:33:17 PM UTC+2, noegry wrote:
>>
>> It might cause issues when templates are using HTML5 syntax but forms are
>> using XHTML syntax?
>>
>
> The forms are not using XHTML syntax per se, they are valid HTML5 and
> valid XHTML!
>
> --
> 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.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/78d2bef3-ff0c-48b5-afd0-8aba233b586f%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" 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/CA%2Bidag%3DWUxGeApMwPx4tu4CDzU%2BU%2BMDuSF7Fmxpp%3DBqCoC6TQQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Would AssertMaxQueries (similar to AssertNumQueries) be a useful addition

[Josh Smeaton]

+1 - useful for user code that guards against accidental poor ORM usage.

On Monday, 18 August 2014 05:47:15 UTC+10, jdunck wrote:
>
> I use this method on my own test subclasses, and I find it useful as a 
> tripwire: a cause for review and consideration, more than a hard error. Did 
> the number of queries go up on this change? Is that reasonable or a 
> mistake? Have we blown the perf budget so we should refactor? Or maybe the 
> number should just be raised to something that seems like a reasonable next 
> tripwire.
>
> These limits aren't flaky or false positives, so they seem useful supports 
> given a reasonable test suite otherwise. 
>
>>
>>  

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/33a1da8e-6ae5-4e14-a829-dc679e95c169%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Support HTML5 syntax

[Florian Apolloner]

On Sunday, August 17, 2014 7:33:17 PM UTC+2, noegry wrote:
>
> It might cause issues when templates are using HTML5 syntax but forms are 
> using XHTML syntax?
>

The forms are not using XHTML syntax per se, they are valid HTML5 and valid 
XHTML!

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/78d2bef3-ff0c-48b5-afd0-8aba233b586f%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Would AssertMaxQueries (similar to AssertNumQueries) be a useful addition

[Jeremy Dunck]

I use this method on my own test subclasses, and I find it useful as a
tripwire: a cause for review and consideration, more than a hard error. Did
the number of queries go up on this change? Is that reasonable or a
mistake? Have we blown the perf budget so we should refactor? Or maybe the
number should just be raised to something that seems like a reasonable next
tripwire.

These limits aren't flaky or false positives, so they seem useful supports
given a reasonable test suite otherwise.
On Aug 17, 2014 8:20 AM, "Florian Apolloner"  wrote:

> I am not so convinced, what would you put in as the upper limit? While
> preventing n+1, it still requires you to know what n in this testcase is
> and changing n can lead to funny errors. Currently we are documenting
> (hopefully) how those query counts come together, so it's clear what's
> happening when it breaks…
>
> On Sunday, August 17, 2014 4:39:17 PM UTC+2, James Bennett wrote:
>>
>> I like the idea -- if nothing else, it would provide an easy way to have
>> a test suite discover N+1 problems, especially in templates.
>>
>> Not sure about the feasibility, though; would you be willing to work up a
>> rough implementation of it?
>>
>  --
> 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.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/41676693-480d-4dfc-82a6-377da0f54057%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" 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/CAM0i3f7nC_hVDwL2MojcQn3Qhex8TGPZnYwdYh%3DTH%2BcWN1yZ6w%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Support HTML5 syntax

[Aymeric Augustin]

Browsers are extremely good at parsing whatever gets thrown at them. They 
accept a mix of self-closing and unclosed tags easily.

If you can describe a use case where self-closing tags create an actual, 
reproducible problem, then we'll have a discussion.

If you were just asking for the purity of the generated HTML, we have chosen 
not to bother as long as pages work.

-- 
Aymeric.



On 17 août 2014, at 19:33, noegry  wrote:

> But I don't sure that when it's using XHTML and HTML5 syntax together and it 
> should use one syntax for rending views.
> It might cause issues when templates are using HTML5 syntax but forms are 
> using XHTML syntax?
> 
> On Sunday, August 17, 2014 10:28:43 PM UTC+8, Florian Apolloner wrote:
> That is not just XHTML but perfectly valid HTML5.
> 
> Cheers,
> Florian
> 
> On Sunday, August 17, 2014 8:30:33 AM UTC+2, noegry wrote:
> Could Django provides a way to render forms in HTML5 syntax? It now render 
> forms in XHTML syntax as 
> 
> Or could it in the settings provides an option as USE_HTML5 for applying that?
> 
> -- 
> 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.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/django-developers/1620c231-1002-484a-8166-ac23848aa6c7%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" 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/928E87AE-F65F-4E63-8B4D-CCE35A5741DB%40polytechnique.org.
For more options, visit https://groups.google.com/d/optout.

Re: Support HTML5 syntax

[noegry]

But I don't sure that when it's using XHTML and HTML5 syntax together and 
it should use one syntax for rending views.
It might cause issues when templates are using HTML5 syntax but forms are 
using XHTML syntax?

On Sunday, August 17, 2014 10:28:43 PM UTC+8, Florian Apolloner wrote:
>
> That is not just XHTML but perfectly valid HTML5.
>
> Cheers,
> Florian
>
> On Sunday, August 17, 2014 8:30:33 AM UTC+2, noegry wrote:
>>
>> Could Django provides a way to render forms in HTML5 syntax? It now 
>> render forms in XHTML syntax as 
>> 
>> Or could it in the settings provides an option as USE_HTML5 for applying 
>> that?
>>
>

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/1620c231-1002-484a-8166-ac23848aa6c7%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Would AssertMaxQueries (similar to AssertNumQueries) be a useful addition

[Florian Apolloner]

I am not so convinced, what would you put in as the upper limit? While 
preventing n+1, it still requires you to know what n in this testcase is 
and changing n can lead to funny errors. Currently we are documenting 
(hopefully) how those query counts come together, so it's clear what's 
happening when it breaks…

On Sunday, August 17, 2014 4:39:17 PM UTC+2, James Bennett wrote:
>
> I like the idea -- if nothing else, it would provide an easy way to have a 
> test suite discover N+1 problems, especially in templates.
>
> Not sure about the feasibility, though; would you be willing to work up a 
> rough implementation of it?
>  

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/41676693-480d-4dfc-82a6-377da0f54057%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Would AssertMaxQueries (similar to AssertNumQueries) be a useful addition

[Shai Berger]

On Sunday 17 August 2014 17:36:12 Michael Manfre wrote:
> AssertNumQueries is often a problem for 3rd party backends.
> AssertMaxQueries would become the same and likely result in poorly written
> tests because of the inherent slop factor in the arbitrarily chosen max
> value.
> 

I agree with the concern, but I also note the intended use:

> On Sun, Aug 17, 2014 at 2:52 AM, Roger Hunwicks 
> > I want to write a test that tries every registered URL and makes sure
> > that none of them has an excessive number of queries.
> > 

This implies that the limit chosen should not be tight; also, it sounds like 
it is meant mostly for DML, where the differences in number of queries between 
backends are relatively small (unlike DDL). I think with documentation noting 
these points, AssertMaxQueries could be a welcome addition and maybe even 
useful for Django's own test-suite.

That said,

> > Would that be a useful contribution to Django proper, or should I just
> > create it in my own tests/utils.py.
> > 

I think you should first have it working for yourself, then, with some 
experience in its use, offer it to the community. Don't put too much into that 
"some experience" -- just make sure you write some tests with it and it really 
works as well as you expect.

HTH,
Shai.

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/201408171753.49569.shai%40platonix.com.
For more options, visit https://groups.google.com/d/optout.

Re: Would AssertMaxQueries (similar to AssertNumQueries) be a useful addition

[James Bennett]

I like the idea -- if nothing else, it would provide an easy way to have a
test suite discover N+1 problems, especially in templates.

Not sure about the feasibility, though; would you be willing to work up a
rough implementation of it?

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

Re: Would AssertMaxQueries (similar to AssertNumQueries) be a useful addition

[Michael Manfre]

AssertNumQueries is often a problem for 3rd party backends.
AssertMaxQueries would become the same and likely result in poorly written
tests because of the inherent slop factor in the arbitrarily chosen max
value.

I'm not opposed to Django adding this. I'm opposed to Django using it in
its own test suite.

Regards,
Michael Manfre


On Sun, Aug 17, 2014 at 2:52 AM, Roger Hunwicks 
wrote:

> I'm doing some refactoring of a Django app and I want to make sure that I
> don't introduce any really poorly performing pages as a result of poor
> queries.
>
> I want to write a test that tries every registered URL and makes sure that
> none of them has an excessive number of queries.
>
> AssertNumQueries doesn't seem very helpful to me, because it requires you
> to know when you write the test exactly how many queries the function
> should require.
>
> I'd like to create an AssertMaxQueries that passes as long as the number
> of queries is less than or equal to the parameter provided to the context
> manager. You could also do this my adding a parameter to AssertNumQueries
> to tell it whether to test for equality or "less than or equal to": that
> would involve less duplicated code in testcases.py, but is possibly less
> discoverable for a test author.
>
> Would that be a useful contribution to Django proper, or should I just
> create it in my own tests/utils.py.
>
> Roger
>
> --
> 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.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/4d8d120a-8819-4a7d-977f-4acae670130f%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" 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/CAGdCwBsH1BT%2BO%2Bta5A5%2BSTMN0VV7Kum0Am5Lk0BkGJa5JQKTkA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Support HTML5 syntax

[Florian Apolloner]

That is not just XHTML but perfectly valid HTML5.

Cheers,
Florian

On Sunday, August 17, 2014 8:30:33 AM UTC+2, noegry wrote:
>
> Could Django provides a way to render forms in HTML5 syntax? It now render 
> forms in XHTML syntax as 
> 
> Or could it in the settings provides an option as USE_HTML5 for applying 
> that?
>

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/5cf7acfc-9c62-4736-b742-2f411b06289e%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Would AssertMaxQueries (similar to AssertNumQueries) be a useful addition

[Roger Hunwicks]

I'm doing some refactoring of a Django app and I want to make sure that I 
don't introduce any really poorly performing pages as a result of poor 
queries.

I want to write a test that tries every registered URL and makes sure that 
none of them has an excessive number of queries.

AssertNumQueries doesn't seem very helpful to me, because it requires you 
to know when you write the test exactly how many queries the function 
should require.

I'd like to create an AssertMaxQueries that passes as long as the number of 
queries is less than or equal to the parameter provided to the context 
manager. You could also do this my adding a parameter to AssertNumQueries 
to tell it whether to test for equality or "less than or equal to": that 
would involve less duplicated code in testcases.py, but is possibly less 
discoverable for a test author.

Would that be a useful contribution to Django proper, or should I just 
create it in my own tests/utils.py.

Roger

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/4d8d120a-8819-4a7d-977f-4acae670130f%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Support HTML5 syntax

[noegry]

Could Django provides a way to render forms in HTML5 syntax? It now render 
forms in XHTML syntax as 

Or could it in the settings provides an option as USE_HTML5 for applying 
that?

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/439b34f6-054f-426d-ac36-e2fbac3bc1cf%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Proposal new Django Admin css style

[Danilo Bargen]

Just for the record, there's also
https://github.com/pydanny/django-admin2, another project that attempts
to create a more modular and extensible admin.

Danilo

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