Django 1.0 features -- the definitive list

103 views
Skip to first unread message

Adrian Holovaty

unread,
Nov 30, 2007, 1:33:31 AM11/30/07
to django-d...@googlegroups.com
(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 with a proposed list, which no doubt has omissions. But
first, here's a proposal for how to handle this:

1. We decide on the list of features/changes.

1.5. Once the list is final, we do NOT add to it except in case of
an Act of God.

2. We set a deadline.

3. We work -- *primarily* on the list of features/changes, but
allowing some time for squeezing in any other small fixes that we have
time for.

4. Any feature that's not implemented by the deadline does NOT
make it into version 1.0. But fear not, because version 1.0 is not the
end of Django -- it's only the beginning!

5. Release, rejoice.

The first order of business is deciding the features/changes. I'll
kick it off with the list I've been keeping.

This is just my own list, of course, and I'm sure other
committers/contributors have other stuff. Please contribute! Just one
important thing to note: This list is for Big Stuff only. Do not
suggest features that would be able to be added/changed *after* the
1.0 release in a backwards-compatible way. The goal here is to have a
simple, concrete list of major things that need to be done to the
framework -- not a list of 4,000 tiny things.

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 instance
* #5361 -- File storage refactoring
* #285 -- WSGI SCRIPT_NAME and PATH_INFO stuff

What am I forgetting?

And, finally, a bit of a controversial statement, but...

I think we ought to call the release 2.0.

Jacob and I have talked in the past about how we should've called
magic-removal version 1.0. (This ended up being 0.95.) For all intents
and purposes, it *was* 1.0 in spirit -- it was the first major
refactoring of several parts of the framework, and it was a point for
me personally where I started to feel like an acceptable number of the
legacy warts from pre-open-sourcing had been removed.

So, that's one reason: philosophically, conceptually, in our minds, in
our hearts, we're really dealing with a 2.0 product. We know Django
rocks (and is rock-solid), and we should give it an appropriate
number.

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 would find it incredibly satisfying, in
a devilish way, to release this thing and slap a "2.0" on it. It would
underscore the project's stability while at the same time
demonstrating that version numbers are completely arbitrary.

It'd be like Google's IPO price, which was set to the mathematical
constant "e" -- a "we're not playing by your rules" message to Wall
Street.

Something to ponder!

Adrian

--
Adrian Holovaty
holovaty.com | djangoproject.com

Ivan Sagalaev

unread,
Nov 30, 2007, 1:55:56 AM11/30/07
to django-d...@googlegroups.com
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 instance
> * #5361 -- File storage refactoring
> * #285 -- WSGI SCRIPT_NAME and PATH_INFO stuff
>
> What am I forgetting?

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.

> I think we ought to call the release 2.0.

I would be -0 emotionally. I'm afraid nobody will understand the reason
just from the number and we'll have a whole lot of confusion ("where's
1.0 then?", "so those version numbers don't mean anything?", "what were
they smoking?")

James Bennett

unread,
Nov 30, 2007, 1:57:32 AM11/30/07
to django-d...@googlegroups.com
On 11/30/07, Adrian Holovaty <holo...@gmail.com> wrote:
> Let's get a definitive list of features we want in Django 1.0, and
> let's release it.

Sounds great to me :)

> What am I forgetting?

I'd add model subclassing to the list, if only because it feels as if
the API has been mostly agreed upon at this point, and a whole lot of
documentation updates/additions and possibly refactoring (there's
plenty of room for post-1.0 improvement, of course, but there are also
a lot of things we should document if we're going to commit to
maintaining compatibility).

> 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 would find it incredibly satisfying, in
> a devilish way, to release this thing and slap a "2.0" on it. It would
> underscore the project's stability while at the same time
> demonstrating that version numbers are completely arbitrary.

I'd be OK with it; in my previous life as a PHP guy I worked a lot
with Textpattern, which went through a multi-year development process
and then decided to call the result "version 4.0" ;)


--
"Bureaucrat Conrad, you are technically correct -- the best kind of correct."

jj

unread,
Nov 30, 2007, 2:18:08 AM11/30/07
to Django developers
As a user having based some key internal applications on 0.96, which
is solid enough, and not being likely to move to 2.0 in the near
future, I'd say yes, go ahead, call it 2.0

AND

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 0.96 that way?

JJ.

Max Battcher

unread,
Nov 30, 2007, 2:27:34 AM11/30/07
to django-d...@googlegroups.com
On Nov 30, 2007 2:18 AM, jj <jjmo...@gmail.com> 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 0.96 that way?

That might be a good idea... backport any remaining useful fixes to
0.96, maybe go ahead and do the newforms -> forms rename, and not much
more really needs to be done and call that 1.0 and everything else
becomes 2.0...

On the other hand I also see the humor in skipping directly from 0.96 to 2.0.

The way changes steadily get pushed to Trunk I'm wondering if Django
might not be better off using Ubuntu-style date-based versions,
anyway. (ie, the current Ubuntu release was official in October 2007
and thus is version 7.10) I think it would be even funnier to skip
from 0.96 to 8.01... and then follow that up with new versions each
quarter, if not each month...

--
--Max Battcher--
http://www.worldmaker.net/

Graham Dumpleton

unread,
Nov 30, 2007, 4:37:43 AM11/30/07
to Django developers
There is probably no ticket for it, but allowing a WSGI environment
variable be used in place of DJANGO_SETTINGS_MODULE environment
variable. The intent in doing this is to get away from dependence on
what is effectively a global variable. This would perhaps allow, or at
least be a step on the way to being able to effectively host multiple
Django site instances within the one Python interpreter. This would be
better than using distinct sub interpreters in mod_python or mod_wsgi
as only have to load common modules into memory once, thus cutting
down on memory bloat when hosting a lot of sites.

I think a lot of people who are hosting a lot of related sites on the
one system would appreciate this one.

Graham

David Reynolds

unread,
Nov 30, 2007, 6:41:19 AM11/30/07
to django-d...@googlegroups.com

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 would find it incredibly satisfying, in
> a devilish way, to release this thing and slap a "2.0" on it. It would
> underscore the project's stability while at the same time
> demonstrating that version numbers are completely arbitrary.

Worth it just for this reason alone IMO ;)

--
David Reynolds
da...@reynoldsfamily.org.uk


Deryck Hodge

unread,
Nov 30, 2007, 7:44:59 AM11/30/07
to django-d...@googlegroups.com
On Nov 30, 2007 12:33 AM, Adrian Holovaty <holo...@gmail.com> 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 changes between
releases. Granted those are dot releases, but the idea is the same.

Cheers,
deryck

Alex Myodov

unread,
Nov 30, 2007, 7:50:49 AM11/30/07
to Django developers
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 other test
mouses to try it and spot the major bugs, and deploy it after a couple
of bugfix releases".
(And by the way, "Django 2.0" definitely implies you have a lot of
Ajax and shiny buttons in it,... and something like Dojo is heavily
integrated).

If you want everyone consider it stable - name it "Django 1.5" or
something. "No service packs needed".

And if you want an incredible showoff and the mention in every IT-
related news magazine - name it "Django 1.6" and announce that every
new version is the next approximation to the Golden Ratio ( the second
release will be Django 1.62, the third will be Django 1.618 and so
on). Hope Knuth is not offended.


<small>PS: and no official SQL view support by the ORM in the Django
release yet planned?</small>

Adrian Holovaty:

Forest Bond

unread,
Nov 30, 2007, 8:33:42 AM11/30/07
to django-d...@googlegroups.com
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 files at all. Or was this resolved when I wasn't looking?

-Forest
--
Forest Bond
http://www.alittletooquiet.net

signature.asc

Patryk Zawadzki

unread,
Nov 30, 2007, 8:37:05 AM11/30/07
to django-d...@googlegroups.com
2007/11/30, Forest Bond <for...@alittletooquiet.net>:

> 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 files at all. Or was this resolved when I wasn't looking?

Start using lighttpd + fcgi instead of Apache ;)

--
Patryk Zawadzki
PLD Linux Distribution

Malcolm Tredinnick

unread,
Nov 30, 2007, 9:12:14 AM11/30/07
to django-d...@googlegroups.com

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 be moved to different relative mount points
> without changing .py files at all. Or was this resolved when I wasn't looking?

It's all the same issue. This is one of the things I'm going to review
and commit during the sprint.

Malcolm


Malcolm Tredinnick

unread,
Nov 30, 2007, 9:13:46 AM11/30/07
to django-d...@googlegroups.com

On Fri, 2007-11-30 at 02:27 -0500, Max Battcher wrote:
> On Nov 30, 2007 2:18 AM, jj <jjmo...@gmail.com> 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 0.96 that way?
>
> That might be a good idea... backport any remaining useful fixes to
> 0.96, maybe go ahead and do the newforms -> forms rename, and not much
> more really needs to be done and call that 1.0 and everything else
> becomes 2.0...

-1.

We're talking about doing *a* release here. Not 1.0 and then 2.0
immediately afterwards. Please don't create more work for us than
necessary.

Malcolm


Kenneth Gonsalves

unread,
Nov 30, 2007, 9:19:45 AM11/30/07
to django-d...@googlegroups.com

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 8.0

--

regards
kg
http://lawgon.livejournal.com
http://nrcfosshelpline.in/web/
Foss Conference for the common man: http://registration.fossconf.in/web/


Etienne Robillard

unread,
Nov 30, 2007, 9:35:50 AM11/30/07
to django-d...@googlegroups.com
On Nov 30, 2007 2:27 AM, Max Battcher <m...@worldmaker.net> wrote:

On Nov 30, 2007 2:18 AM, jj <jjmo...@gmail.com> 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 0.96 that way?

That might be a good idea...  backport any remaining useful fixes to
0.96, maybe go ahead and do the newforms -> forms rename, and not much
more really needs to be done and call that 1.0 and everything else
becomes 2.0...

I think it would be great if Django-1.0 (and subsequent releases) be backward-compatible with Django-0.96...

Regards and happy sprinting!
- Etienne

 

George Vilches

unread,
Nov 30, 2007, 9:40:36 AM11/30/07
to django-d...@googlegroups.com
Etienne Robillard wrote:
>
>
> On Nov 30, 2007 2:27 AM, Max Battcher <m...@worldmaker.net
> <mailto:m...@worldmaker.net>> wrote:
>
>
> On Nov 30, 2007 2:18 AM, jj <jjmo...@gmail.com
> <mailto:jjmo...@gmail.com>> 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 0.96 that way?
>
> That might be a good idea... backport any remaining useful fixes to
> 0.96, maybe go ahead and do the newforms -> forms rename, and not much
> more really needs to be done and call that 1.0 and everything else
> becomes 2.0...
>
>
> I think it would be great if Django-1.0 (and subsequent releases) be
> backward-compatible with Django-0.96...

I think it's fair to say that with the changes already in the trunk,
this is a lost cause.

gav

Forest Bond

unread,
Nov 30, 2007, 9:56:47 AM11/30/07
to django-d...@googlegroups.com
Hi,

I was hoping you'd say that. Thanks!

signature.asc

Luke Plant

unread,
Nov 30, 2007, 10:13:39 AM11/30/07
to django-d...@googlegroups.com
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_APPS an instance, and each app an instance
> * #5361 -- File storage refactoring
> * #285 -- WSGI SCRIPT_NAME and PATH_INFO stuff
>
> What am I forgetting?

Middleware ordering really needs looking at:
http://code.djangoproject.com/ticket/730
http://code.djangoproject.com/ticket/749

A small backwards incompatible fix here, I think should be looked at:
http://code.djangoproject.com/ticket/4619

Luke


--
"Mediocrity: It takes a lot less time, and most people don't realise
until it's too late." (despair.com)

Luke Plant || http://lukeplant.me.uk/

Barry Pederson

unread,
Nov 30, 2007, 10:16:36 AM11/30/07
to django-d...@googlegroups.com
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 gone into that over the last 15 months - it'd be a shame to see
it not make the cut.

Barry

Jacob Kaplan-Moss

unread,
Nov 30, 2007, 10:43:46 AM11/30/07
to django-d...@googlegroups.com
On 11/30/07, Etienne Robillard <robillar...@gmail.com> 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 changes so far
here: http://code.djangoproject.com/wiki/BackwardsIncompatibleChanges.
Notice that the vast majority of them are relatively minor.

Jacob

Patryk Zawadzki

unread,
Nov 30, 2007, 10:46:11 AM11/30/07
to django-d...@googlegroups.com
2007/11/30, Adrian Holovaty <holo...@gmail.com>:

> 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 instance
> * #5361 -- File storage refactoring
> * #285 -- WSGI SCRIPT_NAME and PATH_INFO stuff
>
> What am I forgetting?

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 other forms

Both are taken care of in http://code.djangoproject.com/ticket/5986

Malcolm Tredinnick

unread,
Nov 30, 2007, 10:50:28 AM11/30/07
to django-d...@googlegroups.com

On Fri, 2007-11-30 at 16:46 +0100, Patryk Zawadzki wrote:
> 2007/11/30, Adrian Holovaty <holo...@gmail.com>:
> > 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 instance
> > * #5361 -- File storage refactoring
> > * #285 -- WSGI SCRIPT_NAME and PATH_INFO stuff
> >
> > What am I forgetting?
>
> 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 other forms

This is the sort of thing where it wouldn't be a complete loss if it
didn't make it into 1.0, since form construction helpers are just that:
helpers. They don't depend on core changes and don't require core
changes to support them. Hence, somebody can just write something
outside of core that meets their purposes.

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.

Let's keep a focus on things that require core changes (and hence can't
be done externally if not in the release).

Malcolm


Patryk Zawadzki

unread,
Nov 30, 2007, 11:16:35 AM11/30/07
to django-d...@googlegroups.com
2007/11/30, Malcolm Tredinnick <mal...@pointy-stick.com>:

You seem to overlook the part about defining field order for forms
extending other forms. That's in no way related to form construction
helpers (other than being useful for them as well).

Karen Tracey

unread,
Nov 30, 2007, 11:24:46 AM11/30/07
to django-d...@googlegroups.com
On 11/30/07, Malcolm Tredinnick <mal...@pointy-stick.com> 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've gotten the impression that these form_for_* changes would be very helpful in getting some of the newforms-admin loose ends tied up (edit-inline in particular, I believe).  Thus since the basic idea has gotten a positive response and there is already an initial implementation, I wouldn't be surprised to see the form_for_* changes become a pre-req to getting newforms-admin finished, which would turn them into a show-stopper for 1.0.  This is just my impression, though, Joseph might very well have a different view.

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.

Karen

Bryan L. Fordham

unread,
Nov 30, 2007, 12:49:16 PM11/30/07
to django-d...@googlegroups.com

>
> 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 well. Seriously, how many of us have been running
these pre-1.0 versions in production with no real problems?

marcin.k...@gmail.com

unread,
Nov 30, 2007, 12:51:25 PM11/30/07
to Django developers
On Nov 30, 7:33 am, "Adrian Holovaty" <holov...@gmail.com> 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 that large :)

The list looks good. My pet peeves are trivial bugs that prevent
django-multilingual from working with clean Django checkout, but one
of them (#3275) was recently fixed in qs-rf and the other (#3434),
while still present in newforms-admin, is not as serious there as in
trunk (I did not test it yet, but it looks like you will get
javascript error instead of an exception in Python code).

On the other hand, merging qs-rf will break the multilingual machinery
anyway, so I just hope to have enough time between the qs-rf merge and
the release deadline to make django-multilingual compatible again, as
it might shake out some hidden Django bugs again. But that is most
probably obvious to you: the list includes at least two branches with
quite low-level changes, so we need to plan a significant amount of
testing and debugging time _after_ those are merged or we will get a
traditionally buggy .0 release.

-mk

Derek Anderson

unread,
Nov 30, 2007, 12:56:10 PM11/30/07
to django-d...@googlegroups.com
what, no schema evolution? =p

(ducks for cover behind fire-retardant suit ;)

> 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 instance
> * #5361 -- File storage refactoring
> * #285 -- WSGI SCRIPT_NAME and PATH_INFO stuff
>
> What am I forgetting?
>

> And, finally, a bit of a controversial statement, but...
>
> I think we ought to call the release 2.0.
>

> Jacob and I have talked in the past about how we should've called
> magic-removal version 1.0. (This ended up being 0.95.) For all intents
> and purposes, it *was* 1.0 in spirit -- it was the first major
> refactoring of several parts of the framework, and it was a point for
> me personally where I started to feel like an acceptable number of the
> legacy warts from pre-open-sourcing had been removed.
>
> So, that's one reason: philosophically, conceptually, in our minds, in
> our hearts, we're really dealing with a 2.0 product. We know Django
> rocks (and is rock-solid), and we should give it an appropriate
> number.
>
> 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 would find it incredibly satisfying, in
> a devilish way, to release this thing and slap a "2.0" on it. It would
> underscore the project's stability while at the same time
> demonstrating that version numbers are completely arbitrary.
>
> It'd be like Google's IPO price, which was set to the mathematical
> constant "e" -- a "we're not playing by your rules" message to Wall
> Street.
>
> Something to ponder!
>
> Adrian
>


--
looking to buy or sell anything?

try: http://allurstuff.com

it's a classified ads service that
shows on a map where the seller is
(think craigslist + google maps)

plus it's 100% free :)

Adrian Holovaty

unread,
Nov 30, 2007, 1:44:31 PM11/30/07
to django-d...@googlegroups.com
On Nov 30, 2007 11:56 AM, Derek Anderson <pub...@kered.org> 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."

Bob T.

unread,
Nov 30, 2007, 3:45:41 PM11/30/07
to Django developers
> 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 a candidate to me.

> I think we ought to call the release 2.0.

That would be fun, though the Ubuntu convention would certainly
sidestep cries of "foul!".

Bob

Derek Anderson

unread,
Nov 30, 2007, 3:55:41 PM11/30/07
to django-d...@googlegroups.com
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 <pub...@kered.org> 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
>


--

David Cramer

unread,
Nov 30, 2007, 4:00:22 PM11/30/07
to Django developers
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" <bford...@socialistsushi.com>
wrote:

Graham Dumpleton

unread,
Nov 30, 2007, 6:52:31 PM11/30/07
to Django developers
Or for something easier to setup than fastcgi and possibly more
reliable, stay with Apache but use mod_wsgi instead. ;-)

Graham

Simon Willison

unread,
Nov 30, 2007, 8:54:43 PM11/30/07
to Django developers
On Nov 30, 6:33 am, "Adrian Holovaty" <holov...@gmail.com> 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 build things
without worrying that backwards compatibility will be broken". That's
what we've been telling people for the past couple of years, and as a
result I feel it would be odd to use 2.0 to make the statement that
version numbers are meaningless after all.

I think that the release of v1.0 combined with the publication of the
Django Book will result in a serious uptick in interest in the project
(and that's not saying that there isn't plenty of interest already). I
wouldn't want to see some of that interest diverted by confusion over
version numbers.

Cheers,

Simon

Mark Green

unread,
Nov 30, 2007, 9:16:06 PM11/30/07
to django-d...@googlegroups.com
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
> let's release it.

Great. Just great! :-)
A small suggestion (and it's probably obvious): It would be awesome
if, once the features are determined, someone could take the time and
make a trac milestone out of the tickets that belong to this goal.

The "roadmap"-feature of trac would then give us a nice progress-bar
and could help to draw more focus onto the relevant tickets.


-mark


Gary Wilson

unread,
Nov 30, 2007, 9:27:07 PM11/30/07
to django-d...@googlegroups.com
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 instance
> * #5361 -- File storage refactoring
> * #285 -- WSGI SCRIPT_NAME and PATH_INFO stuff
>
> What am I forgetting?

newforms in generic views and comments too. This isn't being taken care of in
newforms admin is it?

We also have the features page made before the last sprint:
http://code.djangoproject.com/wiki/VersionOneFeatures

On a related note, the maxlength argument is currently issuing a
PendingDeprecationWarning. It was talked that we would change to
DeprecationWarning before the next release, but I think it should die before
<what do we call it>.0.

Should we change to DeprecationWarning now and remove it before the release or
just axe it all now?

> And, finally, a bit of a controversial statement, but...
>

> I think we ought to call the release 2.0.

"The birth of Django"
1.910

Gary

Simon Willison

unread,
Nov 30, 2007, 10:50:08 PM11/30/07
to Django developers
On Nov 30, 6:33 am, "Adrian Holovaty" <holov...@gmail.com> 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
application is a callable that takes a request object and returns a
response - and in fact an entire Django deployment can be boiled down
to that. This has a number of advantages:

1. At the moment, middleware applies globally to the whole site. This
is bad: often you'll want a piece of middleware to apply just to one
or two of the applications that a site is composed of. If views and
applications (and projects) had a unified API then middleware could be
redefined to apply at any level of the stack. View middleware wouldn't
make so much sense here, but Request and Response middleware would.
2. We always said that the regular expression based URL dispatching
should be replaceable by other methods if required. Having url
dispatch as just another view function would give us that for free.
I'd love to have a simpler alternative to the regexp method that is
more friendly for developers who haven't fully grokked regular
expression syntax yet.

If there's enough interest in the DEP idea I'd be happy to write up
this proposal more formally.

Cheers,

Simon

Brian Rosner

unread,
Dec 1, 2007, 1:38:57 AM12/1/07
to Django developers


On Nov 30, 7:27 pm, Gary Wilson <gary.wil...@gmail.com> 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__ hacking
> > * #3591 -- Make INSTALLED_APPS an instance, and each app an instance
> > * #5361 -- File storage refactoring
> > * #285 -- WSGI SCRIPT_NAME and PATH_INFO stuff
>
> > What am I forgetting?
>
> newforms in generic views and comments too. This isn't being taken care of in
> newforms admin is it?

No this isn't being done in newforms-admin. I would post the ticket
number, but I have created a patch with docs and tests for converting
the generic views over to newforms. Be great if it can get some more
eyeballs and maybe get merged in tomorrow.

Brian Rosner

unread,
Dec 1, 2007, 1:42:02 AM12/1/07
to Django developers


On Nov 30, 11:38 pm, Brian Rosner <bros...@gmail.com> wrote:
> On Nov 30, 7:27 pm, Gary Wilson <gary.wil...@gmail.com> 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__ hacking
> > > * #3591 -- Make INSTALLED_APPS an instance, and each app an instance
> > > * #5361 -- File storage refactoring
> > > * #285 -- WSGI SCRIPT_NAME and PATH_INFO stuff
>
> > > What am I forgetting?
>
> > newforms in generic views and comments too. This isn't being taken care of in
> > newforms admin is it?
>
> No this isn't being done in newforms-admin. I would post the ticket
> number, but I have created a patch with docs and tests for converting
> the generic views over to newforms. Be great if it can get some more
> eyeballs and maybe get merged in tomorrow.

Er, I meant to say that I can't post the ticket since the site is down
for maintenance and that I have created a patch ;)

SmileyChris

unread,
Dec 1, 2007, 4:05:56 AM12/1/07
to Django developers
On Dec 1, 5:24 am, "Karen Tracey" <kmtra...@gmail.com> wrote:
> 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.

+1

While 2.0 sounds like we'd be "making a statement", this sounds more
sensible.

Eugene Lazutkin

unread,
Dec 1, 2007, 2:46:17 PM12/1/07
to django-d...@googlegroups.com
+1. I agree with Simon's reasoning.

oggie rob

unread,
Dec 1, 2007, 8:26:02 PM12/1/07
to Django developers


On Nov 29, 10:33 pm, "Adrian Holovaty" <holov...@gmail.com> 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 instance
> * #5361 -- File storage refactoring
> * #285 -- WSGI SCRIPT_NAME and PATH_INFO stuff
>
> What am I forgetting?

Good choices, Adrian. I talked about this with you guys last sprint
(sorry by the way for missing this one) and I think these hit the
spot. Various branches may have to scramble a little to get up to date
but I think that will give them a better point of reference than "the
last time we branched". Also these are clearly backwards incompatible
- good to get those out of the way and make the upgrade path easier
for those starting with the next major version, and add the less-
incompatible changes later.

>
> And, finally, a bit of a controversial statement, but...
>
> I think we ought to call the release 2.0.
>

Well Rails is about to release 2.0... oops, did I say that out loud?!

Great stuff!
-rob

Gábor Farkas

unread,
Dec 2, 2007, 12:27:29 PM12/2/07
to django-d...@googlegroups.com
Simon Willison wrote:
> I'd love to have a simpler alternative to the regexp method that is
> more friendly for developers who haven't fully grokked regular
> expression syntax yet.

while i agree that simplifying things is always a good idea, i think
that "developers who haven't fully grokked regular expression syntax
yet" should learn them as soon as possible :-)

gabor

David Larlet

unread,
Dec 2, 2007, 1:31:36 PM12/2/07
to django-d...@googlegroups.com

Le 30 nov. 07 à 07:33, Adrian Holovaty a écrit :

>
> Let's get a definitive list of features we want in Django 1.0, and
> let's release it.

Just great.


>
> 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 instance
> * #5361 -- File storage refactoring
> * #285 -- WSGI SCRIPT_NAME and PATH_INFO stuff
>
> What am I forgetting?

Maybe use request.DATA instead of POST as discussed in #5682? It's
backward compatible and not a Big Stuff but can require a lot of
changes if it becomes the right way to do®.

David

Thomas Güttler

unread,
Dec 3, 2007, 3:00:53 AM12/3/07
to django-d...@googlegroups.com
> 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 admin or as own application.

Thomas Güttler

--
Thomas Güttler, http://www.tbz-pariv.de/
Bernsdorfer Str. 210-212, 09126 Chemnitz, Tel.: 0371/5347-917
TBZ-PARIV GmbH Geschäftsführer: Dr. Reiner Wohlgemuth
Sitz der Gesellschaft: Chemnitz Registergericht: Chemnitz HRB 8543

James Bennett

unread,
Dec 3, 2007, 3:15:42 AM12/3/07
to django-d...@googlegroups.com
On 11/30/07, Simon Willison <si...@simonwillison.net> 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 that takes a request object and returns a
> response - and in fact an entire Django deployment can be boiled down
> to that. This has a number of advantages:

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.

I'd much prefer to have our WSGI issues straightened out so that
Django can be a first-class WSGI citizen, and leave dispatch and
request/response within the framework as they are.

--
"Bureaucrat Conrad, you are technically correct -- the best kind of correct."

Russell Keith-Magee

unread,
Dec 3, 2007, 6:19:06 AM12/3/07
to django-d...@googlegroups.com
On Nov 30, 2007 3:33 PM, Adrian Holovaty <holo...@gmail.com> 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. We set a deadline.

This is the only one that worries me... as much as I would like to
make the v1.0 hawks go away by saying "no later than X", I think the
better approach is to set a conservative set of goal features, rather
than a chronological deadline. Hypothetical extreme case - we set up a
feature list, and set a deadline for 1 July 2008. Then all the core
developers get distracted on non-Django work, 1 July comes around, and
we still haven't merged newforms-admin. At this point, I don't care
what the date is - a v1.0 without newforms-admin would be a waste of
time.

> What am I forgetting?

That looks like a pretty comprehensive list to me. I can only think of
2 items that aren't present:

1) Model inheritance.
2) #2070 - streaming uploads.

My reasoning for (1) is much the same as James. From a purely
technical perspective, inheritance/subclassing/abstract base classes
could probably be added post 1.0 without any backwards incompatiblilty
issues. However, the OneToOneField has been marked as 'don't use this,
there's something better coming' for almost as long as I can remember;
since the point of the v1 release is to establish the core APIs that
we are happy with, this is probably something we should resolve.

As for #2070 - it has a lot of followers (currently 32 names on the CC list);
I haven't had a look at this patch for a while, so I don't remember
the extent to which it could be integrated post v1. However, it's one
of those tickets that (a) has a lot of interest and (b) has an
apparently working implementation, so IMHO its worth the effort to
include it.

> And, finally, a bit of a controversial statement, but...
>
> I think we ought to call the release 2.0.

While I can appreciate the 'stick it to them' sentiment, I don't like
the way that this conflicts with the message that we have been sending
for quite some time - that v1.0 is when we will stabilize our APIs. I
for one don't want to have to answer the deluge of "Huh? When was 1.0
released?" questions from people that don't get the joke.

Russ %-)

Nick

unread,
Dec 3, 2007, 7:37:20 AM12/3/07
to Django developers

> 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

Panos

unread,
Dec 3, 2007, 10:52:19 AM12/3/07
to Django developers
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.

Jacob Kaplan-Moss

unread,
Dec 3, 2007, 11:36:46 AM12/3/07
to django-d...@googlegroups.com
On 12/3/07, Thomas Güttler <h...@tbz-pariv.de> 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
different.

> And make the documentation (incl. API doc) available trough the development
> server. Either in admin or as own application.

While this is a good idea (and certainly on my list), it's very much
*not* something that should block releasing 1.0. Adding documentation
in 1.1 or 2.0 or 7.56 doesn't cause any backwards incompatibilities.

Folks, we need to think very carefully about the features we put on
the 1.0 list. The goal of 1.0 is forward API stability, not
feature-completion. Getting a release out in a timely manner means
that we'll all need to sacrifice our personal wishlist to a more
pragmatic -- and smaller -- feature set.

Jacob

alex....@gmail.com

unread,
Dec 3, 2007, 1:37:03 PM12/3/07
to Django developers
For some unknown reason I am in love with this suggestion.

Simon Willison

unread,
Dec 3, 2007, 1:59:49 PM12/3/07
to django-d...@googlegroups.com

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.

Because WSGI is a horrible API for developers. I'd love to see Django
request/response become a simple developer-friendly wrapper around
WSGI, provided we gained rather than lost flexibility and power in
the process.

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. Or, imagine taking a WSGI
application, wrapping it up as a Django view and deploying it
straight in to a Django URL configuration.

Cheers,

Simon

David Cramer

unread,
Dec 3, 2007, 2:03:46 PM12/3/07
to Django developers
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 how they can make a timely 1.0 release.

On Dec 3, 3:19 am, "Russell Keith-Magee" <freakboy3...@gmail.com>
wrote:

Malcolm Tredinnick

unread,
Dec 3, 2007, 2:17:11 PM12/3/07
to django-d...@googlegroups.com

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 in the air. If there are features that are unsure of, I don't
> see how they can make a timely 1.0 release.

Then you haven't searched the archives closely enough. Since this is the
second time today this has come up, I'll post the summary of what's
going to happen in a couple of days, after I'm back in Australia and
recovered from the travel. It's been discussed ad infinitum with some
reasonable agreement in the past.

Malcolm

James Bennett

unread,
Dec 3, 2007, 2:26:33 PM12/3/07
to django-d...@googlegroups.com
On 12/3/07, Simon Willison <si...@simonwillison.net> 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. Or, imagine taking a WSGI
> application, wrapping it up as a Django view and deploying it
> straight in to a Django URL configuration.

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.

Marty Alchin

unread,
Dec 3, 2007, 2:34:13 PM12/3/07
to django-d...@googlegroups.com
On Dec 3, 2007 2:26 PM, James Bennett <ubern...@gmail.com> 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 about WSGI, but Malcolm and I have had some
discussion about some minor changes to URL resolution that would make
something like this a wee bit nicer. I don't have a link to it
offhand, but I had a need for something a little different than normal
when I was working out a Netvibes widget app, and it sounds like there
might be some overlap. Probably a bit off-topic for this thread,
though.

-Gul

Adrian Holovaty

unread,
Dec 3, 2007, 2:51:30 PM12/3/07
to django-d...@googlegroups.com

A vehement "no, no, no." Nicknames like this are way too confusing,
and they offer no value other than cutesiness.

Adrian

--
Adrian Holovaty
holovaty.com | djangoproject.com

David Cramer

unread,
Dec 3, 2007, 3:17:56 PM12/3/07
to Django developers
I'm also -1 on the strange names -- especially something like "Paris
1945" :P

On Dec 3, 11:51 am, "Adrian Holovaty" <holov...@gmail.com> wrote:

jj

unread,
Dec 4, 2007, 12:34:58 AM12/4/07
to Django developers
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 generally takes longer. It wouldn't be fair to you
or the community if people moved elsewhere in the meantime.

Don't get me wrong. I'm not criticizing the work that has been done or
is currently being done. 0.96 is a tremendous release already and I
know you're all hard work on even stronger stuff. It's just about
saying, yes, there's more to come (2.0 or 1.5), but 1.0 (i.e. 0.96) is
good enough already.

Or maybe 2.0 is just so close already? (If so I'd say don't add more,
just complete what's in the trunk (and key) and ship; then make an
another release with the new stuff that is being discussed in this
thread.)

JJ.


On Nov 30, 3:13 pm, Malcolm Tredinnick <malc...@pointy-stick.com>
wrote:
> On Fri, 2007-11-30 at 02:27 -0500, Max Battcher wrote:
> > On Nov 30, 2007 2:18 AM, jj <jjmor...@gmail.com> wrote:
> > > move 0.96 to1.0status. 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 0.96 that way?
>
> > That might be a good idea... backport any remaining useful fixes to
> > 0.96, maybe go ahead and do the newforms -> forms rename, and not much
> > more really needs to be done and call that1.0and everything else
> > becomes 2.0...
>
> -1.
>
> We're talking about doing *a* release here. Not1.0and then 2.0
> immediately afterwards. Please don't create more work for us than
> necessary.
>
> Malcolm

bobj

unread,
Dec 4, 2007, 8:26:16 AM12/4/07
to Django developers, Simon Willison
Simon - These are GREAT!!! Ideas. The regular expression based URL
dispatching replacement has been something I personally have been
thinking about for some time. I would be interested in helping with
this If you put together a proposal. One URL implementation worth
considering is "Routes" ( http://routes.groovie.org ). I have used
Routes for web applications and I think it is easy to grok. Have you
taken a look at Routes?

BobJ

Simon Willison

unread,
Dec 4, 2007, 3:54:11 PM12/4/07
to bobj, Django developers

On 4 Dec 2007, at 13:26, bobj wrote:

> Simon - These are GREAT!!! Ideas. The regular expression based URL
> dispatching replacement has been something I personally have been
> thinking about for some time. I would be interested in helping with
> this If you put together a proposal. One URL implementation worth
> considering is "Routes" ( http://routes.groovie.org ). I have used
> Routes for web applications and I think it is easy to grok. Have you
> taken a look at Routes?

I like Routes in principle, but the way it has the concept of a
"controller" baked in to it didn't sit very well with me. I can't
imagine it would be hard to use it without controllers though.

I'm generally pretty happy with regular expressions, but I watched
Scott Guthrie's presentation on the ASP.NET MVC framework a few weeks
ago (it's really interesting, they've taken a bunch of ideas from
Django and it gets name-checked in the presentation) and one of the
things he noted is that there are developers (especially in the
Microsoft ecosystem) who never really got comfortable with regexps. I
don't want those people to be turned away from Django on the first
page of the tutorial. He also described the ASP.NET MVC syntax for
URLs, which looks like this:

search/[query]
product/[id]

http://weblogs.asp.net/scottgu/archive/2007/12/03/asp-net-mvc-
framework-part-2-url-routing.aspx

While I personally prefer the power of regexps, I can see how the
above would make it much easier for developers just beginning to get
their feet wet with Django. We can always enlighten them with the
power of regular expressions once they're hooked. If URL handling is
interchangeable we can have the best of both worlds. Incidentally,
allowing URL logic to be swapped out was an initial design goal back
when we put the URL stuff together - we were worried about
performance, but when we benchmarked it turned out that Python can
run through a list of a hundred or so regular expressions in less
than 0.01 seconds.

Cheers,

Simon

Ned Batchelder

unread,
Dec 4, 2007, 10:09:46 PM12/4/07
to django-d...@googlegroups.com, bobj
I would like to see a replacement for the regex scheme as well, but not because I am uncomfortable with regexes.  I think the typical regex for a URL is noisy: it's hard to see the intent of the expression.  Most URL regexes follow some very well-defined patterns, and we don't have a way to express them other than to "compile them down" to regexes.  Sometimes you need the full power, but usually, your URL consists of fixed parts and variable parts separated by slashes.  The variable parts are often numbers, or slugs, and need to be given names.  Being able to express that succinctly would solve most people's URL matching.

I don't have a suggestion for a replacement, and I don't think it needs to be on the 1.0 list (since it can be added without breaking backward compatibility), but I think it would be a big plus.

--Ned.
http://nedbatchelder.com/blog
-- 
Ned Batchelder, http://nedbatchelder.com

James Bennett

unread,
Dec 4, 2007, 10:31:43 PM12/4/07