On Dec 6, 2005, at 11:00 PM, Adrian Holovaty wrote:
http://code.djangoproject.com/wiki/RemovingTheMagic
* Model definitions (with properties, etc): +1; this is a no-brainer
* Database connections: -0; seems like name-churn to me; unless
there's a big reason to change the name let's just leave it alone so
that people don't have to change their code.
* Putting lookups under Person.objects: +0; I'm still going to lobby
loud and hard for having a PersonManager named "people" in the
module's namespace so that (again) old code is easier to update and
so that readability is still nice... but ".objects" seems to be the
majority opinion, so maybe I'm just being a language curmudgeon.
* Overwriting model methods (and hooks): +1 - brilliant.
* Overriding table-level functions: +1 - even more brilliant. This
might be the biggest gain of the whole proposal.
* API lookups... man, I was right there with you up until here.
First, I *really* dislike the ".q" syntax; it just feels crufty to
me, and feels like *more* magic than the double-underscore thing.
It's also not at all clear to me how joins would work; what's the
translation of:
people.get_list
(children__school__principle__first_name__startswith="Joe")
? I don't think the new syntax gains *anything* in readability over
the first, and it seems be a HUGE change for no other reason than to
please a single strongly opinionated user who's already jumpped
ship. If there's more to it than that, fine, but as this comes
entirely out of left field I can't help but get that impression.
However, this really tripped me up: "The old syntax will still be
supported and documented, indefinitely. The new syntax will be
implemented as a thin wrapper around the old syntax." Now we have
two lookup syntaxes? Please, no! If there's a compelling reason to
switch to the ".q" -- a compelling reason behind "Aaron wants it" --
let's do so, but we *have* to deprecate and remove the old syntax if
that is the case. The great thing about Python is how easy it is to
read someone else's code; providing more than one way to accomplish a
task is an excellent way to circumvent that readability.
I'm -0.9 on the ".q" syntax, and -1 on having two competing lookup
syntaxes.
* Renamed manipulators and exceptions: +0; more names to change in
everyone's code, but probably a good idea.
A few procedural notes: if we're going to churn things this much,
let's (a) release a point release before we embark on it and (b) do
all the work on a branch.
Jacob
