Django developers Google Group

Re: A (last-minute) compromise on {% url %}

2008-08-30T15:50:12Z

+1 for a sweet feature.

Re: Working on comments

2008-08-30T14:48:33Z

Hey Bruce,

Reading between the lines, I think you meant to post this in Satchmo-
dev ;) Nonetheless, this is good news!

-Chris

Re: Does CharField still required max_length? Or is it a bug?

2008-08-30T12:40:33Z

I don't believe this is correct. A CharField needs a max_length parameter
to pass validation. You may not need it for issuing test queries, etc. in a
manage.py shell, but it is still needed in general, as documented:
[link]
Karen
p.s. This conversation really belongs on django-users, please follow up

Re: Does CharField still required max_length? Or is it a bug?

2008-08-30T04:56:39Z

Yes, it has been made optional with this syntax class CharField(*
max_length=None*[, ***options*])
This is true for all other model fields as well that were expecting
max_length parameter.
Regards,
Shihan

Working on comments

2008-08-30T06:40:39Z

I'm mostly through with a drop-in replacement for the old comments, using
the new Comment system and signals. It should be slick.
When it tests out, I'll also commit the new save() parameters mentioned in
the backwards-incompatible page, and we should be again compatible with the
latest Django trunk.

Does CharField still required max_length? Or is it a bug?

2008-08-30T04:49:20Z

hi,all
I use django beta2 and find that model's charfield doesn't require
max_length parameter anymore. Is there any thing wrong?

Re: 500 error if django run in scgi mode(fcgi is ok)

2008-08-29T20:33:53Z

If you want a response, you will need to ask this on the django-users
list. This list is for the discussion of developing the Django
framework itself.

Re: A (last-minute) compromise on {% url %}

2008-08-29T19:07:35Z

Am 29.08.2008 um 17:18 schrieb Jacob Kaplan-Moss:
Hell, no! That's perfect and also works with blocktrans.
..and let's us kill that captureas in Pinax, yay!
Cheers,
Jannis

Re: queryset set difference

2008-08-29T18:02:56Z

And because I wasn't concentrating about which list I was reading, here
comes the obligatory statement:
Please take any follow-ups to django-users. This mailing list is
for the internal development of Django itself. "How to use"
questions should go to the django-users mailing list.

Re: queryset set difference

2008-08-29T18:00:37Z

If they already exist as querysets, the set difference is the way to go.
There's probably no need to turn it back into a list at the end, since
Python's sets are iterable containers. It depends what you want to do
with it afterwards.
However, if you know the filters you are applying, you can get the

queryset set difference

2008-08-29T17:51:29Z

I have 2 querysets q1 and q2.

I want q3 = q2-q1, where q3 is a queryset object and contains only the
objects in q2 that are not in q1.

Is there built in support for this operation?

The only thing I can think to do is:
list( set(q2) - set(q1) )
It doesn't return a queryset, but I can deal with it if there's no

Re: A (last-minute) compromise on {% url %}

2008-08-29T15:53:28Z

+1 -- Pinax could deprecate {% captureas %} with this feature. Seems
like a non-intentional pro :)

Re: A (last-minute) compromise on {% url %}

2008-08-29T15:43:48Z

Le 29 août 08 à 17:18, Jacob Kaplan-Moss a écrit :
+1 for this, before I test if someone already knows the answer, is it
possible to use this var in blocktrans?
{% url args as myurl %}
{% blocktrans %}
foo <a href="{{ myurl }}">baz</a>
{% endblocktrans %}
That's potentially the best solution for the endless discussion about

A (last-minute) compromise on {% url %}

2008-08-29T15:18:49Z

Hi folks --
While working on some URL-related issues, I ran across a pretty big
problem with having ``{% url %}`` propagate ``NoReverseMatch`` up into
the templates: if it does that, there's no way to have "optional"
links. The perfect example is #7810 and the admin docs: if the URLs
for the admin doc views are installed, the admin should show a

Re: Recover/Reset password on code.djangoproject.com

2008-08-29T14:16:55Z

[link]
Jacob