Magic - removal branch .. is the API stable yet?

[Ian Holsman]

Hi.

I'd like to start moving my stuff over to the magic removal branch and
was wondering if the API is stable enough to start doing so.

I'm not after something bugfree, just something where the ground is
stable enough so I don't have to rewrite huge portions of my code
every week.

regards
Ian

--
I...@Holsman.net -- blog: http://feh.holsman.net/ -- PH: ++61-3-9877-0909

If everything seems under control, you're not going fast enough. -
Mario Andretti

[Russell Keith-Magee]

On 1/23/06, Ian Holsman <kry...@gmail.com> wrote:

I'd like to start moving my stuff over to the magic removal branch and
was wondering if the API is stable enough to start doing so.

I would say probably not. There is still one big change to come - the use of descriptors on database objects. This will have a pretty big impact on the way you query the database. I don't know when these modifications are expected - I believe Robert Wittams is working on them. Robert - can you shed any light on the ETA for the descriptor changes?

Russ Magee %-)

[Adrian Holovaty]

On 1/22/06, Ian Holsman <kry...@gmail.com> wrote:
> I'd like to start moving my stuff over to the magic removal branch and
> was wondering if the API is stable enough to start doing so.
>
> I'm not after something bugfree, just something where the ground is
> stable enough so I don't have to rewrite huge portions of my code
> every week.

It's definitely not for the faint of heart, and of course it's not for
production use. But you should feel free to start experimenting, if
only to help test and make suggestions.

For my personal projects such as chicagocrime.org, I have a
magic-removal branch of the code, so I can easily run two different
versions of the code. Up until today I could even run both branches of
code against the same database, but that changed tonight because we've
changed the way database-table names are calculated.

Adrian

--
Adrian Holovaty
holovaty.com | djangoproject.com | chicagocrime.org

[hugo]

>Up until today I could even run both branches of
>code against the same database, but that changed tonight because we've
>changed the way database-table names are calculated.

Ok, now I know why it was a bad idea to switch the logger to
magic-removal ;-)

(just kidding, it's a really simple project and easily updated - and my
main sites aren't running magic removal for a good reason)

bye, Georg

[Robert Wittams]

I personally am not going to be able to work on it any time soon. Sorry.
Anyone else should feel free to give it a stab.

Robert

[Jason Davies]

Robert Wittams wrote:
> I personally am not going to be able to work on it any time soon. Sorry.
> Anyone else should feel free to give it a stab.

I'm keen to get the "semantics of subtyping" stuff done. If you have
any implementation hints to help me along that would be really helpful,
thanks.

Jason

[Andreas Stuhlmüller]

On 1/23/06, Jason Davies <jason....@gmail.com> wrote:
> I'm keen to get the "semantics of subtyping" stuff done. If you have
> any implementation hints to help me along that would be really helpful,
> thanks.

Same here. I'd love to see a working subtyping implementation for
magic removal, the sooner the better. If there is anything I can do to
help just drop me a note.

Andreas

[Joseph Kocherhans]

Is there any reason subtyping and field descriptors need to happen on
magic-removal? Could we just test/merge magic-removal and create a new
branch for those tasks? Is there anything else but those two tasks
left? It doesn't sound like either of them will be done anytime soon
and I think a lot of people are anxiously waiting for magic-removal to
be merged.

Joseph

[Adrian Holovaty]

On 1/23/06, Joseph Kocherhans <jkoch...@gmail.com> wrote:
> Is there any reason subtyping and field descriptors need to happen on
> magic-removal? Could we just test/merge magic-removal and create a new
> branch for those tasks? Is there anything else but those two tasks
> left? It doesn't sound like either of them will be done anytime soon
> and I think a lot of people are anxiously waiting for magic-removal to
> be merged.

The goal is to the minimize the amount of times people need to make
changes to their code. I was hoping the magic-removal merge will be
the last really big API change before Django 1.0 -- hence my wanting
to implement field descriptors in this branch.

[Ivan Fedorov]

Adrian Holovaty пишет:

> On 1/23/06, Joseph Kocherhans <jkoch...@gmail.com> wrote:
>
>>Is there any reason subtyping and field descriptors need to happen on
>>magic-removal? Could we just test/merge magic-removal and create a new
>>branch for those tasks? Is there anything else but those two tasks
>>left? It doesn't sound like either of them will be done anytime soon
>>and I think a lot of people are anxiously waiting for magic-removal to
>>be merged.
>
>
> The goal is to the minimize the amount of times people need to make
> changes to their code. I was hoping the magic-removal merge will be
> the last really big API change before Django 1.0 -- hence my wanting
> to implement field descriptors in this branch.

AFAIR unicodefication must be done before Django 1.0. This not big API
change, but some code must be changed too after it.
(Ex. str->repr or str->unicode)

[hugo]

>AFAIR unicodefication must be done before Django 1.0. This not big API
>change, but some code must be changed too after it.
>(Ex. str->repr or str->unicode)

Before doing it, there still is the analysis of what needs exactly to
be done - for now it's just a list of keywords on the wiki page, I
definitely need to put more into that page. But I am in Munich this
week, so I won't be able to do much on Django stuff.

The changes might introduce some backwards incompatibilities, but I
don't think it will be big changes in API or something like that - so
it would be fine to put all stuff that might introduce big API changes
(like the descriptor fields) into magic-removal, but leave out other
things like UnitOfWork (can only be done after descriptors for fields,
because some of that will be needed, I think - we need to capture
attribute assignements to register changed objects in the unit of
work) or Unicodefication.

bye, Georg