Django sprint / 0.95 release at OSCON
Adrian Holovaty
next week in Portland, Oregon. Malcolm is also going to be there. Who
else is planning to come?
I'm wondering if we could get some people together for some Django
sprinting -- knocking out some tickets, fixing some bugs, adding some
features, etc. Anybody up for it?
Also, I did a Django tech talk at Google (Chicago office) yesterday,
and some Google people asked when 0.95 was coming out. I mentioned we
would probably release something at OSCON. Might as well, eh? Most --
all? -- of the magic-removal stuff has settled down, and it's about
time we had an official release.
Adrian
--
Adrian Holovaty
holovaty.com | djangoproject.com
Malcolm Tredinnick
> As Jacob write on the Django weblog, he and I are going to be at OSCON
> next week in Portland, Oregon. Malcolm is also going to be there. Who
> else is planning to come?
>
> I'm wondering if we could get some people together for some Django
> sprinting -- knocking out some tickets, fixing some bugs, adding some
> features, etc. Anybody up for it?
Sounds like a plan. I'm in.
>
> Also, I did a Django tech talk at Google (Chicago office) yesterday,
> and some Google people asked when 0.95 was coming out. I mentioned we
> would probably release something at OSCON. Might as well, eh? Most --
> all? -- of the magic-removal stuff has settled down, and it's about
> time we had an official release.
Agreed.
One thing: as we move to 1.0 (and beyond) we are going to want to plan
releases a little bit in advance so that we can give the translators
notice and have a couple of weeks of rigorous string freeze in order to
allow them to all update to the latest string base. It will also allow
us to do things like get screenshots on djangoprojects.com up to date to
match the release, etc.
Not a big deal for 0.95, since getting a new snapshot tarball out is
starting to get important; but it's something to think about in a few
months.
Regards,
Malcolm
Ben Bangert
will a few other people from my division at O'Reilly. I'd be rather
interested in talking frameworks and WSGI or perhaps having a little
Python web developer meet-up.
Lookin forward to a release with the magic-removal stuff.
Cheers,
Ben
Ivan Sagalaev
> Most -- all? -- of the magic-removal stuff has settled down
What about model inheritance? This is one feature that was before MR and
never recovered after. I remember some people in django-users were
forced to stay with pre-MR syntax because of it.
I also remember that Malcolm was deep in work on it...
Kenneth Gonsalves
On 21-Jul-06, at 8:03 PM, Ivan Sagalaev wrote:
>> Most -- all? -- of the magic-removal stuff has settled down
>
> What about model inheritance? This is one feature that was before
> MR and
> never recovered after. I remember some people in django-users were
> forced to stay with pre-MR syntax because of it.
comes up 4-5 times a day at least on IRC, most common desire is to
extend auth.User
--
regards
kg
http://lawgon.livejournal.com
http://nrcfosshelpline.in/web/
Malcolm Tredinnick
Its current status is that it is blocking on query.py being fixed in a
few ways (since it has to make a few changes in there). I would
personally rather wait until that is done before putting in the MI
stuff. However, even without that, I don't think we could settle all the
outstanding bits for MI before next week. There are a few syntax ideas
to work out, plus a couple of other things that I want to bounce of some
other developers.
When I'm less tired (after midnight here, so not now), I'll write up
what we need to work out here so that people can be thinking about that.
Regards,
Malcolm
Bryan
up"/SoC django projects. I'm particularly interested in the status of
Model Inheritance, Row Level Permissions, and Schema Evolution.
With "status" being the current state of the project and its projected
completion.
Bryan
James Bennett
> comes up 4-5 times a day at least on IRC, most common desire is to
> extend auth.User
Which I've never understood. Subclassing User, even when model
inheritance works again, will be probably the most difficult, least
efficient and least rewarding way of extending User...
--
"May the forces of evil become confused on the way to your house."
-- George Carlin
Ivan Sagalaev
> Which I've never understood. Subclassing User, even when model
> inheritance works again, will be probably the most difficult, least
> efficient and least rewarding way of extending User...
But nobody knows this beforehand. The feature is called "subclassing"
and looks like it should fit perfectly when one wants to add some
additional fields for users.
Again, having the solution with OneToOne relation scares newbies away
because it's become a kind of common wisdom that OneToOne will be
changed very drastically very soon and "all your code would burn".
I was extending User model before I've read about the "profile" thing
[1] and I did it in a way that seamed natural: created my own "User" and
was trying to refer to it all over the place as ForeignKey. Now I
realize that I've made a mistake because I have to go back and forth
over this relation all over the code. I believe this is a common
misconception.
In short, my point is that newbies being Python programmers are familiar
with extending classes but don't know about user's profiles supported in
Django.
[1]:
http://www.b-list.org/weblog/2006/06/06/django-tips-extending-user-model
Todd O'Bryan
>
> Again, having the solution with OneToOne relation scares newbies away
> because it's become a kind of common wisdom that OneToOne will be
> changed very drastically very soon and "all your code would burn".
What is the current wisdom on OneToOne? Will it be finalized soon? Ever?
Todd
James Bennett
> What is the current wisdom on OneToOne? Will it be finalized soon? Ever?
As I understand it from a conversation I had the other day, nothing
whatsoever will happen until subclassing is straightened out. At that
point we'll move to recommending people use subclassing for a lot of
the things OneToOneField is currently used for, because in many cases
that's the behavior people really want.
OneToOneField itself will remain, and there will still be cases --
like extending User -- where it's the best solution, but the
underlying behavior of the field type may change somewhat.
Bryan
extension problem is asp.net 2.0 with their provider model. The
provider model allows users to extend or "plug" in their own
implementation of a feature. This is useful when the given schema
doesn't meet your needs, such as a User model not providing an
is_approved field. Now, I could have my own User model and override
and implement the necessary membership/auth methods so that a user
cannot login if they are not active. This also makes it possible to
use data from another db or format (such as xml).
I hope that the GenericAuthorization project is headed in this general
direction.
Todd O'Bryan
On Jul 22, 2006, at 7:18 PM, James Bennett wrote:
>
> On 7/22/06, Todd O'Bryan <toddo...@mac.com> wrote:
>> What is the current wisdom on OneToOne? Will it be finalized soon?
>> Ever?
>
> As I understand it from a conversation I had the other day, nothing
> whatsoever will happen until subclassing is straightened out. At that
> point we'll move to recommending people use subclassing for a lot of
> the things OneToOneField is currently used for, because in many cases
> that's the behavior people really want.
>
> OneToOneField itself will remain, and there will still be cases --
> like extending User -- where it's the best solution, but the
> underlying behavior of the field type may change somewhat.
Underlying behavior? So, is it basically safe to use a OneToOneField
and the API, though not guaranteed to be consistent, is likely to
just require tweaking? In other words, while underlying behavior
might change, it'll look roughly equivalent...
That would be great!
Todd
James Bennett
I don't know for certain what's planned, but I would certainly hope
that it would be at least mostly backward compatible. Someone with
more extensive knowledge should pipe up and clarify, maybe.
Kenneth Gonsalves
On 22-Jul-06, at 11:04 PM, Todd O'Bryan wrote:
>>
>> Again, having the solution with OneToOne relation scares newbies away
>> because it's become a kind of common wisdom that OneToOne will be
>> changed very drastically very soon and "all your code would burn".
>
> What is the current wisdom on OneToOne? Will it be finalized soon?
> Ever?
its going to be chopped