Upcoming Django release, and the future
James Bennett
As we sit here in warm, sunny Dallas, meditating on how next year's
PyCon will be in cold, cloudy Chicago, we're also getting ready to
push out a new release of Django, and with that there are some things
you all need to know, and as your friendly neighborhood release
manager it's my job to tell you :)
First, the immediate future: the goal of the first part of our PyCon
sprint this year is to get Django 0.96 rolled and released. There's a
lot of cool new stuff that's landed in trunk since 0.95 (like the
testing framework and the newforms library), and we want to get it out
in an official release.
If there's a bug that's been annoying the heck out of you and you want
it fixed before the release, this would be the time to speak up about
it. We have a fairly high concentration of Django developers all in
one place with nothing to do but code, so hopefully we'll be able to
hit a lot of stuff and get a release out very quickly (we'd like to
release 0.96 in the next day or two).
After 0.96, though, there will be some major, backwards-incompatible
changes; several things, like the admin refactoring Jacob announced
last night, will require changes that just can't be
backwards-compatible, and will require a lot of activity on trunk for
a while. In that light, Django 0.96 is important not just for getting
all the cool features we've developed on trunk since 0.95, but also
for being a relatively easy upgrade for users of 0.95 and a stable
version to run with while we do a lot of work on trunk to get some
things into their "ready for 1.0" state.
It's not clear right now how long it'll be between 0.96 and the next
release. In the meantime, 0.96 will serve as a pleasant mix of
compatibility and new features; a couple of things have changed (like
the location of the admin documentation views), but on the whole it
should be an easy upgrade for anyone who's already at 0.95.
If you've got any questions about all of this, feel free to reply and
I'll do my best to answer them or delegate to someone who can. And if
you've got some free time this week and want to help us kill bugs in
the run up to 0.96, let us know and we'll be happy to show you how you
can help.
--
"Bureaucrat Conrad, you are technically correct -- the best kind of correct."
Michael Radziej
James Bennett wrote:
> If there's a bug that's been annoying the heck out of you and you want
> it fixed before the release, this would be the time to speak up about
> it. We have a fairly high concentration of Django developers all in
> one place with nothing to do but code, so hopefully we'll be able to
> hit a lot of stuff and get a release out very quickly (we'd like to
> release 0.96 in the next day or two).
One thing comes to my mind, supporting non-ASCII characters in newforms:
http://code.djangoproject.com/wiki/FeatureGrouping#Characterencodingissues
(and, please, sprinkle the newforms tests with a few of those "funky
characters" ;-)
Michael
Brian Harring
> If there's a bug that's been annoying the heck out of you and you want
> it fixed before the release, this would be the time to speak up about
> it.
http://code.djangoproject.com/ticket/3440 , Models.__init__
refactoring.
Fair amount of models instantiation is from data pulled from the
backend, meaning it's passed in via positional args- the current
__init__ however is written more for instantiation via passing args in
through kwargs.
Due to this, for instantiating a model derivative for a record (fairly
common case) a lot of extra work is done that isn't needed- very
least, fair slowdown due to exception throwing/catching.
Patch in that ticket reorganizes the processing so that the same
behaviour is preserved, but processing starts with positional args
first- 33% reduction in runtime via the reordering.
If at all possible, I'd like to see that patch integrated for 0.96,
since behaviour is the same but it provides a rather nice boost for
decent sized queryset operations.
Thanks,
~harring
Rubic
year's PyCon, it would be nice to have integrated
testing (fixtures, ticket #2333) brought to resolution.
It was great to briefly meet everyone over the past
few days in Dallas.
--
Jeff Bauer
Rubicon, Inc.
Jacob Kaplan-Moss
> One thing comes to my mind, supporting non-ASCII characters in newforms:
Since newforms will still be "new" in 0.96, I'm could take or leave
these before it. I'll try to get to 'em, though.
> http://code.djangoproject.com/wiki/FeatureGrouping#Characterencodingissues
>
> (and, please, sprinkle the newforms tests with a few of those "funky
> characters" ;-)
Wanna write some of those tests? I'd be in your debt forever...
Jacob
Jacob Kaplan-Moss
> http://code.djangoproject.com/ticket/3440 , Models.__init__
> refactoring.
#3440 is fixed and has to do with DateQuerySet; did you mean #3438?
Jacob
Jacob Kaplan-Moss
> In keeping with the overall theme of testing at this
> year's PyCon, it would be nice to have integrated
> testing (fixtures, ticket #2333) brought to resolution.
I really, really, *really* agree, and I'm going to look at seeing if I
can channel Russ and finish it off, but I doubt it -- it's Russ' baby.
Hopefully he's got some time to finish this up soon, but it can go in
after 0.96 without too much trouble. If the next release seems to take
too long, we could always do a 0.96.1 at some point.
Jacob
Russell Keith-Magee
>
> On 2/25/07, Rubic <rub...@gmail.com> wrote:
> > In keeping with the overall theme of testing at this
> > year's PyCon, it would be nice to have integrated
> > testing (fixtures, ticket #2333) brought to resolution.
>
> I really, really, *really* agree, and I'm going to look at seeing if I
> can channel Russ and finish it off, but I doubt it -- it's Russ' baby.
AFAIK, it is finished, just waiting for Adrian's ok. Is there
something missing that I'm not aware of?
Yours,
Russ Magee %-)
Jacob Kaplan-Moss
> AFAIK, it is finished, just waiting for Adrian's ok. Is there
> something missing that I'm not aware of?
Oh, I thought there was something missing *I* wasn't aware of :)
Please go ahead and check it in! I'll focus on writing docs (and maybe
a YAML serializer), and I'll look into earlier versions of Postgres,
too.
W00t, I'm so excited!
Jacob
Russell Keith-Magee
> > AFAIK, it is finished, just waiting for Adrian's ok. Is there
> > something missing that I'm not aware of?
>
> Oh, I thought there was something missing *I* wasn't aware of :)
The only issues I am aware of are:
1) The lack of docs (just waiting until everything was approved before
I put pen to paper)
2) The serialization order problem described (and fixed) in #3390. The
basic fixtures framework will work without this patch, but forward
referenced relations in fixtures will fail under postgres if this
patch doesn't get applied as well.
3) Approval from Adrian
> Please go ahead and check it in! I'll focus on writing docs (and maybe
> a YAML serializer), and I'll look into earlier versions of Postgres,
> too.
I have the old versions of Postgres problem sorted out; that should be
on the most recent fixtures patch.
As for checking it in; personally, I'm happy to, but after the
confusion that arose when Phase 1 of the testing framework was rolled
out, I wanted to wait until there was some explicit comment from
Adrian before I committed. A single word from Adrian, and I'm there.
Russ %-)
Daniel Roseman
> If there's a bug that's been annoying the heck out of you and you want
> it fixed before the release, this would be the time to speak up about
> it.
Because you did ask, the one that's annoying me most at the moment
(and preventing me from using newforms) is ticket 3268 -
form_for_model and fields with choices. This was accepted a month ago
but hasn't been included, and in fact the patch no longer installs
against current trunk.
It looks like it needs a design decision and tests - I'd love to help
but I don't know anything about writing tests.
--
Daniel.
Massimiliano Ravelli
I'm using your latest patch (ticket #2333) in my applications:
I find it useful and extremely fast !
I configured the svn repository of my django apps to work with
buildbot and
have all tests done each time a commit is performed.
Buildbot runs "python manage.py test" but shows the green flag even
if some tests fail because the exit code of "manage.py test" is always
zero.
I think that a different exit code when one or more tests fail would
really
be helpful in case of automated tests.
Thank you very much and keep on the good work!
Massimiliano
Russell Keith-Magee
>
> Hi Russ,
> I'm using your latest patch (ticket #2333) in my applications:
> I find it useful and extremely fast !
Glad you like it.
> I think that a different exit code when one or more tests fail would
> really
> be helpful in case of automated tests.
Nice idea, and shouldn't be too much effort. I've logged the idea as
#3576 to make sure it doesn't get lost; I should get a chance to look
at it over the next few days.
Yours,
Russ Magee %-)
Michael Radziej
> Hi Russ,
> I'm using your latest patch (ticket #2333) in my applications:
> I find it useful and extremely fast !
>
> I configured the svn repository of my django apps to work with
> buildbot and
> have all tests done each time a commit is performed.
>
> Buildbot runs "python manage.py test" but shows the green flag even
> if some tests fail because the exit code of "manage.py test" is always
> zero.
>
> I think that a different exit code when one or more tests fail would
> really
> be helpful in case of automated tests.
http://code.djangoproject.com/ticket/3253
;-)
Michael
--
noris network AG - Deutschherrnstraße 15-19 - D-90429 Nürnberg -
Tel +49-911-9352-0 - Fax +49-911-9352-100
http://www.noris.de - The IT-Outsourcing Company
Vorstand: Ingo Kraupa (Vorsitzender), Joachim Astel, Hansjochen Klenk -
Vorsitzender des Aufsichtsrats: Stefan Schnabel - AG Nürnberg HRB 17689
Michael Radziej
> Nice idea, and shouldn't be too much effort. I've logged the idea as
> #3576 to make sure it doesn't get lost; I should get a chance to look
> at it over the next few days.
#3253 has a working patch with documentation. I've closed yours as
duplicate of #3253.
Russell Keith-Magee
>
> > I think that a different exit code when one or more tests fail would
> > really
> > be helpful in case of automated tests.
>
> http://code.djangoproject.com/ticket/3253
>
> ;-)
Oops :-). To make up for my boo boo, please accept [4608]
Sheepishly,
Russ Magee %-)
Michael Radziej
> Oops :-). To make up for my boo boo, please accept [4608]
Merci! Anyways, duplicates are unavoidable in the Django ticket djungle ;-)
Espen Grindhaug
how about trying to merge one or two of the 100 development branches
into trunk.
Anyhow once again thanks a lot for a great framework.
Espen
James Bennett
> I got a little suggestion, and I think a lot of people agrees with me:
> how about trying to merge one or two of the 100 development branches
> into trunk.
We can only merge a branch when it's done, and unfortunately there
aren't many branches which have gotten to that stage. Also, other
changes in Django have effects on some of them -- for example,
per-object-permissions will essentially be made obsolete by the new
work being done on the admin.
If somebody wants to step up and champion a particular branch, go for
it; just remember that code speaks louder than anything else :)
Rob Hudson
looking 404 and 500 templates?
It seems pretty minor but important as there are 2 cases where
switching from DEBUG=True in development to DEBUG=False for production
could end up biting you...
1) With DEBUG=False and a 500 occurs and there's no 500.html, Django
exposes a traceback...
http://code.djangoproject.com/ticket/760
2) If using flatpages...
http://code.djangoproject.com/ticket/3335
Adding a fallback 404 and 500 template would fix these.
-Rob
Jacob Kaplan-Moss
> Could we get a design decision on whether to add default, non-django
> looking 404 and 500 templates?
I've close #760 and #3335 with this comment:
"""
Django's not going to ever include a default 404 or 500 template. If
we do, people won't be forced to create their own, and an error will
quickly reveal what software your server's running (think "Application
Error (Rails)").
However, [4612] adds a comment to the line that will fail so that at
least people will get a slightly better idea of where to go next.
"""
Jacob
Rob Hudson
wrote:
> I've close #760 and #3335 with this comment:
Design decision: Django won't include default 404 and 500 templates.
OK.
But does that invalidate those bugs? The default templates were a
possible solution to fix both of them.
Both of these bite the end user when they migrate from development to
production so these seem especially ugly to me... changing DEBUG
shouldn't break your site. Perhaps under DEBUG=True Django should
detect the existence of 404.html or 500.html when one of these errors
occurs? Or maybe ./manage.py validate should perform this check?
If anything, flatpages docs should mention to the user to make sure
they have a 404.html template or it will break when DEBUG=False.
That's certainly something I could provide a patch for. Is there
another place to add docs that all projects must contain 404.html and
500.html templates?
Thanks,
Rob
oyvind....@gmail.com
Massimiliano Ravelli
> #3253 has a working patch with documentation. I've closed yours as
> duplicate of #3253.
Hi Micheal, Hi Russ
>From ticket #3253:
"I didn't check whether it actually works for manage.py test";
I made a quick test and it seems that it doesn't work in this case.
I'll give a closer look at Micheal's patch as soon as possible.
Thank you
Massimiliano
Russell Keith-Magee
I tried it, and it worked for me. Can you provide an example where it fails?
Yours,
Russ Magee %-)
Massimiliano Ravelli
wrote:
> I tried it, and it worked for me.
> Can you provide an example where it fails?
I'll give it a deeper look tomorrow. I'll let you know.
Thank you very much
Massimiliano
Sandro Dentella
>
> I would like to see http://code.djangoproject.com/ticket/3297
> implemented before 0.96 if possible.
I definitely agree. And more It's a working one!
I think that newforms are the true change in this releise. We need to try
the out with at least all the features that where present with oldform.
One more missing brick is a floatfield. How can you use it without float
field? A decision must be taken on Decimals/Floats. I don't really care, I
use python2.4 but I *need* a float field and a numeric one, and as I already
told to this list, FloatField.formfield() is missing so that postgresql will
just (correctly) refuse to insert an empty string into the db.
I see that also in the user list people have asked for this. Again: a patch
is already present and working.
sandro
*:-)
Massimiliano Ravelli
wrote:
> I tried it, and it worked for me. Can you provide an example where it fails?
I updated the trunk and it works perfectly.
It was obviously my fault.
Thank you very much.
Massimiliano
Niels
> it fixed before the release, this would be the time to speak up about
There one tiny bugfix in [3501] regarding the _sqlite_extract function
that i'd like to see committed. It breaks the admin date_hierarchy
filter for models that can contain a date field with a NULL value.
--
Niels
David Larlet
> > it fixed before the release, this would be the time to speak up about
>
What about bug #2282? What's the actual status? A patch is proposed,
it doesn't suit any case but it's a good start for a part of the
world.
Cheers,
David Larlet
James Bennett
> What about bug #2282? What's the actual status? A patch is proposed,
> it doesn't suit any case but it's a good start for a part of the
> world.
It still needs a discussion and decision about how far we want to go
to support (essentially) arbitrary Unicode in slugs. That's come up a
time or two, and there's never been any sort of consensus on a best
practice, so I'd say this probably isn't going to change before 0.96.
Kai Kuehne
Well... it's not *that* important but it this is ugly, imho.
http://code.djangoproject.com/ticket/3622
Greetings
Kai
PS: I like the mood here, thanks to everybody. :)
James Bennett
> Could you decide on whether to name the attribute maxlength or max_length?
> Well... it's not *that* important but it this is ugly, imho.
AFAIK it will be migrated eventually to being 'max_length' everywhere,
but probably not for this release because that's a
backwards-incompatible change.
Rubic
> AFAIK it will be migrated eventually to being 'max_length' everywhere,
> but probably not for this release because that's a
> backwards-incompatible change.
One possibility would be to allow max_length to be
used as a maxlength attribute so applications could
begin to future-proof.
--
Jeff Bauer
Rubicon, Inc.
Honza Král
and add a deprecation note when running ./manage.py validate
>
> --
> Jeff Bauer
> Rubicon, Inc.
>
>
> >
>
--
Honza Král
E-Mail: Honza...@gmail.com
ICQ#: 107471613
Phone: +420 606 678585
olive
mich...@gmail.com
Lakin Wecker
If there's a bug that's been annoying the heck out of you and you want
it fixed before the release, this would be the time to speak up about
it. We have a fairly high concentration of Django developers all in
one place with nothing to do but code, so hopefully we'll be able to
hit a lot of stuff and get a release out very quickly (we'd like to
release 0.96 in the next day or two).
I don't know about the rest of you, but I'm whole heartedly switching to python2.5. I ran across this bug: http://code.djangoproject.com/ticket/3519 yesterday.
This has me worried that there aren't as many django users testing with python2.5 and that we may not have fleshed out all of the bugs that may be present.
It would be a shame to ship 1.0 without fully testing Django with python2.5.
Lakin
Simon G.
candidate - it's a Python 2.3 issue with rsplit in the test system.
It's been reported three times, so people are definitely running into
it.
3625 has a simple patch to fix this.
--Simon
Joseph Perla
Some of these have been complete and ready for 2 months.
j
Malcolm Tredinnick
> They don't need to be in 0.96, but can someone at least check in the
> tickets already decided as ready for check-in?
> http://code.djangoproject.com/query?status=new&status=assigned&status=reopened&stage=Ready+for+checkin
> Some of these have been complete and ready for 2 months.
Unsurprisingly, that particular report does get checked very regularly.
In our effort to streamline the triage project, it is important to
realise that some slightly different states have been collapsed into
each other and "ready for checkin" does not mean "can be checked in
without further thought". It really means that the patch looks
reasonable (to the traigers) and reasonable tests and docs are in
available, if appropriate.
A bunch of them have subsequently been notated as waiting until after
0.96 or they are for another branch. Some others are not no-brainers, so
require some thought and for a committer to have a block of time
available to drop them in. Note that a lot of tickets from that stage
have been committed over the past four weeks or so. So don't just look
at the number of tickets. From a quick scan, I couldn't find any that
have been marked as "ready" for over 2 months that are not waiting on
something else.
Regards,
Malcolm
SmileyChris
> One possibility would be to allow max_length to be
> used as a maxlength attribute so applications could
> begin to future-proof.
The patch for this is waiting for checkin (minus Honza's suggestion of
a depreciation note)
http://code.djangoproject.com/ticket/2101
Joseph Perla
j
Jeremy Dunck
> 0.96 or they are for another branch. Some others are not no-brainers, so
> require some thought and for a committer to have a block of time
> available to drop them in.
I wonder if, due to patches getting out of sync with trunk, tickets
that have been "Ready for Checkin" for longer than x weeks should go
back to Accepted?
Michael Radziej
> I wonder if, due to patches getting out of sync with trunk, tickets
> that have been "Ready for Checkin" for longer than x weeks should go
> back to Accepted?
Why? As long as they apply, what's the problem?
Michael
Jeremy Dunck
Right-- I'm supposing that some of them would no longer apply due to
code changes since the patch was submitted.
Michael Radziej
Jeremy Dunck schrieb:
Sure, in that case, it "needs better patch" and becomes Accepted, if
someone spots it.
Michael
Malcolm Tredinnick
It hasn't been a problem so far -- even quite old patches can usually be
salvaged without too much trouble. I probably average about a 50-50
balance between applying a patch unchanged and having to tweak it in
some way at commit time anyway, so accommodating a slight drift between
the source and the patch is the least we can do if we've let a patch
sit.
For things that are miles away from applying cleanly and at all
complicated, they're going to be bounced back to "needs better patch",
but, on the whole, there is some responsibility to being a committer:
we're meant to be able to do some work on our own, which includes
helping out people who've submitted patches that we've left lying for a
little while.
Regards,
Malcolm
Malcolm Tredinnick
> Thanks for that thoughtful response. Let me just point to the
> specific one I've been hoping to get through for the past couple
> months, very small in scope and complete, that should be checked in:
> http://code.djangoproject.com/ticket/3182 . I assumed that since this
> simple one hasn't gone through, then others also were floating
> stagnant.
Ah, no I see your motivation. :-) I had personally been hoping that
would be handled during the PyCon sprint, since it may have needed some
discussion about whether it's a worthwhile API addition and I gather
Jacob was already in favour of it, so in the best position to evaluate
it. That didn't happen, but it's not the end of the world; I probably
should have dropped in a comment saying what I was hoping would happen,
too.
For my own use of time, a ticket like #3182 is a pure enhancement. It
doesn't add anything you cannot already do fairly easily anyway. So when
I have time to address tickets, I'm going to be looking at things that
fix bugs and generally leaving enhancements until later. I've also
noticed in the past that it's fairly self-contained and so unlikely to
stagnate much if code around it changes (which is a good thing).
I hadn't realised it was two months old now. It will get handled
eventually and maybe fairly soon, since you've pointed out that it was
getting a little old despite being ready. There really isn't a problem
with people asking about tickets that appear to just be lying around
with no action for no clear reason, like this one, within reason.
Sometimes there will be legitimate reasons that just aren't clear
because we've assumed something or haven't communicated, as in this
case.
Regards,
Malcolm