Brant Harris wrote:
So here's my best idea:
# myproject/people/models.py contains this:
from django.core import meta
class Person(meta.Model):
first_name = meta.CharField(maxlength=30)
last_name = meta.CharField(maxlength=30)
objects = meta.Manager() # This is mirrors the defau
Jacob Kaplan-Moss wrote:
* The fix solves the visibility problems, solves naming issues, and
makes importing crystal clear. Inheritance is quite unrelated to this
as are mixins.
Jacob, sorry for misunderstading... I've reread Adrians original
proposal but still can'r get it. Could you exp
On 6 Dec 2005, at 20:54, Robert Wittams wrote:
1) For the model class defined by the user to 'just work' for
everything
This is probably useless cruft in a very involved debate, especially
as newbiedom has become slightly politicised, however...
As a very green Django programmer, I'd li
So here's my best idea:
# myproject/people/models.py contains this:
from django.core import meta
class Person(meta.Model):
first_name = meta.CharField(maxlength=30)
last_name = meta.CharField(maxlength=30)
objects = meta.Manager() # This is mirrors the default behavior.
# OR, s
>I'm having a hard time seeing any benefit to 2 over 1, unless 1 can't be
>done.
>I think you want 1 (as do I), but I just couldn't quite see if that was
>what you meant in the text ;-)
For the records: yep, I would be happy with 1). I could live with 2),
but as you I don't see any advantage over
hugo wrote:
>>I'm sure others can come up with other methods. I would prefer 1)
>>because its obvious, but don't really care as long as we get rid of the
>>generated class.
>
>
> Actually turning the model class with it's magic into one
> standard-behaving python class (preferably new-style) wou
>I'm sure others can come up with other methods. I would prefer 1)
>because its obvious, but don't really care as long as we get rid of the
>generated class.
Actually turning the model class with it's magic into one
standard-behaving python class (preferably new-style) would be a really
great thi
Jacob Kaplan-Moss wrote:
>
> * Prettiness is very important to me.
I just really don't know what to think about this rant, it is
effectively building up a personal preference about how evil class
methods are into a reason to cause yourself lots of other problems in
the future.
I honestly hav
Jonathan Daugherty wrote:
> # Not being funny, but this isn't actually a very good way to design
> # anything.
> #
> # 'Most' newcomers will design a horrifically bad api if asked, because
> # 'most' newcomers have no idea how to design apis.
>
> Maybe I should be more explicit: come up with a l
On Dec 6, 2005, at 1:38 PM, kmh wrote:
MODULE_CONSTANTS is ugly. Perhaps I should get over this, but I find
it so ugly that I often end up explicitly importing things inside each
method of my magic module. And that's pretty ugly too.
Note that this change would fix the MODULE_CONSTANTS hack.
Howdy --
My two bits:
* Class methods basically exist to mask dogmatic language design.
They make sense in languages with shitty namespace support (Java,
Objective-C) but they're lame in Python. Speaking as someone who has
taught a lot of people to program in a lot of languages: nobody
# Not being funny, but this isn't actually a very good way to design
# anything.
#
# 'Most' newcomers will design a horrifically bad api if asked, because
# 'most' newcomers have no idea how to design apis.
Maybe I should be more explicit: come up with a list of design
possibilities and ask newc
Ignore my earlier post. I prefer Robert and Hugo's thoughts on this -
even as a newcomer :)
-rob
P.S. AFAICS, removing the magic class behaviour is much more important
than the changes that were originally proposed
I agree with Robert. Too much magic. It would be a shame not to take
the chance to get rid of it if changes of this significance are
planned.
MODULE_CONSTANTS is ugly. Perhaps I should get over this, but I find
it so ugly that I often end up explicitly importing things inside each
method of my
Jonathan Daugherty wrote
> but these issues don't render the separation of scoped
> functionality unimportant.
I think that this scoping is of *far* less importance than working
vaguely like normal python modules and classes. Can anyone honestly say
they expected to have to import things at metho
>If I didn't think combining the functionality in models would confuse
>people (particularly newcomers), I could probably agree with you. But
>regardless, I think it's cleaner to keep these functionalities
>physically separate.
And you honestly think that newcomers are not confused by the fact t
Since we're looking, is there some way to more clearly separate table
vs row than using pluralization? e.g. I think it would be much cleaner
if we could say something like
rec = Poll()
table = Poll.table()
fewer imports required, less misspellings, etc.
Don't know if it would be possible, though
# Argh. What is the big deal with this? I deleted a screed from my
# original mail about this ridiculously overpumped goal.
That's good. :)
# Just look at the downsides to the magic generated class : wierdo
# issues with visibility, importing, naming, inheritance (quite apart
# from the odd curr
On 12/6/05, Jonathan Daugherty <[EMAIL PROTECTED]> wrote:
> That doesn't seem promote a clean separation of "table-level"
> vs. "row-level" functionality.
What is the table-level functionality other than queries? Why not
have a "get" or "query" member in the model class that does queries?
Sure
>Right -- the generic view infodict will change, and content types will
>change as well. It's a big change, but it's important to make.
Then we should maybe relase a point release just before the merge of
that stuff - it will break loads of peoples apps, so maybe it would be
a good idea to have "
Adrian Holovaty wrote:
> On 12/6/05, Jonathan Daugherty <[EMAIL PROTECTED]> wrote:
>
>># Why can't we just allow the model class defined by the user to be
>># used?
>>
>>That doesn't seem promote a clean separation of "table-level"
>>vs. "row-level" functionality.
>
>
> Exactly. And don't forge
Jonathan Daugherty wrote:
> # Why can't we just allow the model class defined by the user to be
> # used?
>
> That doesn't seem promote a clean separation of "table-level"
> vs. "row-level" functionality.
>
Argh. What is the big deal with this? I deleted a screed from my
original mail about thi
On 12/6/05, hugo <[EMAIL PROTECTED]> wrote:
> One problem I see: the Admin URLs currently can rely on being only
> two-level. When the listed changes are in, an app that sit's in
> cms.apps.cms will have models in cms.apps.cms.models - so will the URL
> be /cms/apps/cms/pages for the Page model? I
On 12/6/05, Jonathan Daugherty <[EMAIL PROTECTED]> wrote:
> # Why can't we just allow the model class defined by the user to be
> # used?
>
> That doesn't seem promote a clean separation of "table-level"
> vs. "row-level" functionality.
Exactly. And don't forget that we're dealing not only with
a
# Why can't we just allow the model class defined by the user to be
# used?
That doesn't seem promote a clean separation of "table-level"
vs. "row-level" functionality.
--
Jonathan Daugherty
http://www.parsed.org
Can I just get this straight :
You still want to make a 'fake' module, a 'fake' class etc?
Why can't we just allow the model class defined by the user to be used?
This would get over all of the visibility issues with the wierdo
MODULE_CONSTANTS stuff, the way you have to import things inside
fun
>One of the things we discussed was demagicifying the "magic" model
>modules.
+1 from me, even though it will be a pain to change all the code ;-)
One problem I see: the Admin URLs currently can rely on being only
two-level. When the listed changes are in, an app that sit's in
cms.apps.cms will
# So the goal is to remove these bits of cruft, while maintaining the
# clean separation of "table-level" functions (get_list(),
# get_object()) and "row-level" functions (model methods such as
# save() and delete()).
+1. Yay! This was my biggest concern.
# * Models should be in a file models.
Jacob, Simon and I did some heavy discussion this weekend about Django
improvements. (It's quite more efficient to talk about these things in
person than on mailing lists! :) )
One of the things we discussed was demagicifying the "magic" model
modules. Here are the current problems:
* Models hav
29 matches
Mail list logo
