hugo wrote:
>>+1. Gets around the reserved word problem entirely, and removes a
>>little bit more magic from model definitions.
>
>
> Problem with that discussion was, IIRC, that neither Adrian nor Jacob
> where very fond of allways having to explicitely provide the manager.
> So the result of t
>+1. Gets around the reserved word problem entirely, and removes a
>little bit more magic from model definitions.
Problem with that discussion was, IIRC, that neither Adrian nor Jacob
where very fond of allways having to explicitely provide the manager.
So the result of the discussion was what we
On 1/18/06, hugo <[EMAIL PROTECTED]> wrote:
>
> One thing I would agree to is, the default 'objects' is magic that
> should be removed. Actually that was my position in the discussion, to
> make the manager assignment _allways_ explicit, so people allways will
> choose the name of the manager obje
>Personally I find the idea of "every model class has an objects
>property for manipulation in bulk, except when it doesn't" pretty
>horrifying, especially from a code maintenance point of view. I guess
>if people really want to make their lives more difficult we should
>let them but I certainly w
On 16 Jan 2006, at 08:49, hugo wrote:
Uhm - in what way is nowadays defining classes and using them
"clumsy"?
Thought that's what OO is all about. The beast is named "removing the
magic" for a good reason, so why throw in another "magic" (one that
turns a scoped class definition into a - dif
> Sorry, but I am -1 on this change. Several reasons:
One more point I would like to add:
- Flat is better than nested
Ok, so Tim Peters isn't infallible, but I think this is pretty good
advice.
my 2 cents
MWM
[current sample with defined classes and used objects]
>The above feels a little clumsy to me. Here's my proposed alternative:
[sample with inner class]
Uhm - in what way is nowadays defining classes and using them "clumsy"?
Thought that's what OO is all about. The beast is named "removing the
On 1/14/06, Simon Willison <[EMAIL PROTECTED]> wrote:
> Basically, you define your own inner class called "Manager" if you want
> to add custom methods to Person.objects (or modify the behaviour of
> existing methods). If you don't define this inner class the default
> Manager will be used.
I can
> I suppose the greater problem is the ability to easily construct (and
use) a filter on queries (e.g. construct a 'tall_people_only' filter,
make it a member of Person, so you can write
Person.get_list(tall_people_only, name__exact='Fred'). You should be
able to do this using arg-level query obje
On 1/15/06, Simon Willison <[EMAIL PROTECTED]> wrote:
>
> The current system in magic-removal enables multiple managers (you can
> assign as many as you like to different properties). I don't see the
> advantage in allowing this - why not just add wrapper methods to your
> custom Manager inner cla
I've been thinking a bit about how we add custom table-level methods to
models in the magic-removal branch. Here's how it works at the moment:
class PersonManager(models.Manager):
def get_list(self, **kwargs):
# Changes get_list() to hard-code a limit=10.
kwargs['limit'] = 10
11 matches
Mail list logo
