Re: Multi-Threaded Dev Server
On Nov 17, 6:54 pm, Ludvig Ericson <[EMAIL PROTECTED]> wrote: > On Nov 16, 2008, at 07:26, Chris wrote: > > > 3. Fear of multi-threading bugs shouldn't be a reason to avoid multi- > > threading, especially when it could be very useful. We don't even know > > if there are multi-threading bugs. And even if there are, they can be > > fixed. > > There are bugs. Django isn't thread-safe, and we know that. Which bugs in particular? By all means, if you find one, report it. I have run Django with mod_wsgi threaded daemon mode with no ill effects for a long time. See http://code.djangoproject.com/wiki/DjangoSpecifications/Core/Threading , all bugs found during the review were fixed a long time ago (and only one of them, #6950, was serious-ish). --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: RequestContext rarely used (branched from Feature reviews for 1.1)
Adrian Holovaty wrote: > Yuri, to answer your question: I try never to send the request object > into a template context Uhm... But using RequestContext is not about it. Everyone I know uses RequestContext almost exclusively (i.e. nobody uses standard render_to_response with plain Context instance) but only a few people actually send request object into templates. The whole point is to be able to use custom context processors and that's it. P.S. "Everyone" is actually not an exaggeration :-) --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Multi-Threaded Dev Server
On Nov 17, 7:25 pm, "Jacob Kaplan-Moss" <[EMAIL PROTECTED]> wrote: > > That's just not true. At one point (two years ago?) it wasn't, but > these days Django's deployed all over the place in mutli-threaded > situations. If it wasn't threadsafe we'd hear about it. > As I understand it, there are some areas where you have to be careful. For example, you can't be sure that caching templates won't lead to problems, because there are some template tags where rendering state is held in the nodes rather than the context. This post may give more information: http://lucumr.pocoo.org/cogitations/2008/09/16/why-jinja-is-not-django-and-why-django-should-have-a-look-at-it/#comment-12073 If you ensure that templates are always compiled from source for each request, then this shouldn't bite you. Best regards, Vinay Sajip --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Multi-Threaded Dev Server
Hi, I'd like to point out that as you've stated, django is deployed in mulit-threaded environments successfully, employing an app that makes use of geodjango in a multi-threaded environment is not. Justin (Bronn) will testify to this I'm sure (as I and others have run into this issue whilst attempting to deploy mod_wsgi/mod_python/others in a mutli-threaded environment. (This is due to the underlying libgeos c library not being thread safe itself) I should (and will) create a ticket to make this clear in the django docs for the geodjango parts, so that others may avoid the pain we went throught a few months back. Cheers, Matt 2008/11/17 Jacob Kaplan-Moss <[EMAIL PROTECTED]> > > On Mon, Nov 17, 2008 at 10:54 AM, Ludvig Ericson > <[EMAIL PROTECTED]> wrote: > > There are bugs. Django isn't thread-safe, and we know that. > > Um... > > That's just not true. At one point (two years ago?) it wasn't, but > these days Django's deployed all over the place in mutli-threaded > situations. If it wasn't threadsafe we'd hear about it. > > Jacob > > > > -- Cheers, Matt --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Suggestion for extending user model
I have a suggestion for the Auth-02 feature. It might seem a bit unorthodox, but it will work. My suggestion involves a table called "auth_usermeta", much like in WordPress, which would have id, user_id, key, and content fields. Note that I said table, not model. To store data in this table, you would use dictionary-like syntax, and __getitem__ and __setitem__ methods would be attached to auth.User to handle this. They would be hooked up to a special adaptor which would store the content in the table for many types (I imagine that numbers would be prefixed with "int:", strings would be prefixed with "str:", image URLs would be prefixed with "img:", etc.). This has the advantages of: - Not requiring extra models to be written - Allowing multiple apps to have their own User extensions - Having the same syntax as model attributes from a template author's point of view The two major problems with this are that (a) apps might try to store data in the same key (which could be mitigated by asking apps to please prefix their keys with their app label), and (b) the multi-type adaptor might have a major performance hit. However, when this happens, the auth.User model will probably be stripped of first_name and last_name, as those are more profile-ish data. Let me know what you think. Regards, Leaf --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Remove "old docs" message from Django docs
Hi, I think I might be speaking for a few people here who have kinda seen enough of the "olddocs" warning/message/admonition thing every time we search on the Django docs. It's been 2 and a half months since Django 1.0 was released, so if people are still following links from the old documentation then they probably know about it by now. It's not a pony - maybe just a "my little pony". Alternatively, cause the olddocs warning to appear only when the referrer URL is from an old docs page. That should be do-able (at the moment it's done via a GET parameter). Regards, Zack --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Non-trivial patches question, + whether mine qualifies
I have a bit of confusion about how possibly "non-trivial" patches are supposed to be handled. Common practice here seems to be that if someone wants to propose a change and has a patch ready, they open a ticket first and then a discussion here. The docs indicate that if the patch is non-trivial (for some definition of non-trivial), the author should show that a discussion of alternate solutions occurred here. I assume that the ticket description is where this evidence goes. My question is: if I have a non-trivial patch, does the alternate- solutions discussion need to occur before I post my patch to Trac, or is it all right to create the ticket first and follow up with linkage later? Finally, I'd like to offer up a patch to contrib.admin, and I'm wondering if it would be classified as non-trivial. It allows a custom "base_site" template to be specified in an AdminSite instance. The patch modifies the admin templates which extend "admin/ base_site.html" to extend a "base_site_template" context variable instead, and adds an optional argument to a handful of view functions in contrib.auth and contrib.admin. Is this kind of change considered non-trivial? --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Django documentation index redesigned
Aw, I had actually started to like/get used to the old-new way ;) On Tue, Nov 18, 2008 at 1:44 AM, Adrian Holovaty <[EMAIL PROTECTED]> wrote: > > After months of being frustrated (and hearing other people being > frustrated) with our newish documentation index, I took some time > tonight to reorganize the links, to make it easier and faster to find > things. Take a look here: > > http://docs.djangoproject.com/en/dev/ > > I opted for a much more compact approach, with related links > side-by-side. The previous version tended to organize each link based > on whether it was reference vs. an overview, but this new version > organizes by topic, instead. > > The "Other batteries included" section is kind of a cop out. It's a > bit past my bedtime, so that's all I could come up with in a hurry. > > Hope people find this easier and faster to use! > > Adrian > > > > -- Clint Ecker -- http://blog.clintecker.com c: 312.863.9323 --- twitter: clint skype: clintology AIM: clintecker Gtalk: [EMAIL PROTECTED] --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Django documentation index redesigned
My only opinion, is beyond the tutorial, people would much rather search then dig for the link :) On Nov 18, 10:54 am, "Clint Ecker" <[EMAIL PROTECTED]> wrote: > Aw, I had actually started to like/get used to the old-new way ;) > > > > On Tue, Nov 18, 2008 at 1:44 AM, Adrian Holovaty <[EMAIL PROTECTED]> wrote: > > > After months of being frustrated (and hearing other people being > > frustrated) with our newish documentation index, I took some time > > tonight to reorganize the links, to make it easier and faster to find > > things. Take a look here: > > >http://docs.djangoproject.com/en/dev/ > > > I opted for a much more compact approach, with related links > > side-by-side. The previous version tended to organize each link based > > on whether it was reference vs. an overview, but this new version > > organizes by topic, instead. > > > The "Other batteries included" section is kind of a cop out. It's a > > bit past my bedtime, so that's all I could come up with in a hurry. > > > Hope people find this easier and faster to use! > > > Adrian > > -- > Clint Ecker --http://blog.clintecker.com > c: 312.863.9323 > --- > twitter: clint > skype: clintology > AIM: clintecker > Gtalk: [EMAIL PROTECTED] --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Post about django optimizations
It would be a lot more useful if you put details in to it. Right now this post looks like spam on the developers group. I'm curious as to your issues with the Paginator class. Works great for me (barring some additional context vars). On Nov 17, 11:43 pm, Dipankar Sarkar <[EMAIL PROTECTED]> wrote: > Hi guys, > > I wrote a post on django platform optimizations which i learned from > building (still learning actually) kwippy (http://kwippy.com) , i > would love to hear more tips from you guys out there :). > > http://www.desinerd.com/blog/technical/django-optimizations-within-th... > > Looking forward to *some* response. > > Dipankar > [EMAIL PROTECTED] --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: ANN: Django 1.0.1 released
On Sun, Nov 16, 2008 at 7:46 PM, James Bennett <[EMAIL PROTECTED]>wrote: > > On Sun, Nov 16, 2008 at 5:42 PM, Jacob Kaplan-Moss > <[EMAIL PROTECTED]> wrote: > > I'll defer to James to make the final call, but I'd prefer to do this > > and release 1.0.2 on Monday or Tuesday with a note that it's basically > > 1.0.1 plus the GeoDjango stuff we forgot and a couple of new bug fixes > > that got slipped in. If you look around you'll see other projects do > > the same all the time; I see no reason to be different. > > That sounds like the best plan. Let's aim for Tuesday (Monday I've got > to babysit some site launches), and add a couple caveats to > contributing instructions for patch authors and committers reminding > them to run 'setup.py sdist' and check that the package includes any > new directories they've added (if not, patch should be amended to > include changes to setup.py or the manifest). > Not sure when on Tuesday you're aiming for. I still think it would be good if this translation fix: http://code.djangoproject.com/ticket/9612 were put in (I'd do it myself except I don't know how to generate the binary xlate file). Also I assume you've seen #9616, about bdist_rpm failing because of the hyphens in the version string? Finally if you need anyone to test-install the next version before releasing it, feel free to ask me...I'm heading out now for a few hours but will be available later this afternoon/evening/night. Karen --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Django documentation index redesigned
I like the new new version much better. With the old new one, I kept going through the search bar, and contrary to David Cramer's opinion, I like being able to drill town to what I'm looking for (as long as it's not frustrating trying to find it). It gives me the sense that I know where I am, and that I could send someone else to the right place if I needed to. Cheers, Cliff On Tue, 2008-11-18 at 11:28 -0800, David Cramer wrote: > My only opinion, is beyond the tutorial, people would much rather > search then dig for the link :) > > On Nov 18, 10:54 am, "Clint Ecker" <[EMAIL PROTECTED]> wrote: > > Aw, I had actually started to like/get used to the old-new way ;) > > > > > > > > On Tue, Nov 18, 2008 at 1:44 AM, Adrian Holovaty <[EMAIL PROTECTED]> wrote: > > > > > After months of being frustrated (and hearing other people being > > > frustrated) with our newish documentation index, I took some time > > > tonight to reorganize the links, to make it easier and faster to find > > > things. Take a look here: > > > > >http://docs.djangoproject.com/en/dev/ > > > > > I opted for a much more compact approach, with related links > > > side-by-side. The previous version tended to organize each link based > > > on whether it was reference vs. an overview, but this new version > > > organizes by topic, instead. > > > > > The "Other batteries included" section is kind of a cop out. It's a > > > bit past my bedtime, so that's all I could come up with in a hurry. > > > > > Hope people find this easier and faster to use! > > > > > Adrian > > > > -- > > Clint Ecker --http://blog.clintecker.com > > c: 312.863.9323 > > --- > > twitter: clint > > skype: clintology > > AIM: clintecker > > Gtalk: [EMAIL PROTECTED] > > --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: ANN: Django 1.0.1 released
To generate the files just cd django; django-admin.py compilemessages - l LANG_CODE Another language ticket is: http://code.djangoproject.com/ticket/9597 On Nov 18, 2:44 pm, "Karen Tracey" <[EMAIL PROTECTED]> wrote: > On Sun, Nov 16, 2008 at 7:46 PM, James Bennett <[EMAIL PROTECTED]>wrote: > > > > > > > On Sun, Nov 16, 2008 at 5:42 PM, Jacob Kaplan-Moss > > <[EMAIL PROTECTED]> wrote: > > > I'll defer to James to make the final call, but I'd prefer to do this > > > and release 1.0.2 on Monday or Tuesday with a note that it's basically > > > 1.0.1 plus the GeoDjango stuff we forgot and a couple of new bug fixes > > > that got slipped in. If you look around you'll see other projects do > > > the same all the time; I see no reason to be different. > > > That sounds like the best plan. Let's aim for Tuesday (Monday I've got > > to babysit some site launches), and add a couple caveats to > > contributing instructions for patch authors and committers reminding > > them to run 'setup.py sdist' and check that the package includes any > > new directories they've added (if not, patch should be amended to > > include changes to setup.py or the manifest). > > Not sure when on Tuesday you're aiming for. I still think it would be good > if this translation fix: > > http://code.djangoproject.com/ticket/9612 > > were put in (I'd do it myself except I don't know how to generate the binary > xlate file). Also I assume you've seen #9616, about bdist_rpm failing > because of the hyphens in the version string? Finally if you need anyone to > test-install the next version before releasing it, feel free to ask me...I'm > heading out now for a few hours but will be available later this > afternoon/evening/night. > > Karen --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Proposal: Let Context handle template loading (#7815)
Am 27.09.2008 um 04:40 schrieb Malcolm Tredinnick:
> On Wed, 2008-09-24 at 16:34 +0200, Johannes Dollinger wrote:
> [...]
>> tpl.render(Context({}, loader=PrefixLoader(['a', 'b', 'c'])))
>> }}}
>>
>> This would fix #2949, #3544, #4278, #6834, and #7931. But it's a
>> backwards incompatible change: If you rely on compile time side
>> effects (e.g. {% load %}) in included templates, that will break.
>>
>> Opinions?
>
> -1 from me, since it's backwards incompatible. It looks like most of
> those feature requests (or at least the ones that are worth doing --
> it's not clear that things like #3944 are worth it) can be done
> without
> backwards incompatible behavioural changes.
Every instance of {% include "foo.html" %} would behave as {% with
"foo.html" as tpl_name %}{% include tpl_name %}{% endwith %}.
The difference should be an implementation detail - currently it's not.
Recursive includes (#3544) are useful whenever you render trees:
#node.xml:
{{ node.label }}
{% for child in node.children %}
{% with child as node %}
{% include "node.xml" %}
{% endwith %}
{% endfor %}
You can already do that if you hack around ConstantIncludeNode with {%
with "node.xml" as tpl %}{% include tpl %}{% endwith %}.
ContantIncludeNode is also the problem in #7931 (which I don't really
care about).
With #7817 [1] you could write:
[...]
{% for child in node.children %}
{% include "node.xml" with child as node %}
{% endfor %}
[...]
However, my original motivation for the proposed change was
customizing the loader for individual requests: while you can pick a
loader for the root Template, you have no control over {% include %}
and {% extends %} template loading. That's essentially what #2949 and
#6834 are about.
> The template context is the static rendering context, not the
> compiling/loading context and it feels like this is blurring that
> boundary.
Context would be the loading context *while rendering*, is that too
far fetched?
[1] http://code.djangoproject.com/ticket/7817
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---
Re: ANN: Django 1.0.1 released
On Tue, Nov 18, 2008 at 4:14 PM, [EMAIL PROTECTED] < [EMAIL PROTECTED]> wrote: > > To generate the files just cd django; django-admin.py compilemessages - > l LANG_CODE > > Another language ticket is: http://code.djangoproject.com/ticket/9597 > OK, thanks, I applied the two translation updates to the branch. Karen --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: RequestContext rarely used (branched from Feature reviews for 1.1)
Out of curiosity, for those who want RequestContext added to render_to_response, is there a reason you don't like using direct_to_template instead? I see the two as being functionally equivalent (minus the addition of RequestContext, of course), but this debate crops up every so often -- is there something I'm missing? In other words: my Python-foo is not strong, is there a reason I should avoid using direct_to_template in 99% of my views? --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Django documentation index redesigned
On Tue, Nov 18, 2008 at 5:47 AM, Mike Scott <[EMAIL PROTECTED]> wrote: > +1! > > Just one suggestion - if the final "bateries included" could be split into > contrib apps, and core library that'd be nicer. +1 -- Andrews Medina www.andrewsmedina.com --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Remove "old docs" message from Django docs
On Tue, Nov 18, 2008 at 9:34 PM, zvoase <[EMAIL PROTECTED]> wrote: > > Hi, >I think I might be speaking for a few people here who have kinda > seen enough of the "olddocs" warning/message/admonition thing every > time we search on the Django docs. It's been 2 and a half months since > Django 1.0 was released, so if people are still following links from > the old documentation then they probably know about it by now. It's > not a pony - maybe just a "my little pony". 2 and a half months isn't that long when we supported 0.96 as the official stable release for 18 months. When it costs us nothing to keep up the warning, it > Alternatively, cause the olddocs warning to appear only when the > referrer URL is from an old docs page. That should be do-able (at the > moment it's done via a GET parameter). That is exactly what _is_ happening. You only get the olddocs parameter if you are visiting from a djangoproject.com/docs URL. If you go in via docs.djangoproject.com, you don't get the olddocs warning. The confusion may be caused by the fact that the Google index (which is used by Django's documentation search) still contains a lot of olddocs pages. Yours, Russ Magee %-) --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: RequestContext rarely used (branched from Feature reviews for 1.1)
On Tue, Nov 18, 2008 at 5:40 PM, Nathaniel Whiteinge <[EMAIL PROTECTED]> wrote: >my Python-foo is not strong, is there a reason I should > avoid using direct_to_template in 99% of my views? I think if people are already using RequestContext 99% of the time, then render_to_response should include by default, if only to reduce confusion. There's no reason to cause confusion when someone uses render_to_response, following tutorial code or something else, and wonder why things aren't working the way they expect it to work. There's nothing wrong with using direct_to_template, but if you use it 99% of the time, and if a vast majority of people are using it or something similar 99% of the time, then render_to_response should be changed to align with actual usage. -- --- David Zhou [EMAIL PROTECTED] --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Django documentation index redesigned
Yeah, I really like it. Now I am able to jump to the Queryset-methods etc right from top page and don't need to dig through subpages (I always took me hours to find the builtin filters/tag reference) :) Thx, Florian Adrian Holovaty wrote: > After months of being frustrated (and hearing other people being > frustrated) with our newish documentation index, I took some time > tonight to reorganize the links, to make it easier and faster to find > things. Take a look here: > > http://docs.djangoproject.com/en/dev/ > > I opted for a much more compact approach, with related links > side-by-side. The previous version tended to organize each link based > on whether it was reference vs. an overview, but this new version > organizes by topic, instead. > > The "Other batteries included" section is kind of a cop out. It's a > bit past my bedtime, so that's all I could come up with in a hurry. > > Hope people find this easier and faster to use! > > Adrian --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: RequestContext rarely used (branched from Feature reviews for 1.1)
Thanks for your explanation, David. On Nov 18, 4:04 pm, "David Zhou" <[EMAIL PROTECTED]> wrote: > There's no reason to cause confusion when someone uses > render_to_response, following tutorial code or something else, and > wonder why things aren't working the way they expect it to work. Then why not just change the docs/tutorial to use or mention direct_to_template instead? Granted, there is a bit of momentum behind render_to_response, but if the docs are changed it will just be the status quo until that time people start catching on to the simpler method. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: RequestContext rarely used (branched from Feature reviews for 1.1)
> Then why not just change the docs/tutorial to use or mention > direct_to_template instead? > > Granted, there is a bit of momentum behind render_to_response, but if > the docs are changed it will just be the status quo until that time > people start catching on to the simpler method. Isn't that a generic view? Anyway, changing render_to_response to make a RequestContext requires it take the request as an argument. That either is backwards incompatible like hell, or will require maintenance (through request=request or so) on code that needs the RequestContext. And that's very doable, and I'm with you on this. I hate having to pass context_instance. Long lines. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: RequestContext rarely used (branched from Feature reviews for 1.1)
On Tue, Nov 18, 2008 at 4:43 PM, Ludvig Ericson <[EMAIL PROTECTED]> wrote: > And that's very doable, and I'm with you on this. I hate having to > pass context_instance. Long lines. Although nothing stops someone from writing their own wrapper if they don't like direct_to_template for some reason :) http://www.djangosnippets.org/snippets/3/ -- Collin Grady --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Remove "old docs" message from Django docs
On Nov 19, 2008, at 00:13, Russell Keith-Magee wrote: > That is exactly what _is_ happening. You only get the olddocs > parameter if you are visiting from a djangoproject.com/docs URL. If > you go in via docs.djangoproject.com, you don't get the olddocs > warning. > > The confusion may be caused by the fact that the Google index (which > is used by Django's documentation search) still contains a lot of > olddocs pages. So uh, I agree with the original post a lot. I personally go edit the URL all the time so I don't have that big red flashy thing. The obvious solution -- to me -- is to do a redirect if the referrer is not djangoproject.com? To the same URL without the from=olddocs. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Django documentation index redesigned
On Nov 19, 2008, at 00:11, Andrews Medina wrote: > > On Tue, Nov 18, 2008 at 5:47 AM, Mike Scott <[EMAIL PROTECTED]> wrote: >> +1! >> >> Just one suggestion - if the final "bateries included" could be >> split into >> contrib apps, and core library that'd be nicer. > > +1 Why are you +1ing a change that has been made? ;P I like it either way. Actually I'd like it if things stuck to one way. :-) --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Remove "old docs" message from Django docs
On Nov 19, 2008, at 00:13, Russell Keith-Magee wrote: > That is exactly what _is_ happening. You only get the olddocs > parameter if you are visiting from a djangoproject.com/docs URL. If > you go in via docs.djangoproject.com, you don't get the olddocs > warning. > > The confusion may be caused by the fact that the Google index (which > is used by Django's documentation search) still contains a lot of > olddocs pages. So uh, I agree with the original post a lot. I personally go edit the URL all the time so I don't have that big red flashy thing. The obvious solution -- to me -- is to do a redirect if the referrer is not djangoproject.com? To the same URL without the from=olddocs. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Using pysqlite2 instead of sqlite3 when desired
On Mon, 2008-11-17 at 16:19 -0800, Matthew D. Hancher wrote: [...] > Options include: > > A. Leave sqlite3 as the default, and add a configuration setting that > forces use of pysqlite2 if desired. > > B. Always try both sqlite3 and pysqlite2, and use whichever has the > greater version number if both are present. > > C. Same as B, but with an optional configuration option to force one > or the other if desired. > > D. Switch to making pysqlite2 the default, since that's the correct > name for the module if the user has explicitly installed it, and treat > the Python-bundled version as the fallback. > > E. Develop arbitrarily convoluted bits of logic that pay attention to > e.g. what Python version we're running under or the phase of the moon > or something. > > I think I'm personally slightly inclined towards C, but I would be > happy with B or D. I don't really like A because I worry that the > sqlite3 module will become increasingly outdated and this > configuration option will be an extra step and source of confusion for > new users. I suspect things are a little hairier than you realise, too. There's evidence (by which I mean "people using Windows have reported" -- and despite their choice of OS they seem otherwise reliable) that Windows has a different version of sqlite3 in their Python binaries to what I have, for example, in my Linux (Fedora) installed versions. We should do something, since it's quite reasonable to expect Python 2.5 will be in active use for years to come, so hoping that Python upstream get their act together and/or SQLite development speed slows down are not particularly realistic. I tend to prefer option A (or D), since the number of people who'll really need to use it should be small and, frankly, if you're up to using GIS features, then reading documentation will hopefully be a skill you've already mastered. Beginners won't need to worry about this, since they won't be using features that require this setting to be touched. I dislike options B and C because they will load two modules if you have them both installed. Django's already fairly memory hungry and this only adds to the burden. Option D is not unreasonable, either. I can't think of a way it can backfire, given that pysqlite2 is compiled against a particular Python version and so shouldn't be accidentally importing the 2.4 version with Python 2.5 or something. But I may be missing some outwardly-looking crazy installation option that causes that to happen. Strong -1 on E. It's been suggested previously as a way to work around problems with sqlite3 and Windows and I didn't like it then either (in that particular case, it turned out to be symptomatic of a broader class of bug in SQLite that we still have to fix, so I feel somewhat justified in preferring cleaner code at the time). I guess I prefer D the most, subject to a slight concern if the wrong version could possibly be imported (but I can't imagine how). Then option A. Don't like the others at all. Regards, Malcolm --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Notification on new database connections (ticket #6064)
Dude, how broken is you mail client? It's attaching this thread continuation On Mon, 2008-11-17 at 15:15 -0800, Matthew D. Hancher wrote: [...] > Okay. Given all this, how do people feel about a connection_created > signal? What about a cursor_created signal, either instead or in > addition? (I have no use case for that, but if for some reason people > prefer it to connection_created it will still be sufficient to solve > my immediate problem.) I'm in favour of connection_created. Since we don't have any compelling use-case for it, I'm not in favour of cursor_created. There's stuff you need to do when connecting to the database, so connection_created is indeed useful. But until there's really a good idea of things that need to be done when a new cursor is made, let's leave it out. We have a fairly consistent policy of not including things just because we can. > Malcolm Tredinnick wrote: > > A random thought: is there any other information worth sending along > > with the signal? Right now, the receiver is told "a connection was > > created". Anything that's likely to vary and that could be useful as a > > trigger for other actions? > > I was thinking about this, too. Right now the most important thing is > the type of database connection being created, which you can determine > from the sender, and which you can determine from settings anyway. > However, the big question in my mind is how all of this relates to the > multiple-database support that folks seem to be working on. Does > anyone from that camp want to chime in? I was contemplating this a bit more in the interim and realised the multi-db stuff will probably want to send through the name (or identifier -- whatever that means. I've been playing with a few ideas and what the ident is varies from thought to thought) when the connection is made. However, I also realised my question was a bit silly. We've set things up (by requiring **kwargs in the signal receiving functions) precisely so that we can add parameters later. This doesn't need to be resolved now, because it's not going to cause any compatibility issues. I withdraw even the random thought; it's really irrelevant to this situation. We can punt this until it becomes a requirement. Regards, Malcolm --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Non-trivial patches question, + whether mine qualifies
On Tue, 2008-11-18 at 05:45 -0800, Matt Brown wrote: > I have a bit of confusion about how possibly "non-trivial" patches are > supposed to be handled. > > Common practice here seems to be that if someone wants to propose a > change and has a patch ready, they open a ticket first and then a > discussion here. The docs indicate that if the patch is non-trivial > (for some definition of non-trivial), the author should show that a > discussion of alternate solutions occurred here. I assume that the > ticket description is where this evidence goes. > > My question is: if I have a non-trivial patch, does the alternate- > solutions discussion need to occur before I post my patch to Trac, or > is it all right to create the ticket first and follow up with linkage > later? That sounds fine. There's no hard and fast procedure. What we're trying to accomplish is this: when design discussions occur in a ticket there are multiple problems. Firstly, only the people who happen to notice the ticket will see the discussion. I make a point of reading every single change to Trac tickets and even then I'll often not notice that a particular ticket isn't really fleshed out as to the design or the patch is just a proto-implementation. Those of us who do follow and contribute to those discussions have one forum we need to follow to keep up on that: django-developers. Yes, there's the slight drawback that everybody then has to see every conversation and there's no keeping it contained just in that ticket. Being forced to be exposed to the development process by being subscribed to the developers mailing list isn't really a downside that gets a lot of sympathy, though. The second problem is when there really isn't any consensus yet, even amongst those with non-pony ideas to add. You end up with a ticket with anywhere from 20 to 100 comments with multiple conflicting threads of conversation and it's a disaster to try and read through (particularly thanks to Trac's displaying of changes to the CC list as just as important as substantive comments). A mailing list makes it quite a bit easier to read through that stuff I've found (kind of confirming the old saw that a web browser really isn't an ideal UI for much beyond scrolling through web pages). So, by all means post your patch. If it's a change that's likely to have alternate approaches or change something dramatic, you might well want to start a thread here as well. That sometimes leads to disasters where people attempt to respond in both places (or sometimes people stop responding on the mailing list when things aren't going as smoothly as they like and just post a comment in the ticket with responses to the mailing list -- that's really annoying and fundamentally counter-productive). But that's not common and can be managed. You might sometimes get asked to start a django-developers thread on the ticket if it looks clean, but appears trickier than that to whichever maintainer reads through it. Basically, though, the idea is to not overwhelm people with content or procedure, but to make sure that as many of the relevant eyes as possible get to see changes before they happen. So just use your best judgement. Nobody gets flamed for trying to do the right thing and listening to feedback (repeat offenders are just auditioning for jobs as Crispy Chicken pieces, obviously, but that's just the Darwin Award in action, really). Regards, Malcolm --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: RequestContext rarely used (branched from Feature reviews for 1.1)
On Nov 18, 5:43 pm, Ludvig Ericson <[EMAIL PROTECTED]> wrote: > Isn't that a generic view? Yes. It's built into Django and already does exactly what some people want render_to_response to do, so why all the hullabaloo? (Or am I still missing something?) --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: RequestContext rarely used (branched from Feature reviews for 1.1)
On Tue, Nov 18, 2008 at 9:20 PM, Nathaniel Whiteinge <[EMAIL PROTECTED]> wrote: > > On Nov 18, 5:43 pm, Ludvig Ericson <[EMAIL PROTECTED]> wrote: >> Isn't that a generic view? > > Yes. It's built into Django and already does exactly what some people > want render_to_response to do, so why all the hullabaloo? (Or am I > still missing something?) http://bikeshed.com/ --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
ANN: Django 1.0.2 released
Tonight, to clear up some problems with the packaging of the Django 1.0.1 release from Friday, we've released Django 1.0.2; once again, this is a bugfix-only release, and is a recommended upgrade for anyone targeting or using Django 1.0 or Django 1.0.1. Weblog entry announcing the release is here: http://www.djangoproject.com/weblog/2008/nov/18/102/ Release notes are here: http://docs.djangoproject.com/en/dev/releases/1.0.2/ -- "Bureaucrat Conrad, you are technically correct -- the best kind of correct." --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: RequestContext rarely used (branched from Feature reviews for 1.1)
Nathaniel Whiteinge wrote:
> Yes. It's built into Django and already does exactly what some people
> want render_to_response to do, so why all the hullabaloo? (Or am I
> still missing something?)
The problem here is for novice users. We have two things doing roughly
the same thing which is confusing. What's even more confusing is that
the thing that doesn't work like most people expect
('render_to_response') is better named and better documented for the
purpose than the other thing ('direct_to_template'). Just adding a
'request' into render_to_response won't solve the problem of having two
things completely but will make 'direct_to_template' not visible, nobody
will look for it in the first place.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---
