Django 1.0 features -- the definitive list
Adrian Holovaty
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
> 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
> 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
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
> 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
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
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
> 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
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
> * #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
Patryk Zawadzki
> 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
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
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
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
That might be a good idea... backport any remaining useful fixes to
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?
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
> > 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
Luke Plant
> 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
>
> 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
> 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
> 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
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
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
[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
>
> 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.
these pre-1.0 versions in production with no real problems?
marcin.k...@gmail.com
>
> I think we ought to call the release 2.0.
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
(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?
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
> 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.
> let's release it.
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.
sidestep cries of "foul!".
Bob
Derek Anderson
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
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
reliable, stay with Apache but use mod_wsgi instead. ;-)
Graham
Simon Willison
> I think we ought to call the release 2.0.
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
> (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 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
> 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
>
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
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
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?
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
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.
for maintenance and that I have created a patch ;)
SmileyChris
> 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.
While 2.0 sounds like we'd be "making a statement", this sounds more
sensible.
Eugene Lazutkin
oggie rob
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?
(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...
>
>
Great stuff!
-rob
Gábor Farkas
> 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
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
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
> 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
>
> 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
> And, finally, a bit of a controversial statement, but...
>
> I think we ought to call the release 2.0.
>
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
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
> 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
Simon Willison
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
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
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
> 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
> 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
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
1945" :P
On Dec 3, 11:51 am, "Adrian Holovaty" <holov...@gmail.com> wrote:
jj
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
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
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
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
> 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.
While I actually like the power and flexibility of regex-based
dispatch, I wouldn't mind seeing something like Joe Gregorio's URI
Templates[1] as an option. That would offer a nice balance between
power and conceptual simplicity, and once it (hopefully) becomes a
published RFC it'd be nice to support the standard.
[1] http://bitworking.org/news/URI_Templates
Waylan Limberg
>
> On 12/4/07, Ned Batchelder <n...@nedbatchelder.com> wrote:
> > 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.
>
> While I actually like the power and flexibility of regex-based
> dispatch, I wouldn't mind seeing something like Joe Gregorio's URI
> Templates[1] as an option. That would offer a nice balance between
> power and conceptual simplicity, and once it (hopefully) becomes a
> published RFC it'd be nice to support the standard.
>
> [1] http://bitworking.org/news/URI_Templates
>
Selector[1], a raw WSGI middleware for url dispatching, uses something
almost exactly like this. Although, there are a few things we
obviously wouldn't want, it provides a decent starting point. I'd
suggest ignoring all the "updates" and scrolling down to the basic
tutorial at the bottom of the page for the general idea.
[1]: http://lukearno.com/projects/selector/
--
----
Waylan Limberg
way...@gmail.com
Adrian Holovaty
> Selector[1], a raw WSGI middleware for url dispatching, uses something
> almost exactly like this. Although, there are a few things we
> obviously wouldn't want, it provides a decent starting point. I'd
> suggest ignoring all the "updates" and scrolling down to the basic
> tutorial at the bottom of the page for the general idea.
This is getting off-topic, but I've had an implementation of
Django-URLconfs-as-a-WSGI-application lying around in my home
directory for probably 6 months. I designed it to honor the
routing_args specification
(http://wsgi.org/wsgi/Specifications/routing_args) so that people
could drop in Selector and Routes if they so desired. I should clean
it up and post it to the list...
Jannis Leidel
Am 30.11.2007 um 07:33 schrieb Adrian Holovaty:
> * 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?
Please add support for loading Django apps from PythonEggs in
preparation of the hot club of france.
Ticket #6080 includes a patch with documentation and is backwards-
compatible.
Best,
Jannis
Antonio Cangiano
> I think we ought to call the release 2.0.
How about releasing 1.0 now, 1.2 in a month or so, and then 2.0 when
all the features listed above will be implemented?
Cheers,
Antonio
--
Antonio Cangiano
http://antoniocangiano.com
http://math-blog.com
Malcolm Tredinnick
On Sat, 2007-12-08 at 01:03 -0800, Antonio Cangiano wrote:
> On Nov 30, 1:33 am, "Adrian Holovaty" <holov...@gmail.com> wrote:
> > I think we ought to call the release 2.0.
>
> Adrian, marketing matters. :)
> How about releasing 1.0 now, 1.2 in a month or so, and then 2.0 when
> all the features listed above will be implemented?
Because, as you say, marketing matters. Releasing code that forces
people to do reasonably fiddly upgrades multiple times in the course of
a couple of months is unreasonable. Given that we're only talking about
a few months, at worst, in any case, rushing to release something just
so that we can say we've released something, no matter how unready, is
unprofessional.
Malcolm
--
Why be difficult when, with a little bit of effort, you could be
impossible.
http://www.pointy-stick.com/blog/
Kevin Menard
On Nov 30, 2007, at 8:54 PM, Simon Willison wrote:
>
> 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.
Apologies for chiming in late. I agree with Simon's sentiments.
Moreover, if the point is that version numbers mean nothing, which is
fine, then what mechanism is used to convey API compatibility between
releases?
Shifting to a more personal stance, I never cared much for the term
"Web 2.0". It seems too gimmicky. That's largely the impression I
get with a Django 2.0 without a prior Django 1.0.
--
Kevin
Simon Willison
On 8 Dec 2007, at 20:14, Kevin Menard wrote:
> Shifting to a more personal stance, I never cared much for the term
> "Web 2.0". It seems too gimmicky. That's largely the impression I
> get with a Django 2.0 without a prior Django 1.0.
The other problem with Django 2.0 is that Rails just released their
2.0 - which means that a Django release will look like an attempt to
catch up on the version number - obviously not the case. If we wanted
to make a statement about Django's maturity that statement could be
equally well served by jumping straight to 1.5. This would also
maintain the meaningfulness of version 1.0 - once past 1.0, backwards
compatibility with the APIs is guaranteed.
Bryan Veloso
This is a completely personal and probably selfish desire, but I'd
love to see the comments system rewrite in there. It's been on that
informal wiki-list ever since I started using Django.
Rob Hudson
release? By marketing, I mean, screencasts, t-shirts, coffee mugs.
Possibly a not-for-profit entity to pipe whatever proceeds or
donations through to help support Django coding, or have paid
bounties, etc.
IIRC, some of these things have always been shelved for the 1.0 release.
-Rob