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
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
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
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
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
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
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
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,
# 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
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
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
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
>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
Colin Howlett wrote:
> Robert,
>
> Thanks again. I can see how I can acheive what I want to acheive with
> simple_tag.
>
> I'm not sure that I understand your first example though.
>
> Is the list of url patterns passed as parameters to inclusion_tag
> supposed to be searched for a match to
Robert,
Thanks again. I can see how I can acheive what I want to acheive with
simple_tag.
I'm not sure that I understand your first example though.
Is the list of url patterns passed as parameters to inclusion_tag
supposed to be searched for a match to decide which template to use?
It seems I
Colin Howlett wrote:
> Thanks Robert!
>
> The @inclusion_tag decorator is really nice! Much nicer than what I
> wrote above.
>
> One thing I'm not too keen on with @inclusion_tag is that the template
> is hard coded in the tag itself. (Did I understand that correctly?)
> That means everytime I
On 12/6/05, Adrian Holovaty <[EMAIL PROTECTED]> wrote:
The remaining question is: What's the behavior if vary_on_get() isn'tspecified for a particular view? Do we cache everything (includingseparate cache entries for any combination of different GETparameters) or cache nothing (current behavior)?
On 12/6/05, hugo <[EMAIL PROTECTED]> wrote:
> +1 for vary_on_get, that fits nicely into the current scheme and just
> sounds right to me.
Looks like vary_on_get is the most popular choice. So here's how that
might work:
@vary_on_get('id')
def my_view(request):
id = request.GET.get('id',
Don't you want to use my cache algorithm, proposed here:
http://groups.google.fi/group/django-developers/browse_thread/thread/fdc59b0b46502ede
?
It is able to handle GET/POST parameters (via converting these
parameters to the array and futher hashing array to the string, which
will be used as an
On 12/6/05, Maniac <[EMAIL PROTECTED]> wrote:
> But still you have to blindly copy strings from code to decorator
> parameters.
Any way of implementing this is going to require you to specify
*somewhere* which GET parameters are relevant to caching a particular
view, and it'd be hard to
On Dec 6, 2005, at 2:35 PM, Jacob Kaplan-Moss wrote:
On Dec 6, 2005, at 12:28 AM, Adrian Holovaty wrote:
Finally, along those lines, we could introduce a vary_on_get
decorator, which, used with the NO_GET_PARAMS setting, would be an
opt-in signifying a view *does* rely on query string. This
James Bennett wrote:
Except it's a decorator, so it's right there with your view code.
But still you have to blindly copy strings from code to decorator
parameters.
On Tuesday 06 December 2005 01:23, oggie rob wrote:
> FYI here are the 'text' file endings that are used throughout (if you
> used autoprops in your config file you would set these to
> eol-style:native):
> .css
> .html
> .js
> .po (?)
> .py
> .txt
> And here are the binary ones (which you
On Monday 05 December 2005 23:06, oggie rob wrote:
> Thanks John.
> So even with a good editor (I'm a SlickEdit guy myself) it can cause
> problems when you diff saved files if you don't happen to change the
> default editor save behaviour.
> Should I open a ticket?
I use SlickEdit as well... I
On 12/6/05, Maniac <[EMAIL PROTECTED]> wrote:
> So when the view's code change during development one should alsways
> remember to update this invalidators list. Not very DRY :-(
Except it's a decorator, so it's right there with your view code.
--
"May the forces of evil become confused on the
29 matches
Mail list logo
