I've created two tickets for this, with patches and tests...
http://code.djangoproject.com/ticket/15762 - WSGIRequest should wrap the
test client wsgi.input in LimitedStream
http://code.djangoproject.com/ticket/15763 - MultiPartParser's LimitBytes is
now redundant.
It's possible that I've misun
Jannis and Łukasz have both suggested the same thing: use Babel instead
of xgettext. I understand why: it's a more complete solution than what I
have proposed, which is at heart still a way to trick xgettext into
parsing source code it doesn't natively understand.
I have no experience with Bab
On Sun, Apr 3, 2011 at 11:46 PM, Gregor Müllegger wrote:
> Hi,
>
> 2011/4/2 Russell Keith-Magee :
>> On Fri, Apr 1, 2011 at 11:57 PM, Gregor Müllegger
>> wrote:
>> Firstly, while it looks fine for a small example, I can see how it
>> would rapidly deteriorate if you have lots of fields, or lots
My apologies for reposting this - I originally posted this at the end
of January and as soon as I posted it I realised that with the push
for bug squashing for the 1.3 release going on I probably wouldn't get
any attention (and thus comment or replies :), so I'm trying a repost
now that 1.3 is out.
On Thu, Mar 31, 2011 at 7:38 PM, Vivek Narayanan wrote:
> Hi Russ,
>
> Thanks for the suggestions once again, I've thought of changing the
> model for handling nested fields.
>
> Each model can have a no of serializers, and they can be plugged in to
> other serializers
> and in this way nested mod
On Sun, Apr 3, 2011 at 6:58 AM, DaNmarner wrote:
> I've got some more crystalized details about my proposal.
>
> Here are the target result if this proposal is implementated:
>
> 1. User could configure serialization for each model.
>
> 2. In fact, user could configure the serialization details do
On Sat, Apr 2, 2011 at 10:04 PM, Marti Raudsepp wrote:
> Hi list,
>
> I wrote a proof of concept patch to add prepared statement support to
> Django for the PostgreSQL backend. Note that it's just a hack to see
> if this approach could work at all, I know it's badly written. :)
>
> The patch is qu
Hi all,
I'm sure you've all heard of the upcoming DjangoCon Europe. Of special
interest to Django Developers will be the sprints, on the 9th & 10th
of June. We've got a very special location:
http://djangocon.eu/venues/#sprint_venue
Of further interest: the sprints will run for 48 hours straight.
Nice!!!
But, at over 500 euros, and the hotel costing 140 euros per night, I
probably won't be able to attend.. (just simply can't justify spending 1000
euros on a conference, no matter how awesome it is lol).
I'll look forward to seeing the slides / pictures though!
Cal
On Tue, Apr 5, 2011 at
> 1) It's almost illegible. Between your mail client's munging of line
> wrapping, and the completely unreadable code samples, it's very
> difficult to tell if you have presented a good idea.
Pardon the format. I actually auto-wrapped the text with vim and copy
pasted at the first time. Realizing
As a side note: I encountered the use case for customizing
serialization last summer when building my own blog project (I wanted
an app that could import/export my models from/to wordpress/blogger
XML. The API I proposed largely emerged from my thought back then. I'm
willing to commit efforts to ma
On Wed, Apr 6, 2011 at 7:44 AM, DaNmarner wrote:
>> 1) It's almost illegible. Between your mail client's munging of line
>> wrapping, and the completely unreadable code samples, it's very
>> difficult to tell if you have presented a good idea.
>
> Pardon the format. I actually auto-wrapped the tex
I started writing the draft for a full proposal, however, I don't have
time to finish it today as I have to revise for tomorrow's exam. I
will try to finish it in 12 hours at most since I know I'm already
posting it a little bit too late to make it possible to review it
thoroughly.
Anyway, I'll po
> So - show me what it would look like. Show me how I, as a third party,
> would use your proposed syntax to define output that would match
> Django's existing serialization scheme. Yes, this serialization format
> will exist as a built in default; but I should be able to reproduce
> that format in
On Wed, Apr 6, 2011 at 11:31 AM, DaNmarner wrote:
>> So - show me what it would look like. Show me how I, as a third party,
>> would use your proposed syntax to define output that would match
>> Django's existing serialization scheme. Yes, this serialization format
>> will exist as a built in defa
> The purpose of this project is to define (and then implement) a DSL
> for serialization.
If a DSL is what you are looking for, then I withdraw my proposal.
The idea of hosting yet another DSL inside Django project scares me a
little.
I'll just implement my idea as a separate project, I guess.
Am 06.04.2011 um 02:45 schrieb Michal Petrucha:
[snip]
> unique and db_index
> ~~~
> Implementing these will require some modifications in the backend code.
> The table creation code will have to handle virtual fields as well as
> local fields in the table creation and index crea
17 matches
Mail list logo
