On 9/15/05, Simon Willison <[EMAIL PROTECTED]> wrote:
> One thing that feels a little strange about Django is the way that
> model classes (with many in a single application file) turn in to
> modules when that application is installed. The reason for this is
> the module level methods associated
On 9/15/05, Simon Willison <[EMAIL PROTECTED]> wrote:
> from django.models.blog import Blog, Entry
>
> Blog.get_list()
> Blog.get_object()
> Entry.get_iterator()
I have a natural aversion to class methods like that. To me, it makes
more sense for a *module* to contain functions that return insta
"Robert Wittams" <[EMAIL PROTECTED]> wrote in
message news:[EMAIL PROTECTED]
>
> Sounds like a really good idea to me. It would certainly be best to get
> the big changes in all in a short period.
Yep. If it should be done, it should be done now before official release.
Thanks,
Eugene
Simon Willison wrote:
>
> One thing that feels a little strange about Django is the way that
> model classes (with many in a single application file) turn in to
> modules when that application is installed. The reason for this is the
> module level methods associated with a model: blogs.get_li
+1
I have become used to this, but it was (perhaps needlessly) confusing at
first.
In a way, this wouldn't be as big as the model syntax change, as it could be
done incrementally. There is nothing (AFAIK) stopping using both methods for
a while.
MWM
On Thursday 15 September 2005 04:46 pm,
One thing that feels a little strange about Django is the way that
model classes (with many in a single application file) turn in to
modules when that application is installed. The reason for this is
the module level methods associated with a model: blogs.get_list(),
blogs.get_object() et
On Sep 15, 2005, at 1:01 AM, Eugene Lazutkin wrote:
Today I submitted new patch, which introduces three new cache
backends:
'locmem:', 'file:', 'sql:'. If you are interested, please test it,
and give
me your feedback. See http://code.djangoproject.com/ticket/515 for
details
and required fi
