Malcolm Tredinnick wrote:
> Anybody have strong objections to ticket #5524: not completely nuking
> form.cleaned_data is a form instance has any non-zero validation errors?
No objections here, seems like the Right Thing to do. My data was cleaned,
keep it that way.
Gary
Derek Anderson wrote:
> even if it was possible, i don't think it's what you would really want.
> logically, this would return an indefinite number of records,
> somewhere between 0 and 10, depending on what's in your table, not the
> first 10 records of people who's name starts w/ an 'a'.
even if it was possible, i don't think it's what you would really want.
logically, this would return an indefinite number of records,
somewhere between 0 and 10, depending on what's in your table, not the
first 10 records of people who's name starts w/ an 'a'.
why are you not doing this?
It is recommended to evaluate a QuerySet by calling list() on it. Problem is,
now you have a list and not a QuerySet. Just thinking it might be nice to
have an evaluate() method that would return a QuerySet object with the result
cache filled.
Now, if only I could think of a use case ;)
Gary
Is there any reason why the following is disallowed:
>>> UTPerson.objects.all()[:10].filter(name__startswith='a')
Traceback (most recent call last):
...
AssertionError: Cannot filter a query once a slice has been taken.
I would think that it should be possible as long as the QuerySet hasn't
Adrian Holovaty wrote:
> On Dec 2, 2007 11:50 PM, James Bennett <[EMAIL PROTECTED]> wrote:
>> I guess I'm curious as to what's difficult or error-prone about it;
>> I've never run into a problem where slicing was the cuplrit, and it
>> feels like a more intuitive and Pythonic syntax than the
Don't overlook the marketing aspect. Trust disappears without visible
progress. Visible progress comes from version numbers. The more often,
the better. 0.96 has been out 9 months already. You mention an extra
8-9 months for 2.0/1.0 (from what I understand in another thread).
Experience says it
On Dec 3, 2007 2:47 PM, Malcolm Tredinnick <[EMAIL PROTECTED]> wrote:
> Anybody have strong objections to ticket #5524: not completely nuking
> form.cleaned_data is a form instance has any non-zero validation errors?
No objections here -- it actually looks like it could be useful, even. :-)
On 12/3/07, Malcolm Tredinnick <[EMAIL PROTECTED]> wrote:
> Anybody have strong objections to ticket #5524: not completely nuking
> form.cleaned_data is a form instance has any non-zero validation errors?
The only objection I'd have is that it would enable naive code to
screw up by just looking
On Dec 4, 2007 5:47 AM, Malcolm Tredinnick <[EMAIL PROTECTED]> wrote:
>
> Adrian, Russell, Gary:
>
> Anybody have strong objections to ticket #5524: not completely nuking
> form.cleaned_data is a form instance has any non-zero validation errors?
>
> I'm pretty much "don't care" and I gather Jacob
On Dec 2, 2007 7:31 AM, Malcolm Tredinnick <[EMAIL PROTECTED]> wrote:
>
>
> On Fri, 2007-11-30 at 20:00 -0800, [EMAIL PROTECTED] wrote:
> > To clarify, code such as the following can be a little confusing:
> >
> > p = MyModel.objects.filter(foo__id = self.id).order_by('-timestamp')[:
> > 1]
> >
On 12/3/07, mtrier <[EMAIL PROTECTED]> wrote:
> It looks like the cron jobs to update the Django Updates google group
> are not working since the server restart. It also appears that the
> community updates are not happening as well.
Thanks for the note; I'll try to figure it out. If you (or
On Dec 2, 2007 11:50 PM, James Bennett <[EMAIL PROTECTED]> wrote:
> I guess I'm curious as to what's difficult or error-prone about it;
> I've never run into a problem where slicing was the cuplrit, and it
> feels like a more intuitive and Pythonic syntax than the "limit" and
> "offset" arguments
2007/12/3, Malcolm Tredinnick <[EMAIL PROTECTED]>:
> On Mon, 2007-12-03 at 13:09 -0800, David Cramer wrote:
> > For the most part I'm just doing if request.POST to validate.
>
> This isn't completely sufficient because it's possible to submit a form
> via POST with no data (e.g. a form with
It looks like the cron jobs to update the Django Updates google group
are not working since the server restart. It also appears that the
community updates are not happening as well.
Michael
--~--~-~--~~~---~--~~
You received this message because you are
I tried old versions of twill, and it seemed to work correctly in
0.8.4, but version 0.8.5 introduced this duplicating behavior. I can
see that the application result reading mechanism was heavily modified
at that point.
Here are relevant snippets of the source for your convenience.
twill
(twill 0.9b1 is of course as close as saying "easy_install twill" if
you have setuptools installed)
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to
Here is a simple test case. Place twilltest.py and urls.py in a
directory and run "PYTHONPATH=. python twilltest.py". Make sure Django
and twill exist in your PYTHONPATH.
--- twilltest.py -
#!/usr/bin/python
from django.conf import settings
I'm desperately trying to get twill to work together with Django using
twill's WSGI intercepting.
The problem is, I always get the content of the page concatenated
twice together. I've debugged and narrowed down the problem so it must
be either in twill.wsgi_intercept.wsgi_fake_socket.makefile()
On Mon, 2007-12-03 at 13:09 -0800, David Cramer wrote:
> For the most part I'm just doing if request.POST to validate.
This isn't completely sufficient because it's possible to submit a form
via POST with no data (e.g. a form with checkboxes and maybe some fields
that aren't filled in). That's
On 12/3/07, David Cramer <[EMAIL PROTECTED]> wrote:
> For the most part I'm just doing if request.POST to validate.
The request.method attribute exists precisely for this purpose, so
that you can find out what the HTTP request method was ;)
--
"Bureaucrat Conrad, you are technically correct --
For the most part I'm just doing if request.POST to validate.
On Dec 3, 11:16 am, Malcolm Tredinnick <[EMAIL PROTECTED]>
wrote:
> On Mon, 2007-12-03 at 11:00 -0800, David Cramer wrote:
> > Just my 2 cents...
>
> > If you drop request.POST, request.GET, and replace them all with
> > request.DATA
Adrian, Russell, Gary:
Anybody have strong objections to ticket #5524: not completely nuking
form.cleaned_data is a form instance has any non-zero validation errors?
I'm pretty much "don't care" and I gather Jacob is about the same, but
it keeps cropping up in various disguises. For the record,
On 12/3/07, Karen Tracey <[EMAIL PROTECTED]> wrote:
> On 12/3/07, Joseph Kocherhans <[EMAIL PROTECTED]> wrote:
>
> >
> > On 12/3/07, Karen Tracey <[EMAIL PROTECTED]> wrote:
> > > In testing out the latest (r6864) newforms-admin branch I noticed that
> the
> > > change history for items I changed
On Dec 4, 4:39 am, Malcolm Tredinnick <[EMAIL PROTECTED]>
wrote:
> lazy() is complex enough without adding things we don't need.
I guess this is my point. It seems that lazy() has been made overly
complex for little gain.
> If there's a legitimate case where Django core needs this extra
>
On 12/3/07, Joseph Kocherhans <[EMAIL PROTECTED]> wrote:
>
>
> On 12/3/07, Karen Tracey <[EMAIL PROTECTED]> wrote:
> > In testing out the latest (r6864) newforms-admin branch I noticed that
> the
> > change history for items I changed always said "No fields changed." even
> > though I was changing
I'm also -1 on the strange names -- especially something like "Paris
1945" :P
On Dec 3, 11:51 am, "Adrian Holovaty" <[EMAIL PROTECTED]> wrote:
> On Dec 3, 2007 9:52 AM, Panos <[EMAIL PROTECTED]> wrote:
>
> > Having major releases include a nickname might be nice too (like
> > Ubuntu & OS X).
>
>
On Dec 3, 2007 9:52 AM, Panos <[EMAIL PROTECTED]> wrote:
> Having major releases include a nickname might be nice too (like
> Ubuntu & OS X).
>
> We could use Reinhardt's album titles, ie:
>
> "Django 2.0 - Paris 1945", "I'm using the Paris 1945 version", etc.
A vehement "no, no, no." Nicknames
On Dec 3, 2007 2:26 PM, James Bennett <[EMAIL PROTECTED]> wrote:
> I've got some half-assed code for this lying around actually; I'd
> envisioned something like 'django.views.generic.wsgi.wsgi_application'
> being a way to simply drop any WSGI application into a Django URLConf.
I don't know much
On 12/3/07, Karen Tracey <[EMAIL PROTECTED]> wrote:
> In testing out the latest (r6864) newforms-admin branch I noticed that the
> change history for items I changed always said "No fields changed." even
> though I was changing fields. Looking at the code I see it's because the
> old change
On 12/3/07, Simon Willison <[EMAIL PROTECTED]> wrote:
> I'd like to see the distance between a Django application (or a
> Django view) and WSGI as small as possible. Imagine if you could drop
> a Django view in to any WSGI container just by applying a WSGI-to-
> Django-view wrapper of some sort.
In testing out the latest (r6864) newforms-admin branch I noticed that the
change history for items I changed always said "No fields changed." even
though I was changing fields. Looking at the code I see it's because the
old change history code is commented out, with a big TODO comment. I don't
On Mon, 2007-12-03 at 11:03 -0800, David Cramer wrote:
> I just want to bring this up again, because Model Inheritance is a
> HUGE thing...
>
> I have not seen any final discussion on how it's going to work (http://
> code.djangoproject.com/wiki/ModelInheritance). Last I heard it was
> still up
On Mon, 2007-12-03 at 11:00 -0800, David Cramer wrote:
> Just my 2 cents...
>
> If you drop request.POST, request.GET, and replace them all with
> request.DATA -- we're going to again be branching away from Django
> trunk.
>
> For our uses -- POST and GET are completely different things --
>
I just want to bring this up again, because Model Inheritance is a
HUGE thing...
I have not seen any final discussion on how it's going to work (http://
code.djangoproject.com/wiki/ModelInheritance). Last I heard it was
still up in the air. If there are features that are unsure of, I don't
see
On 3 Dec 2007, at 08:15, James Bennett wrote:
> At that point I'd wonder why Django had any machinery for
> request/response processing, middleware, etc., given that what you're
> describing is more neatly handled by just writing a WSGI application
> and taking advantage of the existing tools.
Just my 2 cents...
If you drop request.POST, request.GET, and replace them all with
request.DATA -- we're going to again be branching away from Django
trunk.
For our uses -- POST and GET are completely different things --
whether you use one at a time or not is unrelated. Things should be
I would also recommend a different name -- maybe django-gcalender,
since its specific to the calender app. After all, Google is quite
big :)
On Dec 3, 9:03 am, "Jacob Kaplan-Moss" <[EMAIL PROTECTED]>
wrote:
> On 12/3/07, Patryk Zawadzki <[EMAIL PROTECTED]> wrote:
>
> > I know django-users might
For some unknown reason I am in love with this suggestion.
On Dec 3, 9:52 am, Panos <[EMAIL PROTECTED]> wrote:
> Having major releases include a nickname might be nice too (like
> Ubuntu & OS X).
>
> We could use Reinhardt's album titles, ie:
>
> "Django 2.0 - Paris 1945", "I'm using the Paris
On 12/3/07, Patryk Zawadzki <[EMAIL PROTECTED]> wrote:
> I know django-users might be a more suitable place for such
> announcements but I was hoping of getting some feedback from the devs
> on the quality part. It also is one of the projects that could benefit
> greatly from having model
On Mon, 2007-12-03 at 17:58 +0100, Patryk Zawadzki wrote:
> 2007/12/3, Jacob Kaplan-Moss <[EMAIL PROTECTED]>:
> > Hey Patryk --
> >
> > Looks cool!
> >
> > However, in the future please direct posts of this nature to
> > django-users. Django-dev is for discussion of developing *on* Django,
> >
2007/12/3, Jacob Kaplan-Moss <[EMAIL PROTECTED]>:
> Hey Patryk --
>
> Looks cool!
>
> However, in the future please direct posts of this nature to
> django-users. Django-dev is for discussion of developing *on* Django,
> not *with* it.
I know django-users might be a more suitable place for such
On 12/3/07, Kenneth Gonsalves <[EMAIL PROTECTED]> wrote:
> add your name and email address in the 'preferences' page of the
> wiki, and you will be allowed in
... or, even better, create an account at
http://www.djangoproject.com/accounts/register/.
Jacob
Hey Patryk --
Looks cool!
However, in the future please direct posts of this nature to
django-users. Django-dev is for discussion of developing *on* Django,
not *with* it.
Thanks!
Jacob
--~--~-~--~~~---~--~~
You received this message because you are subscribed
On 12/3/07, Thomas Güttler <[EMAIL PROTECTED]> wrote:
> Join both into one:
> http://www.djangoproject.com/documentation/
> http://www.djangobook.com/
This won't happen, for a bunch of reasons including the fact that the
licenses aren't compatible and the release schedules are drastically
On 12/3/07, Malcolm Tredinnick <[EMAIL PROTECTED]> wrote:
> -1 from me.
I think the best thing to do would be to split the difference a bit:
once all the features are in (see Adrian's high-level list from a few
days back) I'd like to release something called "1.0 alpha 1" or
something. Then we
On Monday 03 December 2007 15:35:27 Malcolm Tredinnick wrote:
> Ancient John (older programmer, who's been around the company
> for years):
> They used to do that. Then Google cut off the oxygen
> to the django-developers group and people stopped thinking clearly.
On 3 Dec 2007, at 15:45, Malcolm Tredinnick wrote:
> -1 from me.
>
> I've already responded at least three times on the users list why this
> wouldn't be a good idea. We should indeed do a release after that
> stuff
> is merged. It will be called 1.0 (or 2.0 or whatever).
Ta, should have
Having major releases include a nickname might be nice too (like
Ubuntu & OS X).
We could use Reinhardt's album titles, ie:
"Django 2.0 - Paris 1945", "I'm using the Paris 1945 version", etc.
--~--~-~--~~~---~--~~
You received this message because you are
On Mon, 2007-12-03 at 10:14 +, Simon Willison wrote:
> It's fantastic that 1.0 (or whatever it ends up being called) is now
> under serious discussion, but are there any plans for a numbered
> release before then? I've been asked by a few people if they should
> be running svn or a
On Mon, 2007-12-03 at 00:03 -0800, SmileyChris wrote:
> On Dec 3, 6:02 pm, Malcolm Tredinnick <[EMAIL PROTECTED]>
> wrote:
> > What method?
>
> lazy()
Of course it works. We're using it throughout Django for lazy
translations.
Keep in mind though that most of the stuff in django.utils is for
On Sun, 2007-12-02 at 23:28 -0600, Adrian Holovaty wrote:
> On Dec 2, 2007 8:31 AM, Malcolm Tredinnick <[EMAIL PROTECTED]> wrote:
> > On Fri, 2007-11-30 at 20:00 -0800, [EMAIL PROTECTED] wrote:
> > > To clarify, code such as the following can be a little confusing:
> > >
> > > p =
There is one other question I've been meaning to ask for a while. As
would be expected, this FileField work adds a good amount of code to
db/models/fields/__init__.py, including 3 new classes, which aren't
even Fields themselves (but they're needed to make the Fields work).
If I get my way, and
> The "Django Way" is essentially to work on the assumption that
> everything is as Django left it (or in a state that is compatible with
> Django's requirements). We provide handles to make integrating with
> legacy databases a little easier (such as allowing specification of
> db_column names,
Hi guys,
Maybe this will be of some interest:
http://code.google.com/p/django-google/
What I've done was basically wrap the Google Calendar API into Django
models and some utility functions for convenience. Would love to hear
from you about the quality of code as well as missing functionality.
Hi Karen and all,
> if effort were to be
> expended on solving this problem I'd rather approach it by seeing if there
> isn't some way to communicate to the django code the SQL bits needed to do
> the kind of ordering desired. Of course in taking this approach I'm
> assuming there is some way
> And, finally, a bit of a controversial statement, but...
>
> I think we ought to call the release 2.0.
>
+0 from me. I've never set much store by version numbers, but I
suppose
2.0 will suggest a bigger leap forward to most people - and there's
a lot of good stuff on that list.
Nick
On 12/1/07, Simon Willison <[EMAIL PROTECTED]> wrote:
>
> Here's an idea that's been kicking around in the back of my head for
> far too long: Django Enhancement Proposals, or DEPs.
+1 There are any number of big features - m2m intermediate tables (now
ticket #6095), model inheritance and
On 12/2/07, J. Clifford Dyer <[EMAIL PROTECTED]> wrote:
>
> One missing feature, which would be very helpful for our project is the
> ability to specify column names in the ManyToManyField definitions.
> There is a ticket (#785) that addresses this issue, with an attached
> patch.
>
>
On 12/1/07, mtrier <[EMAIL PROTECTED]> wrote:
>
> With the current design the table and foreign key information is
> pulled together from the model information itself. The problem with
> that is that if someone manually changes the name of an foreign key
> constraint or removes the constraint
On Nov 30, 2007 3:33 PM, Adrian Holovaty <[EMAIL PROTECTED]> wrote:
>
> Let's get a definitive list of features we want in Django 1.0, and
> let's release it.
+1
> I'll start with a proposed list, which no doubt has omissions. But
> first, here's a proposal for how to handle this:
...
> 2.
It's fantastic that 1.0 (or whatever it ends up being called) is now
under serious discussion, but are there any plans for a numbered
release before then? I've been asked by a few people if they should
be running svn or a numbered release - with auto-escaping now in
trunk it seems a new
On 11/30/07, Simon Willison <[EMAIL PROTECTED]> wrote:
> It's probably too big a feature to start talking about now, but I'd be
> really interested in seeing Django applications (in particular the
> URLconf part) unified with the concept of a Django view, so a Django
> application is a callable
On Dec 3, 6:02 pm, Malcolm Tredinnick <[EMAIL PROTECTED]>
wrote:
> What method?
lazy()
Maybe I just don't get how it is supposed to work, but the setattr
line seems wrong, at least for setting special method names.
Also confusing is that the docstring says "Results are not memoized;
the
> Without further ado, here's my list:
> ...
My whish: Use DRY (Don't repeat yourself) for the documentation:
Join both into one:
http://www.djangoproject.com/documentation/
http://www.djangobook.com/
And make the documentation (incl. API doc) available trough the development
server. Either in
65 matches
Mail list logo
