On 12/14/05, Robert Wittams <[EMAIL PROTECTED]> wrote:
> I don't think class META needs to get involved at all.
>
> This seems much cleaner ( and avoids random things like "manager = "):
>
>
> class Person(models.Model):
> first_name = models.CharField(maxlength=30)
> last_name = models.Ch
Adrian Holovaty wrote:
> Thoughts?
>
> http://code.djangoproject.com/wiki/RemovingTheMagic
>
> Please comment here rather than on the wiki.
>
> Adrian
>
> --
> Adrian Holovaty
> holovaty.com | djangoproject.com | chicagocrime.org
>
Hi,
Just looking over the wiki page again,
I really dislik
On 12/11/05, Tim Keating <[EMAIL PROTECTED]> wrote:
> I'm approximately -235 on multiple sytaxes. This is one of the reasons
> I'm no longer using Zope.
Yeah, I'm completely against the syntax I suggested on the wiki page.
What I'm concentrating on at the moment is the other magic removal --
stop
Jacob Kaplan-Moss wrote:
> I'm -0.9 on the ".q" syntax, and -1 on having two competing lookup
> syntaxes.
I'm approximately -235 on multiple sytaxes. This is one of the reasons
I'm no longer using Zope.
TK
I second Hugo's take on the syntax. In general, anything that moves
away from a syntax for field lookup that differs from both the template
language AND Python gets a big thumbs up from me. But I also prefer the
syntax suggested in #980.
Jacob Kaplan-Moss wrote:
> On Dec 8, 2005, at 7:07 PM, Lachlan Cannon wrote:
> > Is there a reason we use a DoesNotExist rather than just
> > using a
> > single ObjectDoesNotExist exception for everything?
>
> Yes.
>
> Consider::
>
> try:
> do_something_that_involves_multiple
On Dec 8, 2005, at 7:07 PM, Lachlan Cannon wrote:
Is there a reason we use a DoesNotExist rather than just
using a
single ObjectDoesNotExist exception for everything?
Yes.
Consider::
try:
do_something_that_involves_multiple_models()
except ModelOneDoesNotE
# Is there a reason we use a DoesNotExist rather than just
# using a single ObjectDoesNotExist exception for everything?
try:
p = polls.get_object(...)
c = choices.get_object(...)
except ObjectDoesNotExist, e:
...
Which one failed?
Having per-model DoesNotExist exceptions makes it p
Jacob Kaplan-Moss wrote:
* Model definitions (with properties, etc):
+1
* Database connections:
-0
* Putting lookups under Person.objects:
Not a fan of the aesthetic, but I can't think of anything better, and it
looks like it'll work fine, so...
+0
* Overwriting model methods
How will 'or' queries work in the new get_list syntax?
-rob
> The reason I thought this should go in the branch is that I'm not
> completely satisfied with it, but also I'm kind of 'stuck' with some
> bits of it (not really hard, just keep putting them off - there is some
> duplicated code to do with OneToOne and ForeignKey, some 2.4 isms, and
> that delet
Woops, relational, yes.
> The problem is that you have thrown away the possibility of this being
> even vaguely similar to normal objects. Its incredibly confusing.
I don't see that, but then again I came up with the idea so it's
obviously not confusing to me. In my view, it seems that the obje
Brant Harris wrote:
> On 12/7/05, Robert Wittams <[EMAIL PROTECTED]> wrote:
>
>>That is just horrible. Sorry. The point is not to treat python as some
>>arbitrary data format that might have some relationship to your objects
>>: the point is to define classes that act as normally as possible and
On 12/7/05, Adrian Holovaty <[EMAIL PROTECTED]> wrote:
> Thoughts?
Models: +1, hooray for properties.
DB connections: +1
Object creation/model import: +1
Table-level functions: -0, there may be good underlying reasons for
it, but it strikes me as needless cluttering of the syntax.
Overriding:
On 12/7/05, Robert Wittams <[EMAIL PROTECTED]> wrote:
> That is just horrible. Sorry. The point is not to treat python as some
> arbitrary data format that might have some relationship to your objects
> : the point is to define classes that act as normally as possible and
> are stored in a databas
Brant Harris wrote:
> Here's yet another idea, that creates seperate classes for the Model
> (table) and the Entity (row). I think the problem with how we've been
> thinking about it is that the two have been the same, and in reality
> they are not.
>
> http://django.pastebin.com/452621
>
That
Here's yet another idea, that creates seperate classes for the Model
(table) and the Entity (row). I think the problem with how we've been
thinking about it is that the two have been the same, and in reality
they are not.
http://django.pastebin.com/452621
>>If we could open a branch up to do this kind of stuff soonish, I would
>>like to commit my 'mutually referential models' stuff to it first, as
>>this will be touching a lot of the same code - this basically moves a
>>lot of special-casing for fields out of meta/__init__.py into individual
>>fiel
Model definition:
+1, Instead of "models" what about "orm"?
Database connection:
+1
API usage: Object creation
+1
API usage: Table-level functions
+0 Instead of fiddling with objects_, just allow them to do what
you plan later on, which is to assign a custom Manager class. This
w
On 12/7/05, Robert Wittams <[EMAIL PROTECTED]> wrote:
> Also I would prefer an explicit complaint about something called
> 'objects' from the validator rather than renaming it.
That's a good idea. I've updated the wiki page.
> If we could open a branch up to do this kind of stuff soonish, I woul
Robert Wittams wrote:
Oh, and I think that the overriding save and delete is good, but we will
still need an event system in the end
Also I would prefer an explicit complaint about something called
'objects' from the validator rather than renaming it.
If we could open a branch up to do thi
Adrian Holovaty wrote:
> Thoughts?
>
> http://code.djangoproject.com/wiki/RemovingTheMagic
>
> Please comment here rather than on the wiki.
>
> Adrian
>
> --
> Adrian Holovaty
> holovaty.com | djangoproject.com | chicagocrime.org
>
This does all seem sensible to me so far. Couple of points:
On Dec 7, 2005, at 2:47 AM, Amit Upadhyay wrote:
How about supporting an SQL where clause, as seen in Rails?
FYI, you can already do this with the "where", "tables", and "params"
keywords; you just have to be a bit more explicit about it. See
http://www.djangoproject.com/documentation/db_
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 lea
hugo wrote:
[snip]
>
> 1) I'd prefer "manager = PersonManager('name_of_manager_attribute')
> over the "an attribute named objects will magically turn into objects_"
> - the default for the name should be 'objects', but if there already is
> an attribute named that, the validator should barf. And
I like the general take. My first thoughts:
If db provided an appropriate __all__ then this would be more succinct:
from django.db import *
class Toy(Model):
name = CharField(maxlength=30)
colour = CharField(maxlength=30)
class Person(Model):
first_name = CharField(maxlength=30)
On 7 dec 2005, at 10.53, Daniel Ericsson wrote:
I find the use of "objects" as a way of namespace separation a bit
off-putting. Enforcing an invocation-style via stack inspection
would cut down on the line-noise. Not a terribly big deal, just how
I'd try to do it unless there'd be somethin
On 7 dec 2005, at 06.21, Adrian Holovaty wrote:
But my rationale for changing to the magic object approach is: If we
move to class-based lookups (Person.objects.get_list() rather than
people.get_list()), the class will have been imported *anyway*, so
it's not too much of a big deal to have to u
my 2c's
I don't see an explanation in the wiki page on why I should care about
any of this. from what I see i just see myself doing some 'busy' work
rewriting my apps to use this new method.
What does removing the magic let me do which I couldn't do before?
specifica
hugo wrote:
2) I really, really dislike the
Person.objects.get_list(Person.q.first_name == 'Adrian')
+1
On 12/7/05, Simon Willison <[EMAIL PROTECTED]> wrote:
On 6 Dec 2005, at 21:00, Adrian Holovaty wrote:> Thoughts?>> http://code.djangoproject.com/wiki/RemovingTheMagicI really like almost all of it. My one hang-up is this:
Person.objects.get_list(Person.q.first_name == 'Adrian')I like the Person.obj
Somehow googlegroups ate my comment. Second try.
Overall comment: "removing magic" is a bit irritating if you actually
just exchange it for other magic (like query objects) ;-)
>Please comment here rather than on the wiki.
Two dislikes:
1) I'd prefer "manager = PersonManager('name_of_manager_a
Inline.
"Simon Willison" <[EMAIL PROTECTED]> wrote
in message news:[EMAIL PROTECTED]
>
>
> On 6 Dec 2005, at 21:00, Adrian Holovaty wrote:
>
>> Thoughts?
>>
>> http://code.djangoproject.com/wiki/RemovingTheMagic
>
> I really like almost all of it. My one hang-up is this:
>
> Person.objects.get_l
On 12/6/05, Adrian Holovaty <[EMAIL PROTECTED]> wrote:
On 12/6/05, Jeremy Dunck <[EMAIL PROTECTED]> wrote:> As (my) knee-jerk reaction, don't take Aaronsw's criticism so much to heart. :)>> He's got some points, but his is just one more opinion (and web tool).
A bunch of this stuff was discussed b
On 6 Dec 2005, at 21:00, Adrian Holovaty wrote:
Thoughts?
http://code.djangoproject.com/wiki/RemovingTheMagic
I really like almost all of it. My one hang-up is this:
Person.objects.get_list(Person.q.first_name == 'Adrian')
I like the Person.objects bit, but I'm not so keen on
Person.q.f
On 12/6/05, Jeremy Dunck <[EMAIL PROTECTED]> wrote:
> As (my) knee-jerk reaction, don't take Aaronsw's criticism so much to heart.
> :)
>
> He's got some points, but his is just one more opinion (and web tool).
A bunch of this stuff was discussed by me, Jacob and Simon this
weekend, so it's not
On 12/6/05, Adrian Holovaty <[EMAIL PROTECTED]> wrote:
>
> Thoughts?
>
> http://code.djangoproject.com/wiki/RemovingTheMagic
>
> Please comment here rather than on the wiki.
As (my) knee-jerk reaction, don't take Aaronsw's criticism so much to heart. :)
He's got some points, but his is just one
Thoughts?
http://code.djangoproject.com/wiki/RemovingTheMagic
Please comment here rather than on the wiki.
Adrian
--
Adrian Holovaty
holovaty.com | djangoproject.com | chicagocrime.org
38 matches
Mail list logo
