Re: Exceptions caught by the "include" template tag make it hard to rely on tests

[Sergei Maertens]

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 silencing behavior as a "feature" when 
> using {% include %}? It doesn't seem that's really possible given you can't 
> use that feature when template.debug=True. Thus, the current behavior 
> doesn't strike me as a reasonable default. Perhaps we can change it after a 
> deprecation. Does anyone really want an alternative to keep the silencing 
> behavior?
>
> From a user's perspective, I think it's more confusing to see a partial 
> and possibly broken page (but not necessarily knowing that it's broken) 
> than an error page.
>
> On Monday, July 11, 2016 at 6:17:58 PM UTC-4, Shai Berger wrote:
>>
>> On Monday 11 July 2016 22:45:31 Florian Apolloner wrote: 
>> > On Monday, July 11, 2016 at 7:56:34 PM UTC+2, Tim Graham wrote: 
>> > > As for me as a developer, I'd support removing the exception 
>> silencing 
>> > > that {% include %} does so that errors appear alongside any other 
>> > > exceptions (e.g. in Sentry) rather than in the django.template logger 
>> > > (that logging was added in Django 1.9). 
>> > 
>> > Dito, most tags should error out where it makes sense, but not sure if 
>> we 
>> > can easily change that :( 
>>
>> It must be opt-in; now that we have template engines and they're 
>> configured in 
>> dictionaries, we have plenty of room for that, though. 
>>
>> Another option to consider is make them error out only under the 
>> test-client. 
>>
>> My 2 cents, 
>> Shai. 
>>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/15102754-c381-45ea-9b57-61b31c6e791f%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Sonar for the Django rpoject

[Sergei Maertens]

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 best 
to get it done with in one or two go's.

If it can be applied to pull-requests, it would be nice I guess.

One final question: why use sonar instead of something like pylint/pep8 - 
these tools also provide static analysis and report common violations in 
the Python world.

On Wednesday, August 31, 2016 at 7:50:38 PM UTC+2, Ivan Sevastoyanov wrote:
>
>
> 
> I'm posting the the 11 criticals. In my opinion, they are not critical, 
> they are just code smells. I will try to export the report so you can 
> review the major issues by groups.
>
> Regards,
> Ivan
>
> On Wednesday, August 31, 2016 at 2:15:48 PM UTC+3, Tim Graham wrote:
>>
>> Any security issues should be reported to secu...@djangoproject.com, 
>> otherwise it's fine to share the information here.
>>
>> On Wednesday, August 31, 2016 at 2:25:55 AM UTC-4, Ivan Sevastoyanov 
>> wrote:
>>>
>>> All the rules are with a default severity so there might be some major 
>>> issues that it's worth reviewing them. I will post the critical issues this 
>>> evening because I'm at work now. Do you want to post them somewhere else 
>>> because it's a sensitive information? I will try to find out how to export 
>>> the whole report in a convenient format.
>>>
>>> Regards,
>>> Ivan
>>>
>>> On Wednesday, August 31, 2016 at 12:55:35 AM UTC+3, Tim Graham wrote:

 Perhaps you could tell us about some of the critical issues so we could 
 get a sense for that.

 On Tuesday, August 30, 2016 at 4:26:42 PM UTC-4, Ivan Sevastoyanov 
 wrote:
>
>
> 
> That is the report from the Sonar with all the rules included. 
> Unfortunately, I cannot export it as a PDF or some more convenient 
> format. 
> I can describe all the steps in my blog so some of the Django members 
> could 
> set up Sonar on his/her machine and see a lot more details and figure out 
> if it's worth it to fix some of the issues.
>
> On Sunday, August 28, 2016 at 11:16:57 PM UTC+3, Aymeric Augustin 
> wrote:
>>
>> On 28 Aug 2016, at 21:43, Ivan Sevastoyanov  
>> wrote: 
>>
>> > My question is do you consider using SonarQube for code quality 
>> analysis, static analysis and find bugs because it's able to do that. 
>>
>>
>> I guess that depends on the signal / noise ratio in the things 
>> SonarQube flags. 
>>
>> Perhaps you could do an initial run and see whether SonarQube spots 
>> interesting bugs? 
>>
>> I have no idea what the results could be because I’m not familiar 
>> with static analysis of Python code. 
>>
>> -- 
>> Aymeric. 
>>
>>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/21d19365-ab7f-4870-9140-e8ec2f786b87%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Form field labels change proposal

[Sergei Maertens]

I've talked with some other core developers at the sprint, and the proposed 
flow is more in line with the initial proposal again:

* The deprecation cycle would include a settings (let's call it 
CAPFIRST_MODELFORM_LABEL), defaulting to False (the new behaviour). Users 
who wish to keep the old behaviour for a while set this to True
* The capfirst calls (there are 2 relevant ones) are replaced by wrappers 
that check the CAPFIRST_MODELFORM_LABEL setting. If it's set to True, the 
real capfirst is applied to field.verbose_name, else the raw 
field.verbose_name is returned.
* The Django admin css can be updated to include the CSS rule, so it looks 
still the same. Drawback is that this breaks tests if people are actively 
checking the labels/HTML for forms. The recommended approach here is to 
provide the capitalized strings in verbose_name
* For the front-end, the example CSS can be documented, or the option to 
capitalize the verbose_name.

Note that the new behaviour would be the default in the setting.

One other drawback I just thought of is that validation errors sometimes 
include the verbose_name (I think). This can look weird if the 
end-developer has specified a capitalized verbose_name, but that's also the 
case already. The recommended approach here would be to do the capitalizing 
in CSS.

On Saturday, July 2, 2016 at 3:28:58 PM UTC+2, Tim Graham wrote:
>
> How 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 apply the capfirst on ModelForm fields 
>> if the model field has no explicit verbose_name set. That way, you can 
>> control the capitalization on the model level without having to specify it 
>> on the form again.
>>
>> This could go through the usual deprecation cycle, with a warnings filter 
>> so that the warning is only emited once. An example of that already exists 
>> in the migrations: django.db.migrations.state.ModelState.render:
>> ...
>> with warnings.catch_warnings():
>> warnings.filterwarnings(
>> "ignore", "Managers from concrete parents will soon 
>> qualify as default managers",
>> RemovedInDjango20Warning)
>> ...
>>
>> In our case, the 'ignore' would become 'once'.
>>
>> The admin CSS would be updated to include the CSS selector for labels so 
>> that the capitalization is applied in CSS.
>>
>> The placeholder issue for djangoproject.com would then have to be 
>> handled in the djangoproject.com code, unfortunately there's no easy way 
>> around that.
>>
>> This gives the developer using Django full control over the labels in a 
>> DRY way.
>>
>> This approach 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://github.com/django/django/blob/master/django/db/models/fields/__init__.py#L872).
>>>  
>>> This behaviour has been around since pretty much forever and makes sense.
>>>
>>> However, this affects what you put down in your translations - if a 
>>> lowercased verbose name is what you want (and you translate it as such), 
>>> Django will make your form labels uppercase and there's no clean way around 
>>> that.
>>>
>>> There is a very specific use case for this proposal. The house-style of 
>>> a design states that all form labels should be lowercase - but names of the 
>>> brand should be capitalized. Example: 'you agree to the Brand terms'. This 
>>> is not easily feasible: css text-transform will also lowercase the brand 
>>> name, and Django uppercases the first letter. Another possible use case 
>>> could be if you insist on putting the labels to the right of the form 
>>> input, but I will agree that looks silly.
>>>
>>> So the proposal is to get rid of the capfirst call, and in the admin 
>>> this could be mitigated for backwards compatibility by modifying the css to 
>>> include:
>>> label {
>>> text-transform: capitalize;
>>> }
>>>
>>> This is ofcourse a fairly big backwards-incompatible change towards 
>>> front-end/non-vendor code, as people now have to explicitly make sure that 
>>> labels are capitalized in their own templates. So 

Re: Form field labels change proposal

[Sergei Maertens]

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 Maertens wrote:
>
> I am experimenting with warnings.filterwarnings('once', ...), which 
> reduces the total warning output to 4 warnings, while there are about 10-15 
> calls. I haven't been able to completely silence it, probably because there 
> are certain imports happening before a custom filter comes into pla
>
> Opting in to the new behaviour is not covered. My personal feeling about 
> this is that adding machinery to be able to opt in and silencing the 
> warnings would be much more work than making the actual change. Extra 
> settings were opted before, I don't like it because of the 
> extra-machinery-reason I just mentioned. It *feels* as if it's either make 
> the (backwards incompatible) change at once, or go through the entire 
> deprecation cycle.
>
> I'm open for suggestions, since obviously I don't have all the answers 
> myself...
>
> On Saturday, July 2, 2016 at 3:28:58 PM UTC+2, Tim Graham wrote:
>>
>> How 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 apply the capfirst on ModelForm 
>>> fields if the model field has no explicit verbose_name set. That way, you 
>>> can control the capitalization on the model level without having to specify 
>>> it on the form again.
>>>
>>> This could go through the usual deprecation cycle, with a warnings 
>>> filter so that the warning is only emited once. An example of that already 
>>> exists in the migrations: django.db.migrations.state.ModelState.render:
>>> ...
>>> with warnings.catch_warnings():
>>> warnings.filterwarnings(
>>> "ignore", "Managers from concrete parents will soon 
>>> qualify as default managers",
>>> RemovedInDjango20Warning)
>>> ...
>>>
>>> In our case, the 'ignore' would become 'once'.
>>>
>>> The admin CSS would be updated to include the CSS selector for labels so 
>>> that the capitalization is applied in CSS.
>>>
>>> The placeholder issue for djangoproject.com would then have to be 
>>> handled in the djangoproject.com code, unfortunately there's no easy 
>>> way around that.
>>>
>>> This gives the developer using Django full control over the labels in a 
>>> DRY way.
>>>
>>> This approach 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://github.com/django/django/blob/master/django/db/models/fields/__init__.py#L872).
>>>>  
>>>> This behaviour has been around since pretty much forever and makes sense.
>>>>
>>>> However, this affects what you put down in your translations - if a 
>>>> lowercased verbose name is what you want (and you translate it as such), 
>>>> Django will make your form labels uppercase and there's no clean way 
>>>> around 
>>>> that.
>>>>
>>>> There is a very specific use case for this proposal. The house-style of 
>>>> a design states that all form labels should be lowercase - but names of 
>>>> the 
>>>> brand should be capitalized. Example: 'you agree to the Brand terms'. This 
>>>> is not easily feasible: css text-transform will also lowercase the brand 
>>>> name, and Django uppercases the first letter. Another possible use case 
>>>> could be if you insist on putting the labels to the right of the form 
>>>> input, but I will agree that looks silly.
>>>>
>>>> So the proposal is to get rid of the capfirst call, and in the admin 
>>>> this could be mitigated for backwards compatibility by modifying the css 
>>>> to 
>>>> include:
>>>> label {
>>>> text-transform: capitalize;
>>>> }
>>>&

Re: Form field labels change proposal

[Sergei Maertens]

I am experimenting with warnings.filterwarnings('once', ...), which reduces 
the total warning output to 4 warnings, while there are about 10-15 calls. 
I haven't been able to completely silence it, probably because there are 
certain imports happening before a custom filter comes into pla

Opting in to the new behaviour is not covered. My personal feeling about 
this is that adding machinery to be able to opt in and silencing the 
warnings would be much more work than making the actual change. Extra 
settings were opted before, I don't like it because of the 
extra-machinery-reason I just mentioned. It *feels* as if it's either make 
the (backwards incompatible) change at once, or go through the entire 
deprecation cycle.

I'm open for suggestions, since obviously I don't have all the answers 
myself...

On Saturday, July 2, 2016 at 3:28:58 PM UTC+2, Tim Graham wrote:
>
> How 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 apply the capfirst on ModelForm fields 
>> if the model field has no explicit verbose_name set. That way, you can 
>> control the capitalization on the model level without having to specify it 
>> on the form again.
>>
>> This could go through the usual deprecation cycle, with a warnings filter 
>> so that the warning is only emited once. An example of that already exists 
>> in the migrations: django.db.migrations.state.ModelState.render:
>> ...
>> with warnings.catch_warnings():
>> warnings.filterwarnings(
>> "ignore", "Managers from concrete parents will soon 
>> qualify as default managers",
>> RemovedInDjango20Warning)
>> ...
>>
>> In our case, the 'ignore' would become 'once'.
>>
>> The admin CSS would be updated to include the CSS selector for labels so 
>> that the capitalization is applied in CSS.
>>
>> The placeholder issue for djangoproject.com would then have to be 
>> handled in the djangoproject.com code, unfortunately there's no easy way 
>> around that.
>>
>> This gives the developer using Django full control over the labels in a 
>> DRY way.
>>
>> This approach 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://github.com/django/django/blob/master/django/db/models/fields/__init__.py#L872).
>>>  
>>> This behaviour has been around since pretty much forever and makes sense.
>>>
>>> However, this affects what you put down in your translations - if a 
>>> lowercased verbose name is what you want (and you translate it as such), 
>>> Django will make your form labels uppercase and there's no clean way around 
>>> that.
>>>
>>> There is a very specific use case for this proposal. The house-style of 
>>> a design states that all form labels should be lowercase - but names of the 
>>> brand should be capitalized. Example: 'you agree to the Brand terms'. This 
>>> is not easily feasible: css text-transform will also lowercase the brand 
>>> name, and Django uppercases the first letter. Another possible use case 
>>> could be if you insist on putting the labels to the right of the form 
>>> input, but I will agree that looks silly.
>>>
>>> So the proposal is to get rid of the capfirst call, and in the admin 
>>> this could be mitigated for backwards compatibility by modifying the css to 
>>> include:
>>> label {
>>> text-transform: capitalize;
>>> }
>>>
>>> This is ofcourse a fairly big backwards-incompatible change towards 
>>> front-end/non-vendor code, as people now have to explicitly make sure that 
>>> labels are capitalized in their own templates. So this should probably go 
>>> through the usual deprecation mechanics (silent, warning, remove), if it 
>>> happens at all.
>>>
>>> What are current workarounds for this problem?
>>>
>>>- explicitly specifying the label value in the ModelForm definition: 
>>>this violates the DRY principle, you already defined the verbose_name on 
>>>the model field
>>>- creating a form mixin that will lowercase the f

Re: Form field labels change proposal

[Sergei Maertens]

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 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 and makes sense.
>
> However, this affects what you put down in your translations - if a 
> lowercased verbose name is what you want (and you translate it as such), 
> Django will make your form labels uppercase and there's no clean way around 
> that.
>
> There is a very specific use case for this proposal. The house-style of a 
> design states that all form labels should be lowercase - but names of the 
> brand should be capitalized. Example: 'you agree to the Brand terms'. This 
> is not easily feasible: css text-transform will also lowercase the brand 
> name, and Django uppercases the first letter. Another possible use case 
> could be if you insist on putting the labels to the right of the form 
> input, but I will agree that looks silly.
>
> So the proposal is to get rid of the capfirst call, and in the admin this 
> could be mitigated for backwards compatibility by modifying the css to 
> include:
> label {
> text-transform: capitalize;
> }
>
> This is ofcourse a fairly big backwards-incompatible change towards 
> front-end/non-vendor code, as people now have to explicitly make sure that 
> labels are capitalized in their own templates. So this should probably go 
> through the usual deprecation mechanics (silent, warning, remove), if it 
> happens at all.
>
> What are current workarounds for this problem?
>
>- explicitly specifying the label value in the ModelForm definition: 
>this violates the DRY principle, you already defined the verbose_name on 
>the model field
>- creating a form mixin that will lowercase the first letter of the 
>label for all fields
>   - you still have to check if the first word if it's the Brand 
>   string, because then it should stay capitalized
>   - you now have to include this mixin in every single form, and can 
>   no longer rely on implicitly generated form classes in generic CBV
>- create a templatefilter that decapitalizes the label, and 
>re-capitalizes 'brand' occurrences to 'Brand' (currently implemented)
>   - you now have to not forget this filter everywhere you render forms
>   - performance hit if this is based on regular expressions (which in 
>   this case it is because subbrand should not become subBrand)
>
> All in all, I'm of the opinion that the flexibility you gain by NOT 
> manipulating the label in Django outweighs the backwards incompatible 
> change. I'm also strongly of the opinion that capitalizing labels is 
> something that should be done entirely in CSS - whether the label is 
> capitalized, lower case or upper case shouldn't matter for Django's 
> internals.
>
> Reasons to not do this:
>
>- cater to common convention, not clients (quoted from #django-dev on 
>irc): in my opinion this works 95% of the time, but your forced into 
>violating some of Django's principles if you divert from this, most 
> notably 
>DRY
>- maintain backwards compatibility
>
> Reasons to do this:
>
>- gain flexibility about the display of form labels
>- keep the codebase sane
>
>
> Bonus: vaguely related ticket: https://code.djangoproject.com/ticket/5518
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/c749d578-9464-419f-a972-a21b25ac3aec%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Form field labels change proposal

[Sergei Maertens]

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 verbose_name set. That way, you can 
control the capitalization on the model level without having to specify it 
on the form again.

This could go through the usual deprecation cycle, with a warnings filter 
so that the warning is only emited once. An example of that already exists 
in the migrations: django.db.migrations.state.ModelState.render:
...
with warnings.catch_warnings():
warnings.filterwarnings(
"ignore", "Managers from concrete parents will soon qualify 
as default managers",
RemovedInDjango20Warning)
...

In our case, the 'ignore' would become 'once'.

The admin CSS would be updated to include the CSS selector for labels so 
that the capitalization is applied in CSS.

The placeholder issue for djangoproject.com would then have to be handled 
in the djangoproject.com code, unfortunately there's no easy way around 
that.

This gives the developer using Django full control over the labels in a DRY 
way.

This approach 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://github.com/django/django/blob/master/django/db/models/fields/__init__.py#L872).
>  
> This behaviour has been around since pretty much forever and makes sense.
>
> However, this affects what you put down in your translations - if a 
> lowercased verbose name is what you want (and you translate it as such), 
> Django will make your form labels uppercase and there's no clean way around 
> that.
>
> There is a very specific use case for this proposal. The house-style of a 
> design states that all form labels should be lowercase - but names of the 
> brand should be capitalized. Example: 'you agree to the Brand terms'. This 
> is not easily feasible: css text-transform will also lowercase the brand 
> name, and Django uppercases the first letter. Another possible use case 
> could be if you insist on putting the labels to the right of the form 
> input, but I will agree that looks silly.
>
> So the proposal is to get rid of the capfirst call, and in the admin this 
> could be mitigated for backwards compatibility by modifying the css to 
> include:
> label {
> text-transform: capitalize;
> }
>
> This is ofcourse a fairly big backwards-incompatible change towards 
> front-end/non-vendor code, as people now have to explicitly make sure that 
> labels are capitalized in their own templates. So this should probably go 
> through the usual deprecation mechanics (silent, warning, remove), if it 
> happens at all.
>
> What are current workarounds for this problem?
>
>- explicitly specifying the label value in the ModelForm definition: 
>this violates the DRY principle, you already defined the verbose_name on 
>the model field
>- creating a form mixin that will lowercase the first letter of the 
>label for all fields
>   - you still have to check if the first word if it's the Brand 
>   string, because then it should stay capitalized
>   - you now have to include this mixin in every single form, and can 
>   no longer rely on implicitly generated form classes in generic CBV
>- create a templatefilter that decapitalizes the label, and 
>re-capitalizes 'brand' occurrences to 'Brand' (currently implemented)
>   - you now have to not forget this filter everywhere you render forms
>   - performance hit if this is based on regular expressions (which in 
>   this case it is because subbrand should not become subBrand)
>
> All in all, I'm of the opinion that the flexibility you gain by NOT 
> manipulating the label in Django outweighs the backwards incompatible 
> change. I'm also strongly of the opinion that capitalizing labels is 
> something that should be done entirely in CSS - whether the label is 
> capitalized, lower case or upper case shouldn't matter for Django's 
> internals.
>
> Reasons to not do this:
>
>- cater to common convention, not clients (quoted from #django-dev on 
>irc): in my opinion this works 95% of the time, but your forced into 
>violating some of Django's principles if you divert from this, most 
> notably 
>DRY
>- maintain backwards compatibility
>
> Reasons to do this:
>
>- gain flexibility about the display of form labels
>- keep the codebase sane
>
>
> Bonus: vaguely related ticket: https://code.djangoproject.com/ticket/5518
>

-- 
You 

Re: Form field labels change proposal

[Sergei Maertens]

Thanks for these specific use cases, I'll see if I can come up with some
acceptable solutions in a reasonable time
On Apr 13, 2016 6:47 PM, "Tim Graham" <timogra...@gmail.com> wrote:

> Took a quick look at djangoproject.com with this change. I noticed we're
> using the label to construct an input placeholder [0]. I think adapting
> that for this change isn't so easy to do in a cross-browser way via CSS [1]
> but we could add capfirst in the code.
>
> The question of a deprecation seems to be whether it's better to ask every
> Django project opt into the new behavior in the next two releases via some
> temporary setting or if we force all projects to adapt their CSS (and
> possibly code, as the example above shows) for Django 1.10. I'm not too
> happy with either path.
>
> I'm not sure about the validation messages. If we stop capitalizing the
> label, the message "%(field_label)s must be unique for" won't start with a
> capital anymore. On the other hand, capitalizing field_label is awkward if
> a custom message that doesn't put field_label at the start of the sentence
> is used.
>
> [0]
> https://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, assuming a 'hard' change without
>> deprecation path, the branch is here:
>> https://github.com/sergei-maertens/django/commit/2f3c1d8dd56522dc69448ec20aac28d4ddc70ac4
>> <https://www.google.com/url?q=https%3A%2F%2Fgithub.com%2Fsergei-maertens%2Fdjango%2Fcommit%2F2f3c1d8dd56522dc69448ec20aac28d4ddc70ac4=D=1=AFQjCNF1RxmN7pPTemwhThfU-Su1TWDDZA>.
>> Tests should be passing.
>>
>> I've also taken a quick glance at django-admin-tools to check if they do
>> anything special with decapitalizing/capitalizing things, but all seems to
>> be well. Django injects the form css in the block extrastyle within
>> change_form.html. For Grappelli/django-xadmin that block is present, but
>> Grappelli overrides change_form.html, so that would probably need updating.
>> I haven't looked at any other admin-theme packages, but the change would be
>> trivial for them as well - providing a proper documentation notion.
>>
>> The only things so far I'm not really sure of are:
>>
>>- Is deprecation required or not (input needed from other core devs I
>>presume)
>>- what with the validation error messages: as it stands, field labels
>>are capitalized at the moment, and they're not in a  tag. Examples
>>can be found
>>in: django.db.models.base.Model.(date_error_message|unique_error_message)
>>
>> In the tests I also noticed that there are cases where the label itself
>> is not wrapped in a  tag
>> (django.tests.forms_tests.tests.test_forms.FormsTestCase.test_templates_with_forms).
>>
>> On Friday, November 20, 2015 at 8:31:55 PM UTC+1, Tim Graham wrote:
>>>
>>> Looks easy enough. I was going to write, "Seems to me that there's more
>>> complexity in a deprecation path that requires a temporary opt-in setting
>>> rather than simply making the backwards incompatible change. Unless I
>>> missed something, adding CSS like that shouldn't cause problems for any
>>> apps maintaining compatibility with older versions of Django." but then I
>>> thought of a different case where it could be trickier to upgrade:
>>> developers who are specifying label='lower string' in some places to
>>> workaround the current behavior (but still want uppercased labels
>>> everywhere else). I guess the solution would be to use the text-transform
>>> rule you mentioned and another CSS rule targeting all labels IDs that you
>>> want to remain lowercased.
>>>
>>> I'd like other opinions about whether or not a deprecation seems helpful
>>> for this. Personally, I'd rather just fix my CSS when upgrading rather than
>>> fix my CSS *and* add a setting for a few Django versions to silence the
>>> deprecation. I guess some people might like a few Django versions to update
>>> their CSS though (also we promised to try to provide fairly seamless
>>> upgrades from one LTS to the next).
>>>
>>> On Friday, November 20, 2015 at 11:38:53 AM UTC-5, Sergei Maertens wrote:
>>>>
>>>> In
>>>> https://github.com/django/django/blob/master/django/contrib/admin/static/admin/css/forms.css#L31
>>>> <https://www.google.com/url?q=https%3A%2F%2Fgithub.com%2Fdjango%2Fdjango%2Fblob%2Fmaster%2Fd

Re: [Discussion] Legacy documentation / Boken docs Django v1.2

[Sergei Maertens]

+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 10:30:57 AM UTC+1, Marc Tamlyn wrote:
>
> I see no reason to remove old versions from readthedocs.
>
> On 17 February 2016 at 04:22, Felipe Prenholato  > wrote:
>
>> I was catch by that change today and found the docs in 
>> http://django.readthedocs.org/en/1.5.x/.
>>
>> I wan't to suggest that for documentations that Django will remove from 
>> docs.djangoproject.com and from django.readthedocs.org we keep instead 
>> links to download PDFs / epubs / HTML zips in some place that is easy to 
>> find and so users can download it. Maybe some page like "Older versions" 
>> inside documentation.
>>
>> Well, just a thought :).
>>
>> Thx, Felipe.
>>
>> Felipe Prenholato.
>> Home page: http://devwithpassion.com | http://chronosbox.org/blog
>> GitHub: http://github.com/chronossc/ | Twitter: 
>> http://twitter.com/chronossc
>> LinkedIn: http://br.linkedin.com/in/felipeprenholato/
>>
>> 2016-02-17 2:10 GMT-02:00 Tim Graham :
>>
>>> I removed the 1.4, 1.5, and 1.6 docs from docs.djangoproject.com today. 
>>> They are still available on readthedocs. I've spent more than a couple 
>>> hours recently debugging some problems related to documentation builds 
>>> there. Some are described in 
>>> https://github.com/django/djangoproject.com/issues/627, otherwise are 
>>> related to elasticsearch (timeouts due to indexing so many documents, I 
>>> think). I hope removing old docs versions will help to reduce the 
>>> maintenance overhead of these tasks. Also, a stale link in the docs was 
>>> pointing to a site with adult content. I backported the fix as far back as 
>>> 1.4 today.
>>>
>>> On Monday, April 13, 2015 at 11:08:59 AM UTC-4, Florian Apolloner wrote:

 As long as it doesn't hurt we can keep em there -- remove as soon as 
 they cause a problem ;)

 On Monday, April 13, 2015 at 4:30:01 PM UTC+2, Tim Graham wrote:
>
> I just discontinued the 1.3 docs on docs.djangoproject.com, they are 
> still available on django.readthedocs.org. Do you think we should 
> keep it there or not?
>
> On Thursday, August 7, 2014 at 7:45:15 AM UTC-4, Tim Graham wrote:
>>
>> I'm in favor of discontinuing older version of the docs. I recently 
>> fixed the 1.3 documentation builder since there were several complaints, 
>> but no one has complained about 1.2.
>>
>> On Thursday, August 7, 2014 7:32:25 AM UTC-4, Areski Belaid wrote:
>>>
>>> Hi Folks,
>>>
>>> I wanted to open a discussion regarding the following ticket 
>>> https://code.djangoproject.com/ticket/23042
>>>
>>> To summarize briefly, you may notice that we can search doc for 
>>> Django version 1.2 (for example 
>>> https://docs.djangoproject.com/search/?q=forms=4) but the 
>>> links in the result won't work.
>>>
>>>
>>> As Baptiste (IRC bmispelon) explained on IRC, we may have 2 approach 
>>> to solve this problem:
>>>
>>> 1) Fix the docs builder for versions < 1.2 (at the moment the 
>>> doc-building process is broken on old branches due to different version 
>>> of 
>>> Sphinx)
>>>
>>> 2) Discontinue older Django docs version and decide a policy 
>>> regarding doc hosting
>>>
>>>
>>> What do you think?
>>>
>>>
>>> -- 
>>> //Areski
>>>
>>> -- 
>>> You received this message because you are subscribed to the Google 
>>> Groups "Django developers (Contributions to Django itself)" group.
>>> To unsubscribe from this group and stop receiving emails from it, send 
>>> an email to django-develop...@googlegroups.com .
>>> To post to this group, send email to django-d...@googlegroups.com 
>>> .
>>> Visit this group at https://groups.google.com/group/django-developers.
>>> To view this discussion on the web visit 
>>> https://groups.google.com/d/msgid/django-developers/8c2638b5-6604-4bd4-b470-9096aee14b69%40googlegroups.com
>>>  
>>> 
>>> .
>>>
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>>
>> -- 
>> You received this message because you are subscribed to the Google Groups 
>> "Django developers (Contributions to Django itself)" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to django-develop...@googlegroups.com .
>> To post to this group, send email to django-d...@googlegroups.com 
>> .
>> Visit this group at https://groups.google.com/group/django-developers.
>> To view this discussion on the web visit 
>> 

Re: remove support for unsalted password hashers?

[Sergei Maertens]

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 additional burding because you 
need to keep track of potential new hashers that get added in the default 
settings.

On Friday, February 5, 2016 at 1:05:01 PM UTC+1, Rafał Pitoń wrote:
>
> Will I still be able to implement unsalted hasher if I so desire?
>
> Don't get me wrong, I understand thats pretty crappy way to store 
> password, but there are times when you inherit large set of data from site 
> that you are moving from some old PHP contraption that happens to be around 
> since 2006, is big (>100 users), ran by company that dominates one of 
> nation's markets and says "absolutely no" on making all those housewifes 
> reset passwords, and your passwords happen to use md5(md5(pass) + 
> md5(pass)) for passwords?
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/56677162-c020-4c2f-8d1f-b35ec0b9874d%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: #10686 - inheritance of extra permissions from base class to child class

[Sergei Maertens]

Thanks for the input, that clears up some details which bring me on
agreement for the first suggestion.
Op 2 feb. 2016 21:51 schreef "Shai Berger" <s...@platonix.com>:

> Hi Sergei,
>
> Two notes:
>
> 1) For Abstract base classes, Meta is inherited by default[1] which would
> make
> the permissions inherited by default. For multi-table inheritance, this is
> not
> the case[2].
>
> 2) The second option as you presented it, where AssignedTask.Meta's
> permissions are added to its parent's permissions, rather than replacing
> them,
> appears unpythonic to me. Python, consistently, requires such accumulation
> in
> inheritence to be explicit.
>
> So, I think I would go with Tim's first suggestion. It means that, if
> BaseTask
> is concrete, then, indeed, its subclasses might need some boilerplate. Note
> that such boilerplate may be reduced  by other means -- e.g. defining a
> base-
> class for all the Meta's as an independent, non-nested class. At least in
> principle, you could even give this base-Meta a metaclass that will
> implement
> the unpythonic accumulating-instead-of-overriding 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-
> table-inheritance
>
> On Tuesday 02 February 2016 15:52:19 Sergei Maertens wrote:
> > 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):
> > ...
> > class Meta:
> >permissions = (
> >('view_%(class)s', 'Can view %(class)s'),
> >)
> >
> > will make those permissions specific for any child classes:
> >
> > class TodoTask(BaseTask):
> > pass
> >
> >
> > class AssignedTask(BaseTask):
> > assignee = models.ForeignKey(settings.AUTH_USER_MODEL)
> >
> > class Meta:
> > permissions = (
> > ('reassign_assignedtask', 'Can reassign assigned task')
> > )
> >
> >
> >
> >
> > With the current patch, TodoTask would have one extra permission:
> > view_todotask, and AssignedTask would have two: view_assignedtask and
> > reassign_assignedtask.
> >
> > Now there were some concerns on the pull request, and input is needed:
> >
> >
> >- in its current state, Django will not inherit the base class
> >permissions, so AssignedTask would end up only with the
> >reassign_assignedtask permission (so missing view_assignedtask). The
> > patch ensures that inheritance is applied, and adds an extra Meta option:
> > inherit_permissions. Setting that to False yields the current behaviour -
> > no base class permissions are inherited. Disadvantages of this approach:
> -
> > yet another Meta attribute
> >   - more tight coupling between Meta and django.contrib.permissions
> >   (pointed out by Tim Graham)
> >   - 'hidden' second feature within the initial enhancee
> >
> > Two alternatives to avoid having to add inherit_permisisons have been
> > proposed by Tim:
> >
> > class AssignedTask(BaseTask):
> > assignee = models.ForeignKey(settings.AUTH_USER_MODEL)
> >
> > class Meta:
> > permissions = BaseTask.Meta.permissions + (
> > ('reassign_assignedtask', 'Can reassign assigned task')
> > )
> >
> > It looks like the inheritance of permissions would not be a default then,
> > which would require the other model to be changed to:
> >
> > class TodoTask(BaseTask):
> > class Meta:
> > permissions = BaseTask.Meta.permissions
> >
> >
> > In my opinition this introduces boilerplate which you get for free if the
> > permissions are inherited by default. On the upside, it is more explicit.
> >
> > Another suggestion was to use good old fashioned Python inheritance:
> >
> > class TodoTask(BaseTask):
> > class Meta(BaseTask.Meta):
> >pass
> >
> >
> > class AssignedTask(BaseTask):
> > assignee = models.ForeignKey(settings.AUTH_USER_MODEL)
> >
> > class Meta(BaseTask.Meta):
> > permissions = (
> > ('reassign_assignedtask', 'Can reassign ass

Re: Links from django docs to djangopackages.com should be 'officially endorsed' or not?

[Sergei Maertens]

My main concern is that it might appear that Django officially endorses the 
website, and that it might not be clear to developers that Django isn't 
directly involved with all those third party packages - which could be 
potentially harmful.

I'm also think that if you start linking to a grid for pagination, that you 
should do so for alternative form libraries, template engines, maybe even 
ORM-stuff if that exists. Basically for every (small or big) component that 
Django offers. Markus explained it better by using the term 'scattered all 
over the documentation'.

I would have no problems with a page/section in the docs where libraries or 
resources like djangopackages.com are linked, centralized in a single 
place. You lose the relevance on the subject at hand though.

DRF links to extensions, where I assume that Tom has checked all of them 
and deemed them worthy. It links to a known set of packages, and to me it 
seems that Tom officially endorses them and finds the quality sufficicient. 
That's something you don't get with a link to a grid comparison where the 
content can change multiple time per day.

On Monday, February 1, 2016 at 12:06:23 PM UTC+1, Federico Capoano wrote:
>
> It seems like a good proposal, It would be good to know why Sergei doesn't 
> think it is appropiate for Django to add links to third party package 
> comparison grids.
>
> django-rest-framework links to third party extensions in its documentation 
> and this had a positive effect on the whole DRF ecosystem.
>
> Federico
>
>
> On Monday, February 1, 2016 at 10:39:44 AM UTC+1, guettli wrote:
>>
>> This ticket was closed as invalid: 
>> https://code.djangoproject.com/ticket/26159
>>
>> {{{
>>
>> Here 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 :-)
>> }}}
>>
>>
>> {{{
>> sergei-maertens
>>
>> Resolution set to invalid
>> Status changed from new to closed
>>
>> I don't think the docs are the appropriate place to point out 
>> alternatives. I feel if Django starts going down that road, then you should 
>> do the same not only for pagination, but for forms, views, other db 
>> adapters, other template engines... I think it's a slippery slope.
>>
>> While I think that djangopackages.com is a great resource, I'm not sure 
>> if it (and no other resources) should be 'officially endorsed' by Django in 
>> the docs.
>> }}}
>>
>> I think a lot of time gets wasted by re-inventing stuff. Yes, programmers 
>> love to program. But time have
>> changed. There are a lot of great re-usable apps and libraries and 
>> programmers who wants to
>> get things done use them.
>>
>> What do you think for *this* issue: the docs for pagination should point 
>> to the comparison grid or not?
>>
>> Regards,
>>   Thomas Güttler
>>
>>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/c00ea768-7559-4145-9ec5-a49c1bec6f39%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

#10686 - inheritance of extra permissions from base class to child class

[Sergei Maertens]

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):
...
class Meta:
   permissions = (
   ('view_%(class)s', 'Can view %(class)s'),
   )

will make those permissions specific for any child classes:

class TodoTask(BaseTask):
pass


class AssignedTask(BaseTask):
assignee = models.ForeignKey(settings.AUTH_USER_MODEL)

class Meta:
permissions = (
('reassign_assignedtask', 'Can reassign assigned task')
)

 


With the current patch, TodoTask would have one extra permission: 
view_todotask, and AssignedTask would have two: view_assignedtask and 
reassign_assignedtask.

Now there were some concerns on the pull request, and input is needed:


   - in its current state, Django will not inherit the base class 
   permissions, so AssignedTask would end up only with the 
   reassign_assignedtask permission (so missing view_assignedtask). The patch 
   ensures that inheritance is applied, and adds an extra Meta option: 
   inherit_permissions. Setting that to False yields the current behaviour - 
   no base class permissions are inherited. Disadvantages of this approach:
  - yet another Meta attribute
  - more tight coupling between Meta and django.contrib.permissions 
  (pointed out by Tim Graham)
  - 'hidden' second feature within the initial enhancee
   
Two alternatives to avoid having to add inherit_permisisons have been 
proposed by Tim:

class AssignedTask(BaseTask):
assignee = models.ForeignKey(settings.AUTH_USER_MODEL)

class Meta:
permissions = BaseTask.Meta.permissions + (
('reassign_assignedtask', 'Can reassign assigned task')
)

It looks like the inheritance of permissions would not be a default then, 
which would require the other model to be changed to:

class TodoTask(BaseTask):
class Meta:
permissions = BaseTask.Meta.permissions


In my opinition this introduces boilerplate which you get for free if the 
permissions are inherited by default. On the upside, it is more explicit.

Another suggestion was to use good old fashioned Python inheritance:

class TodoTask(BaseTask):
class Meta(BaseTask.Meta):
   pass


class AssignedTask(BaseTask):
assignee = models.ForeignKey(settings.AUTH_USER_MODEL)

class Meta(BaseTask.Meta):
permissions = ( 
('reassign_assignedtask', 'Can reassign assigned task')
)


The latter two suggestions would ofcourse require fixing the patch, but 
that's an implementation detail.

Input would be greatly valued.

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/646d7295-5183-42b1-be32-30967794b051%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Form field labels change proposal

[Sergei Maertens]

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 if they do 
anything special with decapitalizing/capitalizing things, but all seems to 
be well. Django injects the form css in the block extrastyle within 
change_form.html. For Grappelli/django-xadmin that block is present, but 
Grappelli overrides change_form.html, so that would probably need updating. 
I haven't looked at any other admin-theme packages, but the change would be 
trivial for them as well - providing a proper documentation notion.

The only things so far I'm not really sure of are:

   - Is deprecation required or not (input needed from other core devs I 
   presume)
   - what with the validation error messages: as it stands, field labels 
   are capitalized at the moment, and they're not in a  tag. Examples 
   can be found 
   in: django.db.models.base.Model.(date_error_message|unique_error_message)

In the tests I also noticed that there are cases where the label itself is 
not wrapped in a  tag 
(django.tests.forms_tests.tests.test_forms.FormsTestCase.test_templates_with_forms).

On Friday, November 20, 2015 at 8:31:55 PM UTC+1, Tim Graham wrote:
>
> Looks easy enough. I was going to write, "Seems to me that there's more 
> complexity in a deprecation path that requires a temporary opt-in setting 
> rather than simply making the backwards incompatible change. Unless I 
> missed something, adding CSS like that shouldn't cause problems for any 
> apps maintaining compatibility with older versions of Django." but then I 
> thought of a different case where it could be trickier to upgrade: 
> developers who are specifying label='lower string' in some places to 
> workaround the current behavior (but still want uppercased labels 
> everywhere else). I guess the solution would be to use the text-transform 
> rule you mentioned and another CSS rule targeting all labels IDs that you 
> want to remain lowercased.
>
> I'd like other opinions about whether or not a deprecation seems helpful 
> for this. Personally, I'd rather just fix my CSS when upgrading rather than 
> fix my CSS *and* add a setting for a few Django versions to silence the 
> deprecation. I guess some people might like a few Django versions to update 
> their CSS though (also we promised to try to provide fairly seamless 
> upgrades from one LTS to the next).
>
> On Friday, November 20, 2015 at 11:38:53 AM UTC-5, Sergei Maertens wrote:
>>
>> In 
>> https://github.com/django/django/blob/master/django/contrib/admin/static/admin/css/forms.css#L31
>>  
>> <https://www.google.com/url?q=https%3A%2F%2Fgithub.com%2Fdjango%2Fdjango%2Fblob%2Fmaster%2Fdjango%2Fcontrib%2Fadmin%2Fstatic%2Fadmin%2Fcss%2Fforms.css%23L31=D=1=AFQjCNHYsYTv4mQblNJ7FiR_9EjUyq28oA>,
>>  
>> after
>> label {
>>font-weight: normal;
>>color:#666;
>>font-size:13px;
>> }
>>
>> you would add
>> label::first-letter {
>>text-transform: capitalize;
>> }
>>
>> (see https://css-tricks.com/almanac/selectors/f/first-letter/)
>>
>> text-transform: capitalize on the label itself would capitalize all 
>> words, which is not wanted. The ::first-letter pseudo-selector is supported 
>> on all browsers, for IE 8 and lower you need a sigle colon instead of a 
>> double colon.
>>
>>
>> On Thursday, November 19, 2015 at 11:23:48 PM UTC+1, Tim Graham wrote:
>>>
>>> I'd like to see the admin's CSS updated under the assumption that this 
>>> change moves forward to better understand the extent of changes that would 
>>> be required from Django users to maintain the current behavior.
>>>
>>> On Thursday, November 19, 2015 at 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 
>>>> that's probably the best way to tackle this.
>>>>
>>>> I'd be happy to write the patch for this myself if no objections turn 
>>>> up.
>>>>
>>>> On Thursday, November 19, 2015 at 10:49:49 PM UTC+1, Tim Graham wrote:
>>>>>
>>>>> The best solution I can think of at the moment would be a setting 
>>>>> allowing users to opt-in to the new behavior which would then silence the 
>>>>> warning. 

Re: Form field labels change proposal

[Sergei Maertens]

In 
https://github.com/django/django/blob/master/django/contrib/admin/static/admin/css/forms.css#L31,
 
after
label {
   font-weight: normal;
   color:#666;
   font-size:13px;
}

you would add
label::first-letter {
   text-transform: capitalize;
}

(see https://css-tricks.com/almanac/selectors/f/first-letter/)

text-transform: capitalize on the label itself would capitalize all words, 
which is not wanted. The ::first-letter pseudo-selector is supported on all 
browsers, for IE 8 and lower you need a sigle colon instead of a double 
colon.


On Thursday, November 19, 2015 at 11:23:48 PM UTC+1, Tim Graham wrote:
>
> I'd like to see the admin's CSS updated under the assumption that this 
> change moves forward to better understand the extent of changes that would 
> be required from Django users to maintain the current behavior.
>
> On Thursday, November 19, 2015 at 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 
>> that's probably the best way to tackle this.
>>
>> I'd be happy to write the patch for this myself if no objections turn up.
>>
>> On Thursday, November 19, 2015 at 10:49:49 PM UTC+1, Tim Graham wrote:
>>>
>>> The best solution I can think of at the moment would be a setting 
>>> allowing users to opt-in to the new behavior which would then silence the 
>>> warning. That 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.
>>>>
>>>> I'm not sure, haven't there been similar cases in the past? First thing 
>>>> I can think of is using naive datetimes when timezone-support is enabled, 
>>>> and then you get a warning for each naive datetime you use, but that's of 
>>>> course different then a DeprecationWarning.
>>>>
>>>> It's probably not best practice, but maybe it could be tracked with a 
>>>> module-level flag/constant, to check if the warning has been emited or 
>>>> not, 
>>>> ensuring that it gets only emited once during the lifetime of a thread?
>>>>
>>>> On Thursday, November 19, 2015 at 7:27:18 PM UTC+1, Tim Graham wrote:
>>>>>
>>>>> How would a developer 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 would start with locally creating a wrapper capfirst that 
>>>>>> is only called in the referenced line and 
>>>>>> https://github.com/django/django/blob/master/django/db/models/fields/__init__.py#L2069
>>>>>>  
>>>>>> (missed that one in the previous post) and possible other ocurrences. 
>>>>>> Emit 
>>>>>> a PendingDeprecationWarning, something along the lines of
>>>>>>
>>>>>> def deprecated_capfirst(value):
>>>>>> warnings.warn(
>>>>>> "form field labels generated from model field 'verbose_name' 
>>>>>> will no longer automatically be capitalized",
>>>>>> PendingDeprecationWarning, stacklevel=2
>>>>>> )
>>>>>> return capfirst(value)
>>>>>>
>>>>>> and replace the capfirst with deprecated_capfirst ofcourse. At the 
>>>>>> same time, in the admin the CSS for labels can be added to 
>>>>>> text-transform 
>>>>>> them to capitalize.
>>>>>>
>>>>>> In the next Django version this becomes loud, and in the next+1 
>>>>>> version it is effectively removed.
>>>>>>
>>>>>> As soon as the PendingDeprecation is added, the entry should be added 
>>>>>> to the docs with example CSS to make your own templates/styling 
>>>>>> capitalize 
>>>>>> the labels - and/or mention the `capfirst` template filter.
>>>>>>
>>>>>

Re: Form field labels change proposal

[Sergei Maertens]

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 
that's probably the best way to tackle this.

I'd be happy to write the patch for this myself if no objections turn up.

On Thursday, November 19, 2015 at 10:49:49 PM UTC+1, Tim Graham wrote:
>
> The best solution I can think of at the moment would be a setting allowing 
> users to opt-in to the new behavior which would then silence the warning. 
> That 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.
>>
>> I'm not sure, haven't there been similar cases in the past? First thing I 
>> can think of is using naive datetimes when timezone-support is enabled, and 
>> then you get a warning for each naive datetime you use, but that's of 
>> course different then a DeprecationWarning.
>>
>> It's probably not best practice, but maybe it could be tracked with a 
>> module-level flag/constant, to check if the warning has been emited or not, 
>> ensuring that it gets only emited once during the lifetime of a thread?
>>
>> On Thursday, November 19, 2015 at 7:27:18 PM UTC+1, Tim Graham wrote:
>>>
>>> How would a developer 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 would start with locally creating a wrapper capfirst that is 
>>>> only called in the referenced line and 
>>>> https://github.com/django/django/blob/master/django/db/models/fields/__init__.py#L2069
>>>>  
>>>> (missed that one in the previous post) and possible other ocurrences. Emit 
>>>> a PendingDeprecationWarning, something along the lines of
>>>>
>>>> def deprecated_capfirst(value):
>>>> warnings.warn(
>>>> "form field labels generated from model field 'verbose_name' 
>>>> will no longer automatically be capitalized",
>>>> PendingDeprecationWarning, stacklevel=2
>>>> )
>>>> return capfirst(value)
>>>>
>>>> and replace the capfirst with deprecated_capfirst ofcourse. At the same 
>>>> time, in the admin the CSS for labels can be added to text-transform them 
>>>> to capitalize.
>>>>
>>>> In the next Django version this becomes loud, and in the next+1 version 
>>>> it is effectively removed.
>>>>
>>>> As soon as the PendingDeprecation is added, the entry should be added 
>>>> to the docs with example CSS to make your own templates/styling capitalize 
>>>> the labels - and/or mention the `capfirst` template filter.
>>>>
>>>> Thoughts?
>>>>
>>>>
>>>> On Wednesday, November 11, 2015 at 5:32:57 PM UTC+1, Tim Graham wrote:
>>>>>
>>>>> How do you envision putting 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 
>>>>>> https://github.com/django/django/blob/master/django/db/models/fields/__init__.py#L872
>>>>>>  
>>>>>> <https://www.google.com/url?q=https%3A%2F%2Fgithub.com%2Fdjango%2Fdjango%2Fblob%2Fmaster%2Fdjango%2Fdb%2Fmodels%2Ffields%2F__init__.py%23L872=D=1=AFQjCNGUcFeQthwsqiwrA57fw50I20lHtw>).
>>>>>>  
>>>>>> This behaviour has been around since pretty much forever and makes sense.
>>>>>>
>>>>>> However, this affects what you put down in your translations - if a 
>>>>>> lowercased verbose name is what you want (and you translate it as such), 
>>>>>> Django will make your form labels uppercase and there's no clean way 
>>>>>> around 
>>>>>> that.
>>>>>>
>>>>>> There is 

Re: Form field labels change proposal

[Sergei Maertens]

Good catch.

I'm not sure, haven't there been similar cases in the past? First thing I 
can think of is using naive datetimes when timezone-support is enabled, and 
then you get a warning for each naive datetime you use, but that's of 
course different then a DeprecationWarning.

It's probably not best practice, but maybe it could be tracked with a 
module-level flag/constant, to check if the warning has been emited or not, 
ensuring that it gets only emited once during the lifetime of a thread?

On Thursday, November 19, 2015 at 7:27:18 PM UTC+1, Tim Graham wrote:
>
> How would a developer 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 would start with locally creating a wrapper capfirst that is 
>> only called in the referenced line and 
>> https://github.com/django/django/blob/master/django/db/models/fields/__init__.py#L2069
>>  
>> (missed that one in the previous post) and possible other ocurrences. Emit 
>> a PendingDeprecationWarning, something along the lines of
>>
>> def deprecated_capfirst(value):
>> warnings.warn(
>> "form field labels generated from model field 'verbose_name' will 
>> no longer automatically be capitalized",
>> PendingDeprecationWarning, stacklevel=2
>> )
>> return capfirst(value)
>>
>> and replace the capfirst with deprecated_capfirst ofcourse. At the same 
>> time, in the admin the CSS for labels can be added to text-transform them 
>> to capitalize.
>>
>> In the next Django version this becomes loud, and in the next+1 version 
>> it is effectively removed.
>>
>> As soon as the PendingDeprecation is added, the entry should be added to 
>> the docs with example CSS to make your own templates/styling capitalize the 
>> labels - and/or mention the `capfirst` template filter.
>>
>> Thoughts?
>>
>>
>> On Wednesday, November 11, 2015 at 5:32:57 PM UTC+1, Tim Graham wrote:
>>>
>>> How do you envision putting 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 
>>>> https://github.com/django/django/blob/master/django/db/models/fields/__init__.py#L872
>>>>  
>>>> <https://www.google.com/url?q=https%3A%2F%2Fgithub.com%2Fdjango%2Fdjango%2Fblob%2Fmaster%2Fdjango%2Fdb%2Fmodels%2Ffields%2F__init__.py%23L872=D=1=AFQjCNGUcFeQthwsqiwrA57fw50I20lHtw>).
>>>>  
>>>> This behaviour has been around since pretty much forever and makes sense.
>>>>
>>>> However, this affects what you put down in your translations - if a 
>>>> lowercased verbose name is what you want (and you translate it as such), 
>>>> Django will make your form labels uppercase and there's no clean way 
>>>> around 
>>>> that.
>>>>
>>>> There is a very specific use case for this proposal. The house-style of 
>>>> a design states that all form labels should be lowercase - but names of 
>>>> the 
>>>> brand should be capitalized. Example: 'you agree to the Brand terms'. This 
>>>> is not easily feasible: css text-transform will also lowercase the brand 
>>>> name, and Django uppercases the first letter. Another possible use case 
>>>> could be if you insist on putting the labels to the right of the form 
>>>> input, but I will agree that looks silly.
>>>>
>>>> So the proposal is to get rid of the capfirst call, and in the admin 
>>>> this could be mitigated for backwards compatibility by modifying the css 
>>>> to 
>>>> include:
>>>> label {
>>>> text-transform: capitalize;
>>>> }
>>>>
>>>> This is ofcourse a fairly big backwards-incompatible change towards 
>>>> front-end/non-vendor code, as people now have to explicitly make sure that 
>>>> labels are capitalized in their own templates. So this should probably go 
>>>> through the usual deprecation mechanics (silent, warning, remove), if it 
>>>> happens at all.
>>>>
>>>> What are current workarounds for this problem?
>>>>
>>>>- ex

Re: Form field labels change proposal

[Sergei Maertens]

I think I would start with locally creating a wrapper capfirst that is only 
called in the referenced line 
and 
https://github.com/django/django/blob/master/django/db/models/fields/__init__.py#L2069
 
(missed that one in the previous post) and possible other ocurrences. Emit 
a PendingDeprecationWarning, something along the lines of

def deprecated_capfirst(value):
warnings.warn(
"form field labels generated from model field 'verbose_name' will 
no longer automatically be capitalized",
PendingDeprecationWarning, stacklevel=2
)
return capfirst(value)

and replace the capfirst with deprecated_capfirst ofcourse. At the same 
time, in the admin the CSS for labels can be added to text-transform them 
to capitalize.

In the next Django version this becomes loud, and in the next+1 version it 
is effectively removed.

As soon as the PendingDeprecation is added, the entry should be added to 
the docs with example CSS to make your own templates/styling capitalize the 
labels - and/or mention the `capfirst` template filter.

Thoughts?


On Wednesday, November 11, 2015 at 5:32:57 PM UTC+1, Tim Graham wrote:
>
> How do you envision putting 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 
>> https://github.com/django/django/blob/master/django/db/models/fields/__init__.py#L872
>>  
>> <https://www.google.com/url?q=https%3A%2F%2Fgithub.com%2Fdjango%2Fdjango%2Fblob%2Fmaster%2Fdjango%2Fdb%2Fmodels%2Ffields%2F__init__.py%23L872=D=1=AFQjCNGUcFeQthwsqiwrA57fw50I20lHtw>).
>>  
>> This behaviour has been around since pretty much forever and makes sense.
>>
>> However, this affects what you put down in your translations - if a 
>> lowercased verbose name is what you want (and you translate it as such), 
>> Django will make your form labels uppercase and there's no clean way around 
>> that.
>>
>> There is a very specific use case for this proposal. The house-style of a 
>> design states that all form labels should be lowercase - but names of the 
>> brand should be capitalized. Example: 'you agree to the Brand terms'. This 
>> is not easily feasible: css text-transform will also lowercase the brand 
>> name, and Django uppercases the first letter. Another possible use case 
>> could be if you insist on putting the labels to the right of the form 
>> input, but I will agree that looks silly.
>>
>> So the proposal is to get rid of the capfirst call, and in the admin this 
>> could be mitigated for backwards compatibility by modifying the css to 
>> include:
>> label {
>> text-transform: capitalize;
>> }
>>
>> This is ofcourse a fairly big backwards-incompatible change towards 
>> front-end/non-vendor code, as people now have to explicitly make sure that 
>> labels are capitalized in their own templates. So this should probably go 
>> through the usual deprecation mechanics (silent, warning, remove), if it 
>> happens at all.
>>
>> What are current workarounds for this problem?
>>
>>- explicitly specifying the label value in the ModelForm definition: 
>>this violates the DRY principle, you already defined the verbose_name on 
>>the model field
>>- creating a form mixin that will lowercase the first letter of the 
>>label for all fields
>>   - you still have to check if the first word if it's the Brand 
>>   string, because then it should stay capitalized
>>   - you now have to include this mixin in every single form, and can 
>>   no longer rely on implicitly generated form classes in generic CBV
>>- create a templatefilter that decapitalizes the label, and 
>>re-capitalizes 'brand' occurrences to 'Brand' (currently implemented)
>>   - you now have to not forget this filter everywhere you render 
>>   forms
>>   - performance hit if this is based on regular expressions (which 
>>   in this case it is because subbrand should not become subBrand)
>>
>> All in all, I'm of the opinion that the flexibility you gain by NOT 
>> manipulating the label in Django outweighs the backwards incompatible 
>> change. I'm also strongly of the opinion that capitalizing labels is 
>> something that should be done entirely in CSS - whether the label is 
>> capitalized, lower case or upper case shouldn't matter for Django's 
>> internals.
>>
>> Reasons to not do this:
>>
>>- cater to common convention, not clien

Form field labels change proposal

[Sergei Maertens]

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 and makes sense.

However, this affects what you put down in your translations - if a 
lowercased verbose name is what you want (and you translate it as such), 
Django will make your form labels uppercase and there's no clean way around 
that.

There is a very specific use case for this proposal. The house-style of a 
design states that all form labels should be lowercase - but names of the 
brand should be capitalized. Example: 'you agree to the Brand terms'. This 
is not easily feasible: css text-transform will also lowercase the brand 
name, and Django uppercases the first letter. Another possible use case 
could be if you insist on putting the labels to the right of the form 
input, but I will agree that looks silly.

So the proposal is to get rid of the capfirst call, and in the admin this 
could be mitigated for backwards compatibility by modifying the css to 
include:
label {
text-transform: capitalize;
}

This is ofcourse a fairly big backwards-incompatible change towards 
front-end/non-vendor code, as people now have to explicitly make sure that 
labels are capitalized in their own templates. So this should probably go 
through the usual deprecation mechanics (silent, warning, remove), if it 
happens at all.

What are current workarounds for this problem?

   - explicitly specifying the label value in the ModelForm definition: 
   this violates the DRY principle, you already defined the verbose_name on 
   the model field
   - creating a form mixin that will lowercase the first letter of the 
   label for all fields
  - you still have to check if the first word if it's the Brand string, 
  because then it should stay capitalized
  - you now have to include this mixin in every single form, and can no 
  longer rely on implicitly generated form classes in generic CBV
   - create a templatefilter that decapitalizes the label, and 
   re-capitalizes 'brand' occurrences to 'Brand' (currently implemented)
  - you now have to not forget this filter everywhere you render forms
  - performance hit if this is based on regular expressions (which in 
  this case it is because subbrand should not become subBrand)
   
All in all, I'm of the opinion that the flexibility you gain by NOT 
manipulating the label in Django outweighs the backwards incompatible 
change. I'm also strongly of the opinion that capitalizing labels is 
something that should be done entirely in CSS - whether the label is 
capitalized, lower case or upper case shouldn't matter for Django's 
internals.

Reasons to not do this:

   - cater to common convention, not clients (quoted from #django-dev on 
   irc): in my opinion this works 95% of the time, but your forced into 
   violating some of Django's principles if you divert from this, most notably 
   DRY
   - maintain backwards compatibility

Reasons to do this:

   - gain flexibility about the display of form labels
   - keep the codebase sane


Bonus: vaguely related ticket: https://code.djangoproject.com/ticket/5518

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/567142d7-0da1-49ed-9994-a43a834af551%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: (Model)formsets, passing custom kwargs to form and _construct_form

[Sergei Maertens]

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 common pattern for 
> this is implementing a custom BaseMyModelFormSet(BaseModelFormSet), 
> overriding __init__ and then passing the custom argument via 
> _construct_form, hereby overriding/extending a private method.
>
> Would it be a good idea to add a form_kwargs attribute on the BaseFormSet 
> class, and pass those arguments by default within _construct_form? This 
> would reduce code verbosity so that you only need to set form_kwargs, 
> either on class definition of the custom BaseFormSet, or dynamically in the 
> custom formset class' __init__. This would prevent overriding a private 
> method.
>
> An alternative approach is using functools' partial/curry, but apparently 
> this may cause trouble with the order of arguments and passing dynamic 
> values (such as request.user).
>
> I'd love to hear any feedback on this, if other people like it I might 
> give the implementation a go on the Djangocon EU sprint.
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/33696654-3af3-4bee-a20a-39589177daf1%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

(Model)formsets, passing custom kwargs to form and _construct_form

[Sergei Maertens]

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 
_construct_form, hereby overriding/extending a private method.

Would it be a good idea to add a form_kwargs attribute on the BaseFormSet 
class, and pass those arguments by default within _construct_form? This 
would reduce code verbosity so that you only need to set form_kwargs, 
either on class definition of the custom BaseFormSet, or dynamically in the 
custom formset class' __init__. This would prevent overriding a private 
method.

An alternative approach is using functools' partial/curry, but apparently 
this may cause trouble with the order of arguments and passing dynamic 
values (such as request.user).

I'd love to hear any feedback on this, if other people like it I might give 
the implementation a go on the Djangocon EU sprint.

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/8011c21f-8384-4ef7-93bf-1e1f01769d47%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.