No, this is actually one of the reasons I keep recommending people to use
inclusion tags as opposed to the {% include %} tag, and I see the same
recommendation/reasoning in the IRC channel.
On Tuesday, July 12, 2016 at 12:36:11 AM UTC+2, Tim Graham wrote:
>
> Has anyone relied on the exception
I kind of like these reports, since they can take away some of the early
review work. I would put it on the same level as the `isort` checks we have
now. On the other hand, adapting the existing codebase to 'resolve' this
code smells will introduce quite some 'stupid' commits, so it might be
gt; On Saturday, July 2, 2016 at 8:04:23 AM UTC-4, Sergei Maertens wrote:
>>
>> So, this is the follow up from the discussion with Markus.
>>
>> Implementation wise, we would only apply the capfirst on ModelForm fields
>> if the model field has no explicit ve
https://github.com/sergei-maertens/django/tree/capfirst-deprecation
contains a simple POC with the warning filtering.
On a fairly large project with a lot of ModelForms and explicit
verbose_name's, I see the warning three times on startup.
On Saturday, July 2, 2016 at 4:03:14 PM UTC+2, Sergei
would projects opt-in to the new behavior and silence the deprecation
> warning?
>
> On Saturday, July 2, 2016 at 8:04:23 AM UTC-4, Sergei Maertens wrote:
>>
>> So, this is the follow up from the discussion with Markus.
>>
>> Implementation wise, we would only
This is the reworked patch assuming the deprecation process was
completed:
https://github.com/django/django/compare/master...sergei-maertens:modelform-capfirst?expand=1
On Wednesday, November 11, 2015 at 4:59:46 PM UTC+1, Sergei Maertens wrote:
>
> This is a proposal to change how
roach matches Sven's latest reply.
On Wednesday, November 11, 2015 at 4:59:46 PM UTC+1, Sergei Maertens wrote:
>
> This is a proposal to change how Django generates form field labels from
> model fields. Currently, `capfirst` is called on `field.verbose_name` (see
> https://gith
//github.com/django/djangoproject.com/blob/7fd780c061e4244982ca5bdd914fd004c6fe90af/members/forms.py#L25
> [1] http://stackoverflow.com/a/2610741/5112
>
> On Sunday, January 31, 2016 at 4:30:09 PM UTC-5, Sergei Maertens wrote:
>>
>> I've done the initial work for a patch, assumin
+1
Yes, you should upgrade, but the reality is that some people have old
versions lying around. They should be _somewhere_, be it 'hard' to find. A
PDF or Epub is fine as well, that removes the need to maintain the build of
the docs for unsupported versions.
On Wednesday, February 17, 2016 at
This is my main concern as well. I often migrate old Joomla or other PHP
things that use md5, and it's really convenient that Django upgrades the
passwords for free for me.
Although I guess I could just write the hasher as part of the project and
add it to the setting, but then that's an
inheritence; but I don't
> think Django should do something like that.
>
> HTH,
> Shai.
>
> [1]
> https://docs.djangoproject.com/en/1.9/topics/db/models/#meta-inheritance
> [2]
> https://docs.djangoproject.com/en/1.9/topics/db/models/#meta-and-multi-
>
e comes a pull request to add a link to the djangopackages comparison
>> grid "Pagination".
>> Background: The pagination in django core is only very basic. Most people
>> want more. I think re-use helps more then re-inventing :-)
>> }}}
>>
>>
>>
Hi all,
I was browsing tickets and stumbled
upon https://code.djangoproject.com/ticket/10686, which was accepted except
for lack of documentation. The patch in the mentioned ticket makes it so
that a Model class that's used as base class with extra permissions:
class BaseTask(models.Model):
I've done the initial work for a patch, assuming a 'hard' change without
deprecation path, the branch is
here:
https://github.com/sergei-maertens/django/commit/2f3c1d8dd56522dc69448ec20aac28d4ddc70ac4.
Tests should be passing.
I've also taken a quick glance at django-admin-tools to check
t 4:52:57 PM UTC-5, Sergei Maertens wrote:
>>
>> Yes, I've thought about a setting as well briefly but quickly discarded
>> it because it would be 'yet another setting'. But this one would ofcourse
>> be temporarily, and if that's been applied successfully in the past, then
t leaves you with a defunct setting once the deprecation period
> completes. That's basically how SessionAuthenticationMiddleware worked
> when we decided to require it.
>
> On Thursday, November 19, 2015 at 4:13:40 PM UTC-5, Sergei Maertens wrote:
>>
>> Good catch.
>>
>>
eloper acknowledge/silence that deprecation warning? It
> seems to me that if it's emitted for every form field in a project that's
> not really going to be helpful.
>
> On Wednesday, November 11, 2015 at 11:47:46 AM UTC-5, Sergei Maertens
> wrote:
>>
>> I think I
ing this through a deprecation cycle?
>
> On Wednesday, November 11, 2015 at 10:59:46 AM UTC-5, Sergei Maertens
> wrote:
>>
>> This is a proposal to change how Django generates form field labels from
>> model fields. Currently, `capfirst` is called on `field.verbose_name` (see
>
This is a proposal to change how Django generates form field labels from
model fields. Currently, `capfirst` is called on `field.verbose_name`
(see
https://github.com/django/django/blob/master/django/db/models/fields/__init__.py#L872).
This behaviour has been around since pretty much forever
Relevant ticket: https://code.djangoproject.com/ticket/18166
On Tuesday, March 31, 2015 at 6:42:40 PM UTC+2, Sergei Maertens wrote:
>
> Hi all,
>
> I've quite often found myself needing to pass custom kwargs to each form
> within a formset (common parameter for all forms). A
Hi all,
I've quite often found myself needing to pass custom kwargs to each form
within a formset (common parameter for all forms). A common pattern for
this is implementing a custom BaseMyModelFormSet(BaseModelFormSet),
overriding __init__ and then passing the custom argument via
21 matches
Mail list logo
