Reset Management Command Design Issue

I'm was confirming ticket #2493 (Error resetting app with self- referencing ForeignKey) this evening and as I began to poke into it it appears that the fix is what mtredinnick recommended, to use introspection to get the foreign key relation name when constructing the alter table drop statement fo

Re: Django 1.0 features -- the definitive list

On Nov 30, 11:38 pm, Brian Rosner <[EMAIL PROTECTED]> wrote: > On Nov 30, 7:27 pm, Gary Wilson <[EMAIL PROTECTED]> wrote: > > > > > Adrian Holovaty wrote: > > > Without further ado, here's my list: > > > > * newforms-admin > > > * queryset-refactor > > > * django.newforms becomes django.forms >

Re: Django 1.0 features -- the definitive list

On Nov 30, 7:27 pm, Gary Wilson <[EMAIL PROTECTED]> wrote: > Adrian Holovaty wrote: > > Without further ado, here's my list: > > > * newforms-admin > > * queryset-refactor > > * django.newforms becomes django.forms > > * Model-level validation > > * Change django.templatetags not to use __path__

Django Web site down for Media Temple scheduled maintenance

There's a bit of bad news for the sprint happening today -- the djangoproject.com site is down for scheduled maintenance by Media Temple. Some information is here: http://weblog.mediatemple.net/weblog/category/system-incidents/electrical-systems-maintenance-notice-nov-30th/ According to that ann

Re: DB API - the limiting syntax, is it magic?

To clarify, code such as the following can be a little confusing: p = MyModel.objects.filter(foo__id = self.id).order_by('-timestamp')[: 1] if p: return p[0] To a python developer who is unfamiliar with django's magic limiting syntax, the slice there looks unnecessary. Writing objects.filte

Re: Django 1.0 features -- the definitive list

On Nov 30, 6:33 am, "Adrian Holovaty" <[EMAIL PROTECTED]> wrote: > What am I forgetting? 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 a

DB API - the limiting syntax, is it magic?

Hi all, I was in two minds about writing this as a ticket, mainly because I understand that it is something that is a design decision. Okay so the issue I came across today was that one of my python developers changed some syntax on one of my views with loads some data from the database, this par

Re: Suggestion: DEPs - Django Enhancement Proposals

On Dec 1, 2:02 am, 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. For further context it's worth reading PEP 1, which describes PEPs and how they work: http://www.python.org/d

Re: Django 1.0 features -- the definitive list

Adrian Holovaty wrote: > Without further ado, here's my list: > > * newforms-admin > * queryset-refactor > * django.newforms becomes django.forms > * Model-level validation > * Change django.templatetags not to use __path__ hacking > * #3591 -- Make INSTALLED_APPS an instance, and each app an ins

Re: Django 1.0 features -- the definitive list

On Fri, 2007-11-30 at 00:33 -0600, Adrian Holovaty wrote: > (I've been saving this e-mail since the last sprint. Given that we're > sprinting again this weekend, I figured it was about time to get this > conversation started.) > > Let's get a definitive list of features we want in Django 1.0, and

Re: Suggestion: DEPs - Django Enhancement Proposals

+1 from me, this also a document that developers can look at and plan around very succinctly. On Dec 1, 2007 3:02 PM, 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. At the mo

Suggestion: DEPs - Django Enhancement Proposals

Here's an idea that's been kicking around in the back of my head for far too long: Django Enhancement Proposals, or DEPs. At the moment, large changes to Django (auto escaping, queryset refactor etc) are discussed in quite an ad-hoc way - if you want to stay completely up to date on them you need

Re: Django 1.0 features -- the definitive list

On Nov 30, 6:33 am, "Adrian Holovaty" <[EMAIL PROTECTED]> wrote: > I think we ought to call the release 2.0. I'm -0.5 on this (if that's possible). I understand the thinking behind it, but "1.0" isn't an arbitrary version number - it has a very specific meaning: "the APIs are frozen, it's safe to

Re: Django 1.0 features -- the definitive list

On Dec 1, 12:37 am, "Patryk Zawadzki" <[EMAIL PROTECTED]> wrote: > 2007/11/30, Forest Bond <[EMAIL PROTECTED]>: > > > On Fri, Nov 30, 2007 at 12:33:31AM -0600, Adrian Holovaty wrote: > > > * #285 -- WSGI SCRIPT_NAME and PATH_INFO stuff > > > Aren't there SCRIPT_NAME/PATH_INFO/etc. problems with mo

Re: from django.template import Template, gives me this output

thx , i'll read through that now, firedancer On Nov 30, 4:48 pm, "Waylan Limberg" <[EMAIL PROTECTED]> wrote: > I'd suggest reading the docs. If your trying to use the template > system by itself. This [1] should answer your question. > > [1]:http://www.djangoproject.com/documentation/templates_p

Re: Django 1.0 features -- the definitive list

Is this set for 2009? ;) About subclassing, what was agreed upon? I'm going to rip my hair out if it does OneToOne relations and strange db queries :P I think the major features listed here are good -- qsrf is the biggest one I want in.. come on .98? :) On Nov 30, 9:49 am, "Bryan L. Fordham" <[

Re: Django 1.0 features -- the definitive list

twas a joke. i don't think any of the authors of any of the evolution mechanisms believe their implementations ready to be included into v1.0. (my own included :) Adrian Holovaty wrote: > On Nov 30, 2007 11:56 AM, Derek Anderson <[EMAIL PROTECTED]> wrote: >> what, no schema evolution? =p >

Re: Django 1.0 features -- the definitive list

> Let's get a definitive list of features we want in Django 1.0, and > let's release it. Is it the consensus that multi-database isn't ready enough to be included? If MDB is likely to have some backwards incompatible changes then maybe it's worth considering, otherwise it doesn't really look like

Re: from django.template import Template, gives me this output

I'd suggest reading the docs. If your trying to use the template system by itself. This [1] should answer your question. [1]: http://www.djangoproject.com/documentation/templates_python/#configuring-the-template-system-in-standalone-mode On Nov 30, 2007 3:29 PM, firedancer <[EMAIL PROTECTED]> w

Re: from django.template import Template, gives me this output

On 11/30/07, firedancer <[EMAIL PROTECTED]> wrote: > i'm new to using django , > i would like to proceed with it , > > your help will be more then appreciated Your best hope is to thoroughly read the official Django tutorial, which explains the need to either use manage.py or properly state which

Re: [Fwd: Re: Consistency between Django syndication framework & generic views (at least)]

Malcolm Tredinnick a écrit : > Could you please describe the problem you're asking about? I don't want > to have to watch a screencast to try and work out what the issue is > here. Yep sorry I could have provided more details. So on one side, you have generic views, in which the default name of

from django.template import Template, gives me this output

Hi, I just started my django quest, but when i started the "Template" part , i found out that not everything is set correct . this is it : >>> from django.template import Template Traceback (most recent call last): File "", line 1, in File "/var/lib/python-support/python2.5/django/template

Add extension support to Markdown filter (ticket #2910)

Unfortunately, I won't be available for the sprint this weekend (except maybe an hour or two). Anyway, ticket #2910 [1] (Add extension support to Markdown filter) has been around for more than a year and now that auto-escaping has landed, I feel is ready for checking in - that is assuming the core

Re: [Fwd: Re: Consistency between Django syndication framework & generic views (at least)]

On Fri, 2007-11-30 at 19:39 +0100, Nicolas Steinmetz wrote: > As I did not get answer from the user list, I try on the dev list. > > Such consistency may also be nice in the {1[2}.O coming. Could you please describe the problem you're asking about? I don't want to have to watch a screencast to

Re: Django 1.0 features -- the definitive list

On Nov 30, 2007 11:56 AM, Derek Anderson <[EMAIL PROTECTED]> wrote: > what, no schema evolution? =p Schema evolution falls squarely in the category of "inessential for this version, but can always be added in a subsequent incremental version without breaking backwards compatibility." Adrian --

[Fwd: Re: Consistency between Django syndication framework & generic views (at least)]

As I did not get answer from the user list, I try on the dev list. Such consistency may also be nice in the {1[2}.O coming. Message original Sujet: Re: Consistency between Django syndication framework & generic views (at least) Date: Tue, 27 Nov 2007 00:46:16 -0800 (PST) De:

Re: Django 1.0 features -- the definitive list

what, no schema evolution? =p (ducks for cover behind fire-retardant suit ;) Adrian Holovaty wrote: > (I've been saving this e-mail since the last sprint. Given that we're > sprinting again this weekend, I figured it was about time to get this > conversation started.) > > Let's get a definiti

Re: Django 1.0 features -- the definitive list

On Nov 30, 7:33 am, "Adrian Holovaty" <[EMAIL PROTECTED]> wrote: > And, finally, a bit of a controversial statement, but... > > I think we ought to call the release 2.0. Well, there are lots of precedents. Emacs went from 1.12 to 13.0 at some point, so the jump from 0.96 to 2.0 does not seem tha

Re: Django 1.0 features -- the definitive list

> > On the issue of what to call 1.0, I like Max Battcher's idea of > adopting an Ubuntu-like date-based version. Puts some useful > information (how old is it?) into the release name and avoids > preconceived notions of stability/completeness associated with .0 > releases. I'm +1 on that as

Re: SQL Server support: In core for "1.0" or external-only?

On Fri, 2007-11-30 at 08:12 -0800, Adam V. wrote: > The SQL Server backend in trunk is basically broken (parameter > replacement doesn't work right), as well as missing features > (introspection being the big one.) > > There have been many proposed patches, though lots of them go back to > 0.91,

Re: Django 1.0 features -- the definitive list

On 11/30/07, Malcolm Tredinnick <[EMAIL PROTECTED]> wrote: > > [snip] > > We're currently leaning more towards Joseph Kocherhans' replacement for > form_for_* (not sure how backwards compatible it will end up) and whilst > "nice to have", I don't see this as show stopper stuff for 1.0. > > Except I

Re: Django 1.0 features -- the definitive list

2007/11/30, Malcolm Tredinnick <[EMAIL PROTECTED]>: > On Fri, 2007-11-30 at 16:46 +0100, Patryk Zawadzki wrote: > > For my needs: > > > > * Extendable results of form_for_{instance,model} (sometimes you just > > need to override one field in a large form) > > * Sortable fields on forms extending o

SQL Server support: In core for "1.0" or external-only?

The SQL Server backend in trunk is basically broken (parameter replacement doesn't work right), as well as missing features (introspection being the big one.) There have been many proposed patches, though lots of them go back to 0.91, and make lots of changes outside of the backend as well. On m

Re: Django 1.0 features -- the definitive list

On Fri, 2007-11-30 at 16:46 +0100, Patryk Zawadzki wrote: > 2007/11/30, Adrian Holovaty <[EMAIL PROTECTED]>: > > Without further ado, here's my list: > > > > * newforms-admin > > * queryset-refactor > > * django.newforms becomes django.forms > > * Model-level validation > > * Change django.templa

Re: Django 1.0 features -- the definitive list

2007/11/30, Adrian Holovaty <[EMAIL PROTECTED]>: > Without further ado, here's my list: > > * newforms-admin > * queryset-refactor > * django.newforms becomes django.forms > * Model-level validation > * Change django.templatetags not to use __path__ hacking > * #3591 -- Make INSTALLED_APPS an inst

Re: Django 1.0 features -- the definitive list

On 11/30/07, Etienne Robillard <[EMAIL PROTECTED]> wrote: > I think it would be great if Django-1.0 (and subsequent releases) be > backward-compatible with Django-0.96... For the most part, it will be; most of the post-0.96 changes have been/will be "under the hood." You can see the list of chang

Re: Django 1.0 features -- the definitive list

Ivan Sagalaev wrote: > > Adrian, people will rip you apart for omitting streamed file upload :-). >Though I believe it will require a lot of effort since the main > ticket on the subject (#2070) looks scary. Ohh yeah, that's one feature I'd love to see go in. An awful lot of work has gon

Re: Django 1.0 features -- the definitive list

On Friday 30 November 2007 06:33:31 Adrian Holovaty wrote: > Without further ado, here's my list: > > * newforms-admin > * queryset-refactor > * django.newforms becomes django.forms > * Model-level validation > * Change django.templatetags not to use __path__ hacking > * #3591 -- Make INSTALLED_A

Re: Django 1.0 features -- the definitive list

Hi, On Fri, Nov 30, 2007 at 08:12:14AM -0600, Malcolm Tredinnick wrote: > On Fri, 2007-11-30 at 08:33 -0500, Forest Bond wrote: > > On Fri, Nov 30, 2007 at 12:33:31AM -0600, Adrian Holovaty wrote: > > > * #285 -- WSGI SCRIPT_NAME and PATH_INFO stuff > > > > Aren't there SCRIPT_NAME/PATH_INFO/etc.

Re: Django 1.0 features -- the definitive list

Etienne Robillard wrote: > > > On Nov 30, 2007 2:27 AM, Max Battcher <[EMAIL PROTECTED] > > wrote: > > > On Nov 30, 2007 2:18 AM, jj <[EMAIL PROTECTED] > > wrote: > > move 0.96 to 1.0 status. This might sound somewhat artificial

Re: Django 1.0 features -- the definitive list

On Nov 30, 2007 2:27 AM, Max Battcher <[EMAIL PROTECTED]> wrote: > > On Nov 30, 2007 2:18 AM, jj <[EMAIL PROTECTED]> wrote: > > move 0.96 to 1.0 status. This might sound somewhat artificial, but > > would clearly indicate that 0.96 is a version one can already trust. > > Isn't the Web site already

Re: Django 1.0 features -- the definitive list

On 30-Nov-07, at 6:14 PM, Deryck Hodge wrote: > +1 > > It's not an unprecedented idea across OSS projects. We jumped from > samba 3.0.14 to 3.0.20 when we had a slew of new changes between > releases. Granted those are dot releases, but the idea is the same. and postgres jumped from 7.4.x to

Re: Django 1.0 features -- the definitive list

On Fri, 2007-11-30 at 02:27 -0500, Max Battcher wrote: > On Nov 30, 2007 2:18 AM, jj <[EMAIL PROTECTED]> wrote: > > move 0.96 to 1.0 status. This might sound somewhat artificial, but > > would clearly indicate that 0.96 is a version one can already trust. > > Isn't the Web site already advocating

Re: Django 1.0 features -- the definitive list

On Fri, 2007-11-30 at 08:33 -0500, Forest Bond wrote: > On Fri, Nov 30, 2007 at 12:33:31AM -0600, Adrian Holovaty wrote: > > * #285 -- WSGI SCRIPT_NAME and PATH_INFO stuff > > Aren't there SCRIPT_NAME/PATH_INFO/etc. problems with mod_python, too? It'd > be > nice if django 1.0-based apps could

Re: Django 1.0 features -- the definitive list

2007/11/30, Forest Bond <[EMAIL PROTECTED]>: > On Fri, Nov 30, 2007 at 12:33:31AM -0600, Adrian Holovaty wrote: > > * #285 -- WSGI SCRIPT_NAME and PATH_INFO stuff > > Aren't there SCRIPT_NAME/PATH_INFO/etc. problems with mod_python, too? It'd > be > nice if django 1.0-based apps could be moved t

Re: Django 1.0 features -- the definitive list

On Fri, Nov 30, 2007 at 12:33:31AM -0600, Adrian Holovaty wrote: > * #285 -- WSGI SCRIPT_NAME and PATH_INFO stuff Aren't there SCRIPT_NAME/PATH_INFO/etc. problems with mod_python, too? It'd be nice if django 1.0-based apps could be moved to different relative mount points without changing .py fil

Re: Django 1.0 features -- the definitive list

Sorry for the shameless messing in, but... if you want a release to be considered rock-stable and proven from the beginning,.. never name it 2.0. Neither 1.0. Nor any *.0. "Anything-dot-zero" obviously stands for "just released after a rush to fit into the deadline" and implies "let's wait for oth

Re: Django 1.0 features -- the definitive list

On Nov 30, 2007 12:33 AM, Adrian Holovaty <[EMAIL PROTECTED]> wrote: > And, finally, a bit of a controversial statement, but... > > I think we ought to call the release 2.0. > +1 It's not an unprecedented idea across OSS projects. We jumped from samba 3.0.14 to 3.0.20 when we had a slew of new

Re: Django 1.0 features -- the definitive list

On 30 Nov 2007, at 6:33 am, Adrian Holovaty wrote: > My second reason for choosing 2.0 is, shall we say, less wholesome. > After having endured a 2.5+ year deluge of "When is 1.0 coming out?" > blog entries, comments, e-mails and in-person confrontations from > people all around the world, I wou

Re: Django 1.0 features -- the definitive list

Adrian Holovaty wrote: > (I've been saving this e-mail since the last sprint. Given that we're > sprinting again this weekend, I figured it was about time to get this > conversation started.) > > Let's get a definitive list of features we want in Django 1.0, and > let's release it. > > I'll start