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 confu
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
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
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?)
--~--~-~--~~~--
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
> di
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?
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 num
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 b
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 c
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 b
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
> 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
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 wh
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
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
--~--~-~--~~~---~
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
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 peo
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
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 t
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:
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:
>
>
>
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, an
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 ba
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]> wrot
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 PROT
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 reorg
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
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 documenta
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
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 attempt
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
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 insta
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
33 matches
Mail list logo
