Feature request: log capture during testing

Now that Django has logging support using the Python logging module, it would be nice if the unit testing framework included the ability to capture logs, similarly to the mail.outbox functionality. I am aware of the log_capture decorator in the testfixtures package, and we are using it for some

[GSoC composite fields] Weekly check-in #1

Hello everyone, I hope the introductions aren't necessary since I've already introduced myself in the past [1]. Just a recap, I'll be working, under the guidance of Jacob Kaplan-Moss, on support for composite model fields which will allow users to define models with composite primary keys. The

[GSoC schema alteration] Weekly check-in #1

Hi once more, So there was 0 check-in to start the thread and now meritum. People who have read, commented and evaluated my proposal already know me, but for others I will introduce myself. My name is Jan Rzepecki, I'm going to work on django schema alteration API this year for GSoC 2011. I'm on

Weekly check-in #1

Hi once more, So there was 0 check-in to start the thread and now meritum. People who have read, commented and evaluated my proposal already know me, but for others I will introduce myself. My name is Jan Rzepecki, I'm going to work on django schema alteration API this year for GSoC 2011. I'm on

[GSoC schema alteration] Weekly check-ins

Hi, So that would be my 0 check-in , purpose of this post is only to keep all following checkins under one thread. More informations starting from check-in number 1 just below. So all my further check-ins are going to be posted under check-in 0. Jan `xtrqt` Rzepecki -- You received this

Re: ModelForm validation - a better way?

> For reference, here's where we'd be in that case (I still prefer the > context manager over the idea of two separate calls to something named > "validate"): > > def my_view(request): >     form = MyModelForm(request.POST or None) >     try: >         with form.validate(tweak=True) as obj: >    

Re: "unique_together" only validated in modelform.is_valid() if ALL of the referenced fields (Ticket #13091)

Carl, Thanks for this professional reply. After rereading my post (immediately after submitting it), I realized that I was much more critical than I would normally think is fair, which is why I removed it. It's sometimes necessary, I think, to remind ourselves that most of us are volunteers

Re: ModelForm validation - a better way?

On 04/29/2011 10:02 AM, Yishai Beeri wrote: > Of course, cleanup need not be simplistic. In fact, I think the common > coder would never expect a CM to actually save an object on __exit__ - > and will be surprised by the proposed behavior. Could be - the name "finish()" was intended to give the

Re: ModelForm validation - a better way?

Hi Carl, On Fri, 29 Apr 2011 17:42:32 +0300, Carl Meyer wrote: Hi Yishai, On 04/29/2011 08:53 AM, Yishai Beeri wrote: First, the logic tied into the context manager does not match the idiomatic use of context managers in Python. One expects a context manager to "clean up"

Re: ModelForm validation - a better way?

Hi Johannes, On 04/29/2011 09:02 AM, Johannes Dollinger wrote: > Here's my take on the API: > > def my_view(request): > form = MyModelForm(request.POST or None) > try: > with form.finish() as obj: > obj.user = request.user > return redirect(obj) > except

Re: ModelForm validation - a better way?

Hi Yishai, On 04/29/2011 08:53 AM, Yishai Beeri wrote: > First, the logic tied into the context manager does not match the > idiomatic use of context managers in Python. One expects a context > manager to "clean up" on exit, rather than *save* a new object. I'd argue it's not totally off base.

Re: Trying to find Dojo Developers

On Fri, Apr 29, 2011 at 3:57 AM, mcflurry7_11 wrote: > I was wondering if any of you could help me out. I'm sorry, but we can't. This list is really the wrong place for messages like yours. First, this is a *Django* list and second this is a list for *developers* of

Re: ModelForm validation - a better way?

Am 29.04.2011 um 04:13 schrieb Carl Meyer: > Hi all, > > We have a number of tickets open (at least #12028, #13249, #13091, > #15326, and #15860 -- #13091 is the active one) reporting problems with > unique_together constraints in our attempts to validate arbitrary > partial models, when

Re: ModelForm validation - a better way?

Without really suggesting a better alternative, I'd like to highlight two problems I see with this approach: First, the logic tied into the context manager does not match the idiomatic use of context managers in Python. One expects a context manager to "clean up" on exit, rather than

Re: "unique_together" only validated in modelform.is_valid() if ALL of the referenced fields (Ticket #13091)

Hi Lior, (moved from another thread) On Apr 29, 12:16 am, Lior Sion wrote: > I looked at the sample you wrote on the other thread (unique together > on username and date, and having a null username with a given date) of > when the old behavior is the right one and it didn't

Re: "unique_together" only validated in modelform.is_valid() if ALL of the referenced fields (Ticket #13091)

Hi Mikhail, On Apr 24, 7:46 am, Mikhail Korobov wrote: > The issue is not only with unique_together indeed. Please correct me if I'm > wrong, but it seems there is no way currently to use model validation with > fields dependent on each other when one of these fields is

Re: ModelForm validation - a better way?

Hi Lior, thanks for commenting. On 04/29/2011 12:16 AM, Lior Sion wrote: > I think that forcing programmers to remember quite a long process of > for validation each time is a wrong approach, especially if only done > to support backward code that behaves in "unnatural" way. I'm not sure why you

Trying to find Dojo Developers

Hi, I was wondering if any of you could help me out. I'm currently looking for a Dojo Developer expert to work on a 3 month contract in Belfast, Northern Ireland for a client of ours. I'm a researcher with Morgan McKinley in Dublin and we've hit a wall trying to find a dojo developer who would

Re: ModelForm validation - a better way?

Carl, I also ran into this issue and opened one of the tickets about it, so I do have an interest in it. I think that forcing programmers to remember quite a long process of for validation each time is a wrong approach, especially if only done to support backward code that behaves in "unnatural"

Re: NoSQL support

On Apr 28, 4:59 pm, Russell Keith-Magee wrote: > I haven't used the django-nonrel branch, and I'm not aware of anyone that > I know and trust that has. For what it's worth, I am currently using django-nonrel and its companions djangoappengine, djangotoolbox, and

Re: Suggestion for improvement to template block/extends tags

Hey, this pattern are nested decorators in templates. Most people here are probably against having nested template tags with the same name. I think it does only make sense when there's somehow a distinction between a "placeholder" and "content". Because otherwise, templates don't know which block