On Oct 6, 4:16 pm, "ihomest...@gmail.com"
wrote:
> I read this doc about the performance comparison between Tornado and
> Django:http://www.tornadoweb.org/documentation
>
> I am quite new to both django and tornado (just heard about it). To me
> there are a few confusing points about the conclu
On Tuesday 06 Oct 2009 10:46:44 am ihomest...@gmail.com wrote:
> I read this doc about the performance comparison between Tornado and
> Django: http://www.tornadoweb.org/documentation
comparison between django and tornado? django is a web framework. Tornado
is a web server. Whats to compare?
I read this doc about the performance comparison between Tornado and
Django: http://www.tornadoweb.org/documentation
I am quite new to both django and tornado (just heard about it). To me
there are a few confusing points about the conclusion that "Tornado
consistently had 4X the throughput of the
On Oct 5, 6:33 pm, Matt Brubeck wrote:
> On Sep 24, 10:18 am, Simon Willison wrote:
> > This offers two APIs: sign/unsign and dumps/loads. sign and unsign
> > generate and append signatures to bytestrings and confirm that they
> > have not been tampered with. dumps and loads can be used to creat
On Mon, Oct 5, 2009 at 2:18 PM, Jeremy Dunck wrote:
> I have an icky patch for this.
To be clearer, this is a general problem with admindocs-- it has a
mapping, DATA_TYPE_MAPPING, and assumes any model field's
.get_internal_type() will be in that dictionary.
I can think of a couple ways to addre
I have an icky patch for this.
On Oct 5, 2009, at 2:07 PM, Peter Baumgartner
wrote:
>
> On Thu, Aug 27, 2009 at 2:03 PM, Justin Lilly
> wrote:
>> Hey guys.
>>
>> I started writing some docs for another developer today and hit a
>> few
>> issues with admindocs that I plan on sprinting
On Thu, Aug 27, 2009 at 2:03 PM, Justin Lilly wrote:
> Hey guys.
>
> I started writing some docs for another developer today and hit a few
> issues with admindocs that I plan on sprinting on for DjangoCon. I'm
> hoping anyone else with complaints / ideas will voice up, though my main
> impetus f
On Sep 24, 10:18 am, Simon Willison wrote:
> This offers two APIs: sign/unsign and dumps/loads. sign and unsign
> generate and append signatures to bytestrings and confirm that they
> have not been tampered with. dumps and loads can be used to create
> signed pickles of arbitrary Python objects.
There's http://code.djangoproject.com/wiki/CollaborateOnGithub
that I wrote some time ago, but it doesn't give guidelines for
branchy development.
I will update that page with these instructions, but it would be
excellent if others who have collaborated more intensively via
GitHub could amend the
Thanks for putting this together - that's a really useful summary of
commands. Any chance you could save it on the wiki somewhere?
Cheers,
Simon
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Django developers" gr
Many core developers and the GSOC folks use GitHub for
Django development, so I hope discussing the best
practices is appropriate for django-dev.
Let me outline the desired workflow, please amend and
correct as you see fit as there are probably errors or
omissions. I expect various useful pattern
On Fri, Oct 2, 2009 at 9:37 AM, Russell Keith-Magee
wrote:
> Django's ORM is designed to make the simple cases really simple, but
> once you move beyond the basics, you really should be looking to use
> raw SQL.
Indeed. I look at raw() really as "I know *exactly* the query I want
to run, get the
On Oct 2, 7:35 pm, mrts wrote:
> But let me stop right here.
Contradicting myself, I've pursued this further and
implemented raw_override() for order_by in [1] as a proof of
concept. See [2] for what's different and tests [3] for
usage.
I'd say that for order_by, the implementation is simple an
13 matches
Mail list logo
