Re: ValidationError for fields

On 08/20/2013 08:26 AM, Loic Bistuer wrote: An alternate would be to implement a method that does this. def field_error(self, name, error): self._errors = self._errors or ErrorDict() self._errors.setdefault(name, ErrorList()) self._errors[name].append(error) I also have a

Re: ValidationError for fields

> An alternate would be to implement a method that does this. > > def field_error(self, name, error): > self._errors = self._errors or ErrorDict() > self._errors.setdefault(name, ErrorList()) > self._errors[name].append(error) I also have a pending PR for that:

Re: ValidationError for fields

+1 on a better way to do field errors. An alternate would be to implement a method that does this. def field_error(self, name, error): > self._errors = self._errors or ErrorDict() > self._errors.setdefault(name, ErrorList()) > self._errors[name].append(error) Having to raise a

Re: ValidationError for fields

There is a ticket with a PR to address the issue of targeting specific fields when raising errors; I'm awaiting feedback on what should be the documented API. https://code.djangoproject.com/ticket/20867. This patch enables two patterns: - Raising ValidationError({'field': 'error'}) from

ValidationError for fields

Lack of clean control over field-specific form errors is an issue that has been raised and discussed many times over the years, but still the solution seems pretty inadequate. We're even directing people hack around with _errors and making excuses for it in the documentation.

Re: New contributor and Git

Sounds good, Paul. Starting small is a good way to get started. On Monday, August 19, 2013 5:06:46 PM UTC-4, Paul C. Anagnostopoulos wrote: > > Thanks, Daniele. That looks like good reading. > > I'm making changes to templates/builtins.txt. I can make the html files > and preview my changes in

Re: Usage and documentation of F()

Just a simple case of what I was talking about earlier, here's something we used to avoid having to pass datetime.datetime.now() to a lot of timestamp filtering queries: class Now(ExpressionNode): def __init__(self): super(Now, self).__init__(None, None, False) def evaluate(self,

Re: New contributor and Git

Thanks, Daniele. That looks like good reading. I'm making changes to templates/builtins.txt. I can make the html files and preview my changes in my browser. Seems to me it would make sense to contribute just a few changes as a test of submission procedures. Is that a good idea? ~~ Paul --

Re: New contributor and Git

On Mon, Aug 19, 2013, Paul C. Anagnostopoulos wrote: >I'd like to contribute to Django by improving the "Built-in template tags >and filters" document. I forked the Django repository at GitHub. Then I >tried to clone it according to the instructions in "Working with Git and

Re: Proposal: A diagram showing Class Based View inheritance and mixins.

Such as one for each of the pink CBVs (CreateView, UpdateView, etc)? Yeah, I'll see what I can do. On Monday, August 19, 2013 12:54:29 AM UTC-7, Daniel Greenfeld wrote: > > Seth, > > I like it a lot. Is there any chance you can provide a focused version per > Class-Based View? > > Daniel

Re: New contributor and Git

That appears to have done the trick. Thanks! ~~ Paul -- You received this message because you are subscribed to the Google Groups "Django developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-developers+unsubscr...@googlegroups.com. To

Re: New contributor and Git

GitHub has great http support now, which includes pushes. I think the documentation could mention https git urls everywhere: - let users who know about the benefits of ssh keys use them on their own, - let the others send their GitHub username/password at every push. -- You received this

Re: New contributor and Git

Hi, It seems you don't have your public key on github. Try to set your upstream url with the read-only url with the following command: $ git remote set-url upstream git://github.com/django/django.git Hope it helps. On Mon, Aug 19, 2013 at 3:24 PM, Paul C. Anagnostopoulos

New contributor and Git

Folks, I'd like to contribute to Django by improving the "Built-in template tags and filters" document. I forked the Django repository at GitHub. Then I tried to clone it according to the instructions in "Working with Git and GitHub." I received: The authenticity of host 'github.com

feedback needed: session serialization API (1.6 release blocker)

Please take a look at the proposed session serialization API on ticket #20922 and add your thoughts if you have an interest in it. -- You received this message because you are subscribed to the Google Groups "Django developers" group. To

Re: Usage and documentation of F()

On Sat, Aug 17, 2013 at 10:22 PM, Curtis Maloney wrote: > If, at the same time, perhaps ExpressionNode got a mention too, that could > really open up some opportunities :) Speaking of opportunities, here's a worthwhile ticket if we want to go further than docs for

Re: #19316 broke the external API of django.views.generic.View by changing where self.request is set

Using views externally to `.as_view()` sounds like a potential pitfall to me - I would not suggest that this is part of the public API of a view. Is this in testing code, or production? As for the change itself, this was precisely done *because* we want people to override `dispatch()` - the issue

#19316 broke the external API of django.views.generic.View by changing where self.request is set

Hey everyone, #19316, or more specifically https://code.djangoproject.com/changeset/12cf9d2be3cccb2ff63d78e93f97188040488a3d seems to have broken the documented API of View. In https://docs.djangoproject.com/en/dev/ref/class-based-views/base/#django.views.generic.base.View.dispatch,

Re: CSRF protection question

Thanks very much for your reply, knowing the reasoning behind the decisions made really helps. Cheers, James On 17 August 2013 11:56, Russell Keith-Magee wrote: > > On Thu, Aug 15, 2013 at 7:21 PM, James Roper wrote: > >> Hi, >> >> I'm a core dev

Re: tests failing/throwing errors - not sure where to start

On Mon, Aug 19, 2013 at 4:13 PM, VernonCole wrote: > Kris: > 9 failures and 17 errors are not an unusual number (out of 556 tests) > given the complexity of django and the number of platforms it works on. > The number and selection of failed tests will vary depending on

Proposal: Deprecate SimpleTestCase.settings and SimpleTestCase.urls

There is a SimpleTestCase.settings method added in commit 0dc6420ⁱ, which, according to the docstring, returns “A context manager that temporarily sets a setting and reverts back to the original value when exiting the context.”. In commit a3a53e0² its implementation has been simplified so that

Re: Performance optimisations in the deployment checklist document

Opened https://code.djangoproject.com/ticket/20938 On 16 August 2013 20:01, Daniele Procida wrote: > On Fri, Aug 16, 2013, Tim Graham wrote: > > >I don't think there's a reason to recommend one of the two cached sessions > >backends over the other as

Re: Model.__eq__

On Wednesday, August 7, 2013 10:45:01 AM UTC+3, Anssi Kääriäinen wrote: > > The way Model.__eq__ works currently should be improved. There is one > definite bug in __eq__, that is deferred instances aren't never equal to > non-deferred instances with same PK. There are also two possible >

Re: Proposal: remove triage stage someday/maybe

I agree with what Russ and Tim said. -0 On 19 August 2013 02:36, Russell Keith-Magee wrote: > > On Sun, Aug 18, 2013 at 4:10 PM, Wim Feijen wrote: > >> Hi, >> >> When triaging tickets I came across the triage stage Someday/Maybe. The >> docs say I

Re: tests failing/throwing errors - not sure where to start

Kris: 9 failures and 17 errors are not an unusual number (out of 556 tests) given the complexity of django and the number of platforms it works on. The number and selection of failed tests will vary depending on the exact implementation you are running. However, I notice that _none_ of the

Re: Proposal: A diagram showing Class Based View inheritance and mixins.

Seth, I like it a lot. Is there any chance you can provide a focused version per Class-Based View? Daniel Greenfeld On Sunday, August 18, 2013 10:03:59 PM UTC+2, Seth Moon wrote: > > I believe it would be beneficial to the Django developers and users if the > documentation included a diagram