On Sat, Oct 2, 2010 at 8:59 AM, Kevin Howerton wrote:
> Definitely agree. Caught the missing nullhandler behavior when
> logging is off too... though didn't make the connection that this was
> likely intended to handle that case.
>
> It might make more sense to put this logic in conf/__init__.py
On Sun, Oct 3, 2010 at 11:20 AM, Russell Keith-Magee
wrote:
>> The issue is not only the frequency of failure, but how explicit/clear
>> it is. The failure here is so obscure and difficult to track down, it
>> is likely to generate an outsize support burden. In contrast, raising
>> an error on ass
+1 on proposal (for what it matters).
Tina, where did you see that Django does that? The docs link you sent
shows regular model validation. What Mamayo is looking for, I think,
is the ability to add a Meta option to a model that says
required_together=({fields: ('weight', 'height', 'width', 'leng
Sorry, I keep top replying in my emails. It's because I'm mostly
taking everything in and not really replying to anyone specifically.
I _really_ like the idea of View being synonymous with a ResponseFactory.
Using __call__:
The view base class can take *args and **kwargs and apply them lazily
wh
2010/10/3 Łukasz Rekucki :
> On 2 October 2010 12:32, Russell Keith-Magee wrote:
>> 2010/10/2 Łukasz Rekucki :
>>> On 2 October 2010 10:34, Russell Keith-Magee
>>> wrote:
> To sum this up, I think the important questions are:
>
> 1) Do View instances need to share anything ? I say: yes.
Agree
On Sun, Oct 3, 2010 at 12:20 AM, George Sakkis wrote:
> On Oct 1, 7:26 am, Russell Keith-Magee
> wrote:
>>
>> I've just added a summary of the last thread on class-based views [1].
>
> Thanks for writing this up. Having missed the discussion on that
> thread, the summary saved me a whole lot of t
On Sat, Oct 2, 2010 at 8:01 PM, Carl Meyer wrote:
>
>
> On Oct 2, 4:34 am, Russell Keith-Magee
> wrote:
>> I can't argue with the fact that setting variables in __init__() is a
>> common idiom in Python generally, and this is certainly a weakness of
>> copy on call that will fail in non-thread sa
On Sat, Oct 2, 2010 at 1:40 PM, Russell Keith-Magee
wrote:
> On Sat, Oct 2, 2010 at 7:05 PM, Patryk Zawadzki wrote:
>> Classes that represent real objects have state. Like cars have color,
>> make and registration number, your models have attributes that
>> differentiate them from other objects o
On 2 October 2010 12:32, Russell Keith-Magee wrote:
> 2010/10/2 Łukasz Rekucki :
>> On 2 October 2010 10:34, Russell Keith-Magee wrote:
>>>
>>> Another option would be to use copy-on-call, but raise an error if
>>> they provide any arguments to __init__(). This would be annoying and
>>> counter t
On Oct 2, 1:59 am, Kevin Howerton wrote:
> Also didn't realize that adding a nullhandler to just the root logger
> would remove those warnings (pretty cool)... ended up writing a bit
> that adds a nullhandler to any logger without handlers for my
> implementation in lumberjack... woops.
>
Yes,
On Oct 2, 6:46 pm, Luke Plant wrote:
> On Sat, 2010-10-02 at 09:20 -0700, George Sakkis wrote:
> > Having said that, I'm in favour of the first approach mentioned in the
> > wiki (store state on request) and I'm surprised it doesn't seem to
> > have any traction in this thread. The only argument a
On Oct 2, 1:01 pm, Carl Meyer wrote:
> Again, arguments to __init__ are not the issue. What would have to be
> checked is any assignment to self that takes place in __init__. How do
> you propose to check that?
>
I think __slots__ would do for this: it would prevent a user of a view
instance fr
On Sat, 2010-10-02 at 09:20 -0700, George Sakkis wrote:
> Having said that, I'm in favour of the first approach mentioned in the
> wiki (store state on request) and I'm surprised it doesn't seem to
> have any traction in this thread. The only argument against is "it's
> unusual to have a class whe
On Oct 1, 7:26 am, Russell Keith-Magee
wrote:
>
> I've just added a summary of the last thread on class-based views [1].
Thanks for writing this up. Having missed the discussion on that
thread, the summary saved me a whole lot of time.
> I'd like to try and get this in for 1.3. It's a big featur
Hi,
Isn't this covered by model validation [1]?
Tino
[1]
http://docs.djangoproject.com/en/dev/ref/models/instances/#validating-objects
On Fri, Oct 1, 2010 at 15:59, hejsan wrote:
> Hi.
> I just filed a feature request on the same or similar issue, and this
> thread was brought to my attention
On Oct 2, 12:32 pm, Russell Keith-Magee
wrote:
>
> The difference is that __new__ doesn't *ever* allow for initialization
> arguments -- there is no way to pass an argument in. An "arguments
> disabled by default" __init__+copy implementation allows arguments as
> an opt-in.
>
> There's also the
Hi all,
I've just uploaded a second alpha of the patch introducing unittest2
into Django's core [1]. As with last time, help is requested running
the test suite on different Python versions and different databases.
Particular attention is needed for the Oracle and GeoDjango changes,
as I don't hav
On Fri, 2010-10-01 at 17:31 +0100, Luke Plant wrote:
> Or, more drastically, we could just do this:
>
> class View(object):
> def __call__(self, request, *args, **kwargs):
> self.request = request
> self.args = args
> self.kwargs = kwargs
> resp = self.dispatch(
I've been keeping up with this thread but have not had the time to
respond until now. I will endeavor to keep it brief as this thread has
grown quite long!
+1 on using a single dispatch() method rather than hard-coding HTTP
method dispatch. As was pointed out, there are many possible dispatch
patt
On Oct 2, 4:34 am, Russell Keith-Magee
wrote:
> I can't argue with the fact that setting variables in __init__() is a
> common idiom in Python generally, and this is certainly a weakness of
> copy on call that will fail in non-thread safe ways.
>
> My counterclaim is that the move to class-based
On Sat, Oct 2, 2010 at 7:05 PM, Patryk Zawadzki wrote:
> On Sat, Oct 2, 2010 at 12:49 PM, Russell Keith-Magee
> wrote:
>> Python classes have state. People *will* assign variables to self,
>> because that's something they have done with every other Python class
>> in existence. And as soon as the
On Sat, Oct 2, 2010 at 1:05 PM, Patryk Zawadzki wrote:
> But until Joey appears to give you money (...)
s/until/before/
--
Patryk Zawadzki
--
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to django-devel
On Sat, Oct 2, 2010 at 12:49 PM, Russell Keith-Magee
wrote:
> Python classes have state. People *will* assign variables to self,
> because that's something they have done with every other Python class
> in existence. And as soon as their code hits production, their code
> will break, in unpredicta
On Sat, Oct 2, 2010 at 6:08 PM, Patryk Zawadzki wrote:
> On Fri, Oct 1, 2010 at 3:55 PM, Alex Gaynor wrote:
>> On Fri, Oct 1, 2010 at 9:53 AM, Vinay Sajip wrote:
>>> On Oct 1, 11:16 am, Johannes Dollinger
>>> wrote:
Could you (or anyone knowledgable) add a section, that explains why each
2010/10/2 Łukasz Rekucki :
> On 2 October 2010 10:34, Russell Keith-Magee wrote:
>>
>> Another option would be to use copy-on-call, but raise an error if
>> they provide any arguments to __init__(). This would be annoying and
>> counter to Python idiom, but it strikes me as less fundamentally
>> c
On Fri, Oct 1, 2010 at 3:55 PM, Alex Gaynor wrote:
> On Fri, Oct 1, 2010 at 9:53 AM, Vinay Sajip wrote:
>> On Oct 1, 11:16 am, Johannes Dollinger
>> wrote:
>>> Could you (or anyone knowledgable) add a section, that explains why each
>>> request should have its own view instance?
>>> The thread-
On 10/02/2010 01:54 AM, Jacob Kaplan-Moss wrote:
On Fri, Oct 1, 2010 at 4:46 PM, Ivan Sagalaev
wrote:
During a sprint before 1.2 I was proposing to commit my ticket [9886] that
deals with adding a .read() method to HttpRequest. Adrian suggested that it
was too late then and it's better to brin
On 2 October 2010 10:34, Russell Keith-Magee wrote:
>
> Another option would be to use copy-on-call, but raise an error if
> they provide any arguments to __init__(). This would be annoying and
> counter to Python idiom, but it strikes me as less fundamentally
> counterintuitive than prohibiting *
On Sat, Oct 2, 2010 at 12:56 PM, Carl Meyer wrote:
>
>
> On Oct 1, 10:00 pm, Russell Keith-Magee
> wrote:
>> Now, I'm sure the counterargument is going to be that copy() will be
>> just as error prone and FAQ inducing. My argument to this is:
>
> Yes.
>
>> * when it fails, it will fail during d
29 matches
Mail list logo
