On Fri, 2007-03-16 at 11:05 +0900, Russell Keith-Magee wrote:
> On 3/16/07, Malcolm Tredinnick <[EMAIL PROTECTED]> wrote:
> >
> > When I was talking about using the serialisation framework before, I
> > wasn't actually thinking of going via the database: just serialising
> > using the lower-level
On 3/15/07, Michael Radziej <[EMAIL PROTECTED]> wrote:
> The point is: It's not possible to extend the session in a
> upwards-compatible way, because there's no way to make sure
> that INSERT is used when you need to set the pk before save().
Again, I'm not disagreeing with the INSERT/UPDATE
Russell Keith-Magee wrote:
> Hi all,
>
> On the users list, Gijs <[EMAIL PROTECTED]> has raised the idea
> of dynamic fixtures.
Well, I hate to pitch my own project, but consider my NonMockObjects:
http://www.jerf.org/programming/nonMockObjects.html
API docs. explanation, tutorial:
On 3/16/07, Malcolm Tredinnick <[EMAIL PROTECTED]> wrote:
>
> When I was talking about using the serialisation framework before, I
> wasn't actually thinking of going via the database: just serialising
> using the lower-level stuff from dictionaries or whatever. Admittedly
> some helper functions
Personally, I do think there would be some benefit in this type of
behavior. Trying to create a bunch of test data can be a pain. For
instance, you can do it programmatically with Python but then you end
up with the cycle of :
- Populate data from scripts
- Dump to a serialized form
- Load into
On Fri, 2007-03-16 at 09:44 +0900, Russell Keith-Magee wrote:
> On 3/16/07, Malcolm Tredinnick <[EMAIL PROTECTED]> wrote:
> >
> > > would define a fixture with 1000 instances of an object.
> >
> > I have to ask a dumb question first: what is this sort of thing useful
> > for? More importantly,
On 3/16/07, Malcolm Tredinnick <[EMAIL PROTECTED]> wrote:
>
> > would define a fixture with 1000 instances of an object.
>
> I have to ask a dumb question first: what is this sort of thing useful
> for? More importantly, why can't it be done by using existing our
> existing serialisation
Hey Russ,
On Fri, 2007-03-16 at 08:55 +0900, Russell Keith-Magee wrote:
> Hi all,
>
> On the users list, Gijs <[EMAIL PROTECTED]> has raised the idea
> of dynamic fixtures. For example, Rails allows the use of embedded
> Ruby in a fixture file, so that:
>
> <% for i in 1..1000 %>
> fix_<%= i
Hello,
I'm planning on submitting a google summer of code project related to
the admin for rich media support that includes integrating filebrowser
and tinyMCE, deleting multiple items at once, friendly large files
support, etc. As the admin is being re-designed/written right now I
was wondering
Hi all,
On the users list, Gijs <[EMAIL PROTECTED]> has raised the idea
of dynamic fixtures. For example, Rails allows the use of embedded
Ruby in a fixture file, so that:
<% for i in 1..1000 %>
fix_<%= i %>:
id: <%= i %>
name: guy_<%= 1 %>
<% end %>
would define a fixture with 1000
If Django wasn't successful in their application to GSoC, a couple of
mentors could sign up under the auspices of the Python Software
Foundation. I can't guarantee how many slots you'd get (if any) but
it's worth a try. A bunch of Python-related projects that didn't get
accepted in their
On Thu, 2007-03-15 at 17:24 -0500, Jeremy Dunck wrote:
> On 3/15/07, Malcolm Tredinnick <[EMAIL PROTECTED]> wrote:
[...]
> > I would probably call out to another function somewhere to do the real
> > registration,
>
> Sorry, can you pseudo-code this? I'm not sure what you mean by
> another
On 3/15/07, Malcolm Tredinnick <[EMAIL PROTECTED]> wrote:
...
> Looking at the code I've written, I think the only potential problem
> tnhat jumps out is that constructing some of these things is
> database-engine specific (some of the text matching options,
> potentially), so having access to
On Thu, 2007-03-15 at 16:42 -0500, Jeremy Dunck wrote:
> On 2/25/07, Malcolm Tredinnick <[EMAIL PROTECTED]> wrote:
> >
> > I noticed today that a new GIS branch has been created, which includes a
> > goal to develop a custom QuerySet-derivative.
> ...
> > I don't know of any announced
On 2/25/07, Malcolm Tredinnick <[EMAIL PROTECTED]> wrote:
>
> I noticed today that a new GIS branch has been created, which includes a
> goal to develop a custom QuerySet-derivative.
...
> I don't know of any announced plans/wishes that affect QuerySets that
> would become more difficult under
On 3/14/07, Benjamin Slavin <[EMAIL PROTECTED]> wrote:
> Do we really need to re-seed the RNG? What if we did something like:
> session_key = md5.new("%x%s%s" % (random.getrandbits(64),
> datetime.datetime.utcnow(), settings.SECRET_KEY)).hexdigest()
That works too :)
I'm just wanting anything
On Thu, 2007-03-15 at 03:09 -0700, ak wrote:
> Malcolm, ofcourse I can rewrite it as a patch to current session
> module but I think you should understand that anyone who will do svn
> update would get broken session module because of extra field in
> django_session table.
> If it is ok, please
I only get digest messages from this group, so I've responded to
several messages inline. Apologies in advance if this breaks
threading.
James Bennett said:
> On 3/13/07, Michael Radziej <[EMAIL PROTECTED]> wrote:
> > a) the client can sit behind a NAT that might hand out different IPs
> > b)
On 3/14/07, Arvind Singh <[EMAIL PROTECTED]> wrote:
> What I don't understand is: Why the developers don't do the correct
> thing by providing separate insert() and update() in addition to
> save() ? All it requires is a trivial refactoring and actually
> simplifies the code (also clarifying the
> Because doing so would introduce some backward incompatibilities.
Thats not true, if you provide a save()-method that calls either
update() or insert(). save() should not be removed, it makes many things
very easy. So only additional flexibility is added without removing or
changing any
On Wed, 14 Mar 2007 20:34:11 -0500, Arvind Singh <[EMAIL PROTECTED]>
wrote:
>
>> 1. Manually seeding the RNG with a value unique to the server process,
>> or to the request, would move the probability of key collision closer
>> to what it "should" be, thus dramatically reducing the problem.
>
> One reason it isn't there is because many of the use cases that require
> differentiating between updating and creating a new object can already
> be implemented without extra code. Requiring an application developer to
> always specify update or create anew when it can usually be inferred
>
Hi list,
After reading the list of mentoring organizations of Google's Summer
of Code 2007 [1] I'm quite confused aboout not finding Django on it.
Any ideas what went wrong?
Best,
Jannis Leidel
1: http://code.google.com/soc
Am 13.03.2007 um 21:44 schrieb Jacob Kaplan-Moss:
>
> Howdy
On Thu, Mar 15, ak wrote:
>
> Malcolm, ofcourse I can rewrite it as a patch to current session
> module but I think you should understand that anyone who will do svn
> update would get broken session module because of extra field in
> django_session table.
> If it is ok, please answer and I
Malcolm, ofcourse I can rewrite it as a patch to current session
module but I think you should understand that anyone who will do svn
update would get broken session module because of extra field in
django_session table.
If it is ok, please answer and I will prepare patch in an hour
(without ip
Instead of passing the complete template context to its filter,
django.template.FilterNode passes a new Context instance containing only
the "var" key, whose value is the rendered content of the block. In
other words, this contrived example works:
{{ obj|cut:request.GET.cut }}
This one,
26 matches
Mail list logo
