Re: Consider renaming `mark_safe` to `dangerously_trust_html` (etc)
The name "mark_safe" unnecessarily exposes an implementation detail. People who misunderstand this API probably have no idea how this "marking" happens, it would make sense to name this after the *effect* it achieves: "don't process / escape me, I've been sanitized somewhere else". Any of these would work: "no_escape", "dontescape", "sanitized_elsewhere", 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 https://groups.google.com/group/django-developers. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/268807b1-cfdf-4bf8-9c02-6e954bfa30e1%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Why doesn't ModelChoiceField.queryset support slicing?
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(
> queryset=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.
Re: Why doesn't ModelChoiceField.queryset support slicing?
> > However, I don't think this is subject to the kind of problem you describe > as the inner queryset should be turned into a subquery of the main queryset. Yes, I can confirm that I used this solution and it returns a QuerySet. It does not perform query at module load time in my case. It's true that the generated queries might be inefficient (I'm not sure all > DBMS can optimize something like "*SELECT ... FROM foo WHERE id IN > (SELECT id FROM foo ORDER BY bar LIMIT 10)*"). I would not use such a > construction on a big production dataset and if performance really matters > I would do something else. My table is not very large (5-10k rows) so the maintenance cost of a solution that would require me to periodically check if the query is not returning too little or to many rows is much bigger concern than performance. But I guess it does matter if it were to be implemented like this internally in Django as I proposed. You're right, the version with a subqery is much slower than the plain one, at least in PostgreSQL. i tried it on one of my tables (unrelated to my example) that contains 1906 rows: *Plain query* EXPLAIN ANALYZE SELECT "baseapp_award"."id", "baseapp_award"."profile_awards_id", "baseapp_award"."name", "baseapp_award"."date_achieved", "baseapp_award"."recognition_level" FROM "baseapp_award" ORDER BY "baseapp_award"."id" DESC LIMIT 100; QUERY PLAN Limit (cost=0.28..4.51 rows=100 width=38) (actual time=0.024..0.118 rows= 100 loops=1) -> Index Scan Backward using baseapp_award_pkey on baseapp_award (cost= 0.28..80.94 rows=1906 width=38) (actual time=0.022..0.097 rows=100 loops=1) Total runtime: 0.171 ms *Subquery* EXPLAIN ANALYZE SELECT "baseapp_award"."id", "baseapp_award"."profile_awards_id", "baseapp_award"."name", "baseapp_award"."date_achieved", "baseapp_award"."recognition_level" FROM "baseapp_award" WHERE "baseapp_award"."id" IN ( SELECT U0."id" FROM "baseapp_award" U0 ORDER BY U0."id" DESC LIMIT 100 ); QUERY PLAN --- Hash Semi Join (cost=6.76..48.94 rows=100 width=38) (actual time=0.763.. 0.841 rows=100 loops=1) Hash Cond: (baseapp_award.id = u0.id) -> Seq Scan on baseapp_award (cost=0.00..36.06 rows=1906 width=38) (actual time=0.007..0.324 rows=1908 loops=1) -> Hash (cost=5.51..5.51 rows=100 width=4) (actual time=0.112..0.112 rows=100 loops=1) Buckets: 1024 Batches: 1 Memory Usage: 4kB -> Limit (cost=0.28..4.51 rows=100 width=4) (actual time=0.009.. 0.083 rows=100 loops=1) -> Index Only Scan Backward using baseapp_award_pkey on baseapp_award u0 (cost=0.28..80.94 rows=1906 width=4) (actual time=0.009.. 0.063 rows=100 loops=1) Heap Fetches: 100 Total runtime: 0.904 ms The plain version runs in about 0.2 sec on my development machine while the one with subquery requires more than 4x times as much. Mostly because of the extra sequential scan and a semi-join. -- 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/0dfb4964-44d5-4648-b7dd-ac06445a164a%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Proposal: OpenLayers.js and shipping it in django.contrib.gis statics
Hi Django developers! This is my first time here posting, so if I'm wrong please forgive me :) I wanna learn as much as possible about django development process from you guys! Thank you all for inspiring time on DjangoCon.eu sprints ! I'm writing because I'm concerned about OpenLayers that are used in django.contrib.gis.admin. For now JS of OpenLayers is shipped with external url from openlayers hosting. There are some drawback of this situation and it's causing bugs in specific circumstances. For example if you are using Chrome browser and your website is using https all non https javascript are blocked by default. So widget in django admin isn't rendering and it's broken (I think that should be considered as a bug and possibility of security problems if someone switch openlayer.js on external hosting). I think the best approach to that problem is that we should ship OpenLayer.js in Django statics. OpenLayers documentation is encouraging to ship in applications own builds of this library. To read more: http://docs.openlayers.org/library/deploying.html I have question is this approach good for Django (to actually compile own build of OpenLayer and ship it in statics) and is this change can be possible place of breaking something with backward compatibility. Things in my mind to consider: 1) With every next Django release I think there should be building of most actual OL. 2) Shipping OL actually should be optional and documented in docs. If there isn't any problem with that approach I'm ready to implement this. Cheers, Kamil Gałuszka -- 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: Proposal: OpenLayers.js and shipping it in django.contrib.gis statics
Hi, Thanks for explanation. I think your reasoning make sense. Cheers Kamil Gałuszka On Monday, May 27, 2013 10:48:35 AM UTC+2, Claude Paroz wrote: > > > > Le lundi 27 mai 2013 07:38:54 UTC+2, Carl Meyer a écrit : >> >> Hi Kamil, >> >> On 05/26/2013 05:39 PM, Kamil Gałuszka wrote: >> > Hi Django developers! >> > >> > This is my first time here posting, so if I'm wrong please forgive me >> :) >> > I wanna learn as much as possible about django development process from >> > you guys! >> > Thank you all for inspiring time on DjangoCon.eu sprints ! >> > >> > I'm writing because I'm concerned about OpenLayers that are used in >> > django.contrib.gis.admin. For now JS of OpenLayers is shipped with >> > external url from openlayers hosting. >> > >> > There are some drawback of this situation and it's causing bugs in >> > specific circumstances. For example if you are using Chrome browser and >> > your website is using https all non https javascript are blocked by >> > default. So widget in django admin isn't rendering and it's broken (I >> > think that should be considered as a bug and possibility of security >> > problems if someone switch openlayer.js on external hosting). >> > >> > I think the best approach to that problem is that we should ship >> > OpenLayer.js in Django statics. OpenLayers documentation is encouraging >> > to ship in applications own builds of this library. To read more: >> > http://docs.openlayers.org/library/deploying.html >> > >> > I have question is this approach good for Django (to actually compile >> > own build of OpenLayer and ship it in statics) and is this change can >> be >> > possible place of breaking something with backward compatibility. >> > >> > Things in my mind to consider: >> > 1) With every next Django release I think there should be building of >> > most actual OL. >> > 2) Shipping OL actually should be optional and documented in docs. >> > >> > If there isn't any problem with that approach I'm ready to implement >> this. >> >> I'm not familiar with any history in this area (so I'll defer to anyone >> who knows a good reason why we do it the way we do), but it makes sense >> to me that it would be better to ship an OpenLayers.js build than link >> to it externally, for security and reliability reasons. >> > > I was not there at the time of this design decision either, however I can > imagine that including a lib weighing more than 700 Ko in every Django > release just for a contrib app is not something to be taken lightly. > > Note that Django 1.6 will introduce some new template-based widgets for > GeoDjango, so changing the OpenLayers source is as simple as subclassing > the new BaseGeometryWidget and redefining its Media class. > > Claude > -- 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.
mod_python support
Hi ! I wanted to post this in old topic from 2010 but Google always gives me an error on posting so I can't do that there. (soory for that!) I know that mod_python support was dropped long time ago but I think this information should be noted to core developers. There is new release of mod_python that support WSGI and is adding Python 3. Maybe we should reconsider adding it to django (only documentation I think since if it has WSGI support we maybe don't need do anything more. But I'm not sure so I could be wrong.)? Here is WSGI handler to mod_python: http://modpython.org/live/current/doc-html/handlers.html#wsgi-handler New version was released 13 November http://modpython.org/. I think someone started refactoring old mod_python and moved project to github. Cheers Kamil Gałuszka -- 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/cea5e59a-42a7-4084-91ab-8759da7d2f1d%40googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: mod_python support
I understand that and I agree that it maybe doesn't have any uptake. But, my reason for sending that information was question from today on django-users about mod_python support on Django. https://groups.google.com/forum/#!topic/django-users/449r3gUsN54 Cheers, Kamil Gałuszka 2013/11/25 Alex Gaynor > I'm -1 on this. If it's, in fact, just a normal WSGI container, we should > add docs for it if it has any uptake, as we would for any other WSGI > container, and I don't believe it has any uptake. > > Alex > > > On Mon, Nov 25, 2013 at 10:36 AM, Kamil Gałuszka wrote: > >> Hi ! >> >> I wanted to post this in old topic from 2010 but Google always gives me >> an error on posting so I can't do that there. (soory for that!) >> >> I know that mod_python support was dropped long time ago but I think this >> information should be noted to core developers. There is new release of >> mod_python that support WSGI and is adding Python 3. Maybe we should >> reconsider adding it to django (only documentation I think since if it has >> WSGI support we maybe don't need do anything more. But I'm not sure so I >> could be wrong.)? >> >> Here is WSGI handler to mod_python: >> http://modpython.org/live/current/doc-html/handlers.html#wsgi-handler >> >> New version was released 13 November http://modpython.org/. I think >> someone started refactoring old mod_python and moved project to github. >> >> Cheers >> Kamil Gałuszka >> >> >> >> -- >> 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/cea5e59a-42a7-4084-91ab-8759da7d2f1d%40googlegroups.com >> . >> For more options, visit https://groups.google.com/groups/opt_out. >> > > > > -- > "I disapprove of what you say, but I will defend to the death your right > to say it." -- Evelyn Beatrice Hall (summarizing Voltaire) > "The people's good is the highest law." -- Cicero > GPG Key fingerprint: 125F 5C67 DFE9 4084 > > -- > You received this message because you are subscribed to a topic in the > Google Groups "Django developers" group. > To unsubscribe from this topic, visit > https://groups.google.com/d/topic/django-developers/TWEhJTRJ5OA/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/CAFRnB2U_f_fqC_c84aPsgWe6PoGVQjKy15X4rLNvPx0VpWMCLw%40mail.gmail.com > . > > For more options, visit https://groups.google.com/groups/opt_out. > -- You received this message because you are subscribed to the Google Groups "Django developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-developers+unsubscr...@googlegroups.com. To post to this group, send email to django-developers@googlegroups.com. Visit this group at http://groups.google.com/group/django-developers. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/CAPDscZ2H_fK6JL7C-FXpTnB7NFMCTV%3DPfCkwSzj7bf7_4evQAA%40mail.gmail.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: Proposal: Write unit tests for JavaScript
Hi Trey, You may be interested in this: https://code.djangoproject.com/ticket/20436 I've started to work on this last year on DjangoCon Europe, I never manage to finish my work mostly because of my work on thesis and other stuff. Maybe I will finish this ticket this week and you start writing UnitTest for that? Cheers Kamil Gałuszka On Saturday, April 19, 2014 1:50:19 PM UTC+2, Jannis Leidel wrote: > > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > Hi Trey, all, > > I know we shortly talked about that at PyCon but I forgot to mention > that a while ago we took a stab at that already. Sean Bleier was spear > heading it and I helped out here and there: > > https://github.com/sebleier/django/compare/4f3ad28a9b4ffc3ae9866d14f242844d5720b3be...qunit > > > Sadly we never finished it, even though it was supposed to be merged > together with the LiveServerTestCase. It was providing a "jstest" > management command that was just runserver in disguise with an > enforced URLconf with a few views to render JS test pages. > > The actual core part was a collector for JS test suites > (conventionally placed in /tests/javascript). Each suite could > test any kind of local and remote files and used staticfiles for > serving them. > > I'm not suggesting to re-use this code but wanted to mention that > we've worked on it and found it pretty good (at the time). We just > lacked the time to finish it. Also, some parts are specific to QUnit > but others (like the suite collector) could be reused for other test > runners. > > All in all, I'm all for supporting some way for writing JS tests as > part of Django apps but would be a lot more careful about what > technique/tool to use given the fast paced changes in JS land. I admit > I don't have experience with Jasmine though so take my advise with a > grain of salt :) > > Cheers, > Jannis > > > On 16.04.14 23:57, Trey Hunner wrote: > > I saw a previous discussion about JavaScript testing in Django but > > it looks like there hasn't been any progress in a few years. > > > > Some of my thoughts on this issue: > > > > This would require choosing a JavaScript testing framework. There > > are many good ones out there. A popular one should probably used > > for easier community support. > > > > Unit testing JavaScript (ideally) should not require running the > > Django server. > > > > JavaScript tests will probably require introducing Node.js into > > the automated testing process. Tests can be run manually from the > > browser, but automated JavaScript tests tend to require Node.js and > > sometimes PhantomJS (for headless testing). > > > > The JavaScript tests should be run as part of the CI testing > > process. If the tests are run standalone this should be easy to do > > using a single command (possibly requiring grunt or a similar task > > runner). > > > > This seems like it would be a big change, but I think it could be > > done in small steps. Setting up the testing framework is the first > > big step. > > > > What do others think about this issue? > > > > -- Trey Hunner > > > > -- 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-develop...@googlegroups.com > > <mailto:django-developers+unsubscr...@googlegroups.com >. > To post to > > this group, send email to django-d...@googlegroups.com > > <mailto: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/CACuWcAwHVJ7HfeWOui3pAT3nQJeABP_Vt5WQe1N5%2BvDs%2Bnt8GQ%40mail.gmail.com > > > > > > < > https://groups.google.com/d/msgid/django-developers/CACuWcAwHVJ7HfeWOui3pAT3nQJeABP_Vt5WQe1N5%2BvDs%2Bnt8GQ%40mail.gmail.com?utm_medium=email&utm_source=footer>. > > > > For more options, visit https://groups.google.com/d/optout. > -BEGIN PGP SIGNATURE- > Version: GnuPG v1 > Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ > > iQIcBAEBAgAGBQJTUmL6AAoJEMeVlW+0idypTNYP/37E7THRsG1BG5uc55nVkTSP > tZ6l7XaOtCfwv82N0sXHVGbBek1UPXfm+3VENAZBxrMyJdGybTcn9q6RGXeKsPE6 > xunFI1IuHEMjzBG6KcL0d2t3CVOeGIMvTNkn3Lr7FM3bl7JYds5PtsislUiH56sY > qDoDkKP+GXglH5sswxB54vyiAf85g7Rh7wcq0klxlLy1D46aH+NqrVFMqWirb1Rr > KVk4Y8H3khRMrOyz17yF/s7Qkbtj3z
Why doesn't ModelChoiceField.queryset support slicing?
Hi
I have just stumbled upon a problem with how ModelChoiceField handles its
'queryset' argument and I'd like to ask whether it's a deliberate design
choice or if I should report it as a bug.
Let's say you have a model called Book:
class Book(models.Model):
rating = models.IntegerField()
You want to create a form that lets user select one of tghe top rated
books. So you try:
class BookForm(forms.Form):
book = forms.ModelChoiceField(queryset =
Book.objects.order_by('-rating')[:100])
It appears to work - the form can be rendered and you can choose one of a
hundered top-rated books. But when you submit, you get the following error:
AssertionError: Cannot filter a query once a slice has been taken.
>
The error is caused by ModelChoiceField.to_python()
validating the existence of the selected item by calling get() on the
queryset:
value = self.queryset.get(**{key: value})
And this is not supported for sliced querysets as the error above states.
It might have been be a deliberate choice not to support this use case in
ModelChoiceField though I don't see any comments about that in the code or
any mentions in ModelChoiceField.queryset
docs. I would also expect it to be a common need. This and the fact that it
can be trivially solved by replacing get() with SQL INTERSECT (implemented
as operator & in Django) makes me suspect that there would be some issue
with that.
Can anyone shed some light on this? Are there any performance or
database-combatibility issues involved? Or is it just a bug?
--
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/e264b254-4208-4e39-a50b-6657f8817996%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
#29433 New split template filter
Hi guys, What do you think about new filter for splitting strings in templates? We need opinion for ticket: https://code.djangoproject.com/ticket/29433 -- 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 https://groups.google.com/group/django-developers. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/bfd7a876-63e7-491b-b255-3bf335224dd7%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
