On Fri, 2008-11-21 at 11:33 -0800, Bob Thomas wrote:
> See tickets #2203 and #9366. They're two opposite sides of an issue
> that needs to be reconciled somehow, and I figured this list was the
> best way to fight it out.
>
> #2203 summary - Date/time formats in the admin interface use the
>
On Fri, 2008-11-21 at 12:53 -0800, David Cramer wrote:
> I agree. The internals are shared among both, that's why I'd much
> rather see a good API around inclusion/exlusion.
And reading the ticket would have revealed that it discusses both
defer() and an opposite.
> I also agree that
>
On Fri, Nov 21, 2008 at 2:05 PM, David Cramer <[EMAIL PROTECTED]> wrote:
> I know personally myself, and several others who expressed
> opinions, wanted more than just an exclude option, but an include-only
> option.
That's part of this proposal, as the previous discussions indicated.
No need to
I agree. The internals are shared among both, that's why I'd much
rather see a good API around inclusion/exlusion. I also agree that
excluding text fields is a use-case, but this could also just be
considered avoidable database design. At the same time, this would
make much more sense at a
Well the hard part is getting the mechanisms in there, the original
ticket(which is on the 1.1 list) requests both, but as long as we have
the internals of how that works, the rest is easy, it's just a matter
of fields = included_fields vs. fields = [x for x in
self.model._meta.fields if x not in
On Fri, Nov 21, 2008 at 1:05 PM, David Cramer <[EMAIL PROTECTED]> wrote:
> I won't use defer, and I won't recommend people use it. I think it's
> not good practice. It's like using .select_related() implicitly. You
> really need to explicitly pass things around in order ot keep things
>
To avoid messing with the 1.1 Roadmap anymore. What happened with defer
(). I know personally myself, and several others who expressed
opinions, wanted more than just an exclude option, but an include-only
option.
Is this part of the "Exclude fields in a SELECT (QuerySet.defer())" or
is this
On Nov 18, 4:40 pm, Nathaniel Whiteinge <[EMAIL PROTECTED]> wrote:
> Out of curiosity, for those who want RequestContext added to
> render_to_response, is there a reason you don't like using
> direct_to_template instead?
Holy smokes, that thought never crossed my mind, despite using both
the
See tickets #2203 and #9366. They're two opposite sides of an issue
that needs to be reconciled somehow, and I figured this list was the
best way to fight it out.
#2203 summary - Date/time formats in the admin interface use the
{DATE,TIME,DATETIME}_FORMAT string from translation files, and fall
On Fri, Nov 21, 2008 at 10:26 AM, Bob Thomas <[EMAIL PROTECTED]> wrote:
> I would volunteer to work on this (I voted +1), though I guess you
> need a committer to back it up.
As long as someone's willing to review it -- which I don't think will
be hard -- having someone volunteering to do the
>
> - the SafeForm feature (eight +0). Personally, I suspect we
> should stop trying to second-guess form features for a bit, but
> if somebody came up with the perfect code, there's no real
> reason to defer that one (it got 8 +0 votes and nothing else, so
>
I understand about the loose coupling, but I think there is some
misunderstanding about the very nature of 'loosely coupled'. Coupling
has to do with *dependency*, not just utility. Adding a decoupled
method to the request is not a restrictive assumption, it is what it
is - a shortcut. No-one is
On Nov 20, 8:58 am, Malcolm Tredinnick <[EMAIL PROTECTED]>
wrote:
> On Thu, 2008-11-20 at 07:20 +0300, Ivan Sagalaev wrote:
> > Malcolm Tredinnick wrote:
> > > Okay. If we go this path, it's something to include in Django, rather
> > > than recommending yet another caching package. We either
2008/11/21 Malcolm Tredinnick <[EMAIL PROTECTED]>:
>
>
> I'd encourage you to follow my hint from the other day on django-users:
> look at tests/regressiontests/middleware/tests.py and add a similar sort
> of class to tests/regressiontests/cache/tests.py (the latter is where
> the caching tests
On Nov 20, 11:28 pm, "Jacob Kaplan-Moss" <[EMAIL PROTECTED]>
wrote:
> Hi folks --
>
> I've posted a draft of the 1.1 roadmap, incorporating the feedback
> gathered here over the last
> week:http://code.djangoproject.com/wiki/Version1.1Roadmap
>
> Discuss.
>
> Jacob
Hi Jacob,
I'm wondering
On Fri, 2008-11-21 at 10:29 +0100, Antoni Aloy wrote:
> Hi!
>
> I'm working on ticket #5691 http://code.djangoproject.com/ticket/5691,
> I have patched the original Django code and now I'm trying to write
> the tests.
>
> For testing purposes I have created a minimum applications and using
>
Hi!
I'm working on ticket #5691 http://code.djangoproject.com/ticket/5691,
I have patched the original Django code and now I'm trying to write
the tests.
For testing purposes I have created a minimum applications and using
Client to start checking, but I have found some problems:
*
On Nov 21, 12:34 am, Malcolm Tredinnick <[EMAIL PROTECTED]>
wrote:
> On Thu, 2008-11-20 at 07:10 -0800, rndblnch wrote:
> > hi all,
>
> > i've recently encounter a bug, submitted a ticket, was asked to solve
> > the problem myself in an initial comment :)
> > i submitted a patch that fix the
On Thu, 2008-11-20 at 23:01 -0800, Cornbread wrote:
> Are these slated to be in 1.1?
Have you read the couple of threads about proposed 1.1 features and then
the thread today about draft 1.1 features? Those would seem to answer
your question (including, if you read Jacob's follow-ups in today's
19 matches
Mail list logo
