Re: Methodology for increasing the number of PBKDF2 iterations

[Martin Koistinen]

The Python3.5 on my system was installed by the official Python installer, 
and is almost 3X slower than the Apple-built 2.7 install. I use pip all day 
long.

True, my MacBook is not a server, but it still serves to demonstrate the 
point that it is not a reasonable assumption that all 3.5 installs use 
OpenSSL libraries.

On Monday, January 9, 2017 at 7:39:18 PM UTC-5, Tim Graham wrote:
>
> About "we cannot just assume that all Python 3 installs have a "fast" 
> PBKDF2 implementation" -- I'd expect very few if any Django users to be 
> compiling their own Python and doing so without OpenSSL. I'm guessing that 
> any operating system Python will have the OpenSSL bindings. Or is that a 
> bad assumption?
>
> On Wednesday, January 4, 2017 at 2:13:09 PM UTC-5, Martin Koistinen wrote:
>>
>> I think this is a pretty solid guess. Bear in mind this was a direct 
>> install from Python.org.
>>
>> The important thing here is, this demonstrates that we cannot just assume 
>> that all Python 3 installs have a "fast" PBKDF2 implementation =/
>>
>> On Wednesday, January 4, 2017 at 11:33:17 AM UTC-5, Tobias McNulty wrote:
>>
>>> ... 
>>>
>> Martin, is it possible your version of Python 3 is not linked against 
>>> OpenSSL and hence is missing the fast version of pbkdf2_hmac? I haven't had 
>>> a chance to try your benchmark yet, but in a quick test I don't see any 
>>> difference between Python 3.5.2 and Python 2.7.12 on a Mac.
>>>
>>> Tobias
>>>
>>
>>  
>>
>

-- 
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/9261dcdc-f3b2-458c-a6e1-bde49642c56b%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Methodology for increasing the number of PBKDF2 iterations

[Alex Gaynor]

That's a correct assumption -- you won't be able to use pip without OpenSSL.

Alex

On Mon, Jan 9, 2017 at 7:39 PM, Tim Graham  wrote:

> About "we cannot just assume that all Python 3 installs have a "fast"
> PBKDF2 implementation" -- I'd expect very few if any Django users to be
> compiling their own Python and doing so without OpenSSL. I'm guessing that
> any operating system Python will have the OpenSSL bindings. Or is that a
> bad assumption?
>
> On Wednesday, January 4, 2017 at 2:13:09 PM UTC-5, Martin Koistinen wrote:
>>
>> I think this is a pretty solid guess. Bear in mind this was a direct
>> install from Python.org.
>>
>> The important thing here is, this demonstrates that we cannot just assume
>> that all Python 3 installs have a "fast" PBKDF2 implementation =/
>>
>> On Wednesday, January 4, 2017 at 11:33:17 AM UTC-5, Tobias McNulty wrote:
>>
>>> ...
>>>
>> Martin, is it possible your version of Python 3 is not linked against
>>> OpenSSL and hence is missing the fast version of pbkdf2_hmac? I haven't had
>>> a chance to try your benchmark yet, but in a quick test I don't see any
>>> difference between Python 3.5.2 and Python 2.7.12 on a Mac.
>>>
>>> Tobias
>>>
>>
>>
>>
> --
> 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/1cac9870-7cc7-4392-ab98-
> 08c0420b64ff%40googlegroups.com
> 
> .
>
> For more options, visit https://groups.google.com/d/optout.
>



-- 
"I disapprove of what you say, but I will defend to the death your right to
say it." -- Evelyn Beatrice Hall (summarizing Voltaire)
"The people's good is the highest law." -- Cicero
GPG Key fingerprint: D1B3 ADC0 E023 8CA6

-- 
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/CAFRnB2XofrO0WwObgEU0r9BqaSNAtftoTwCmsrO89S%2BUPmbZ3w%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Methodology for increasing the number of PBKDF2 iterations

[Tim Graham]

About "we cannot just assume that all Python 3 installs have a "fast" 
PBKDF2 implementation" -- I'd expect very few if any Django users to be 
compiling their own Python and doing so without OpenSSL. I'm guessing that 
any operating system Python will have the OpenSSL bindings. Or is that a 
bad assumption?

On Wednesday, January 4, 2017 at 2:13:09 PM UTC-5, Martin Koistinen wrote:
>
> I think this is a pretty solid guess. Bear in mind this was a direct 
> install from Python.org.
>
> The important thing here is, this demonstrates that we cannot just assume 
> that all Python 3 installs have a "fast" PBKDF2 implementation =/
>
> On Wednesday, January 4, 2017 at 11:33:17 AM UTC-5, Tobias McNulty wrote:
>
>> ... 
>>
> Martin, is it possible your version of Python 3 is not linked against 
>> OpenSSL and hence is missing the fast version of pbkdf2_hmac? I haven't had 
>> a chance to try your benchmark yet, but in a quick test I don't see any 
>> difference between Python 3.5.2 and Python 2.7.12 on a Mac.
>>
>> Tobias
>>
>
>  
>

-- 
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/1cac9870-7cc7-4392-ab98-08c0420b64ff%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Presenting DCP, a compatibility layer for Django (feedback welcome)

[Tim Graham]

Our new deprecation policy was designed to eliminate the need for this type 
of compatibility library. If you want to support more Django versions than 
what our guidelines recommend (which may involve supporting versions that 
no longer receive security updates), I guess this library could be useful, 
but I wouldn't give it an endorsement in the Django docs.

Perhaps you could elaborate on "Most importantly, this way, django main 
tests suites  would stop making asserts on the presence or absence of 
deprecation warnings (which is a way of mixing unrelated aspects of the 
framework)." I don't understand your complaint about the current way we're 
testing deprecation warnings.

On Saturday, January 7, 2017 at 3:17:06 PM UTC-5, Pkl wrote:
>
>
> Hello,
>
> I've *at last* had some time to experiment with the idea I had thrown 
> years again, of a system to workaround the recurring breakages introduced 
> by new django releases, breakages which sometimes lead to unreconcilable 
> requirements between django apps.
>
> After a sprint at PyconFR, with a colleague (R. Gomès), and some cleanups 
> and improvements, here it is:
>
> https://github.com/pakal/django-compat-patcher  (also known as DCP)
> https://pypi.python.org/pypi/django-compat-patcher
>
> The philosophy of the module is that, with extremly agile languages such 
> as python, one doesn't have to choose between a fast-moving project, and a 
> compatibility-friendly project.
> So, in an approach reminding "aspect oriented programming", DCP separates 
> the Django codebase, which may move forward and be left mostly free of 
> compatibility shims, from retrocompatibility shims ; and changing the 
> "level of compatibility" of a project is just the matter of tweaking some 
> Django settings.
> Since, as usual, "explicit is better than implicit", logging and code 
> warnings are used to ensure that project users are informed about what 
> compatibility fixers are applied, and how project dependencies are rated 
> deprecation-wise.
>
> I've noticed there had been debates and evolutions for the past years, 
> until the switch to a "lax semantic versioning" for Django. 
> Surely it's an effort in the right direction, but I guess I'm not the only 
> one worried by the "lax" adjective ; especially after the long history of 
> breakages occurring for quite cosmetic reasons (eg. the removal of 
> urlpatterns(), which broke most django apps available, whereas dotted-path 
> URLs were rather harmless).
> That's why I think DCP is still relevant, as it gives back some control 
> over compatibility to end users of Django ; and it should remove part of 
> the apprehension some may have known too, when installing a new Django 
> version.
>
> DCP has been successfully used to upgrade wide projects from django 1.7 to 
> django 1.10, with no hassle. But more feedback would be nice, before it can 
> be marked "production ready".
> The project welcomes patches, especially new backward/forward 
> compatibility fixers one might need.
>
>
> *Apart from that *: I think many people could benefit from more 
> instructions about how to handle (backwards and forwards) compatibility, so 
> here are some ideas I had :
>
>
> *1) Advertising compatibility systems for Django, in the official docs.*
>
> That is to say, packages like "django-compat" (which I only discovered 
> lately), dedicated to library developers who need a wide compatibility.
> And packages like "django-compat-patcher" for project maintainers who have 
> compatibility issues and deadlines (it's not *always* the right moment to 
> fork and patch a bunch of big dependencies).
> All that would come in addition to the docs now mentioning "how to support 
> 2 LTS versions at a time".
> These measures might diminish the number of django app using handmade 
> compatibility shims, or completely ignoring previous versions of django.
>
>
> *2) Pushing a compatibility system like DCP into Django itself*
>
> What would be the gain ? It would pleasantly reduce the work needed for 
> Django evolutions.
>
> At the moment, first compatibility shims must be introduced, and 
> specifically tested in code ; then these compatibility shims must be 
> removed, and their tests with them.
>
> With a separate compatibility system, only half the work would be needed : 
> once the code has been modified, the old version is moved to a fixer, and 
> its associated unit-test is moved to the compatibility system test suite. 
> The activation/deactivation of this particular fixer is then only a matter 
> of django settings, not of new code commits.
> Most importantly, this way, django main tests suites  would stop making 
> asserts on the presence or absence of deprecation warnings (which is a way 
> of mixing unrelated aspects of the framework). Django tests suites could 
> thus be leveraged by compatibility systems to ensure that the whole system 
> is well sane and backwards/forward compatible, whatever the series of 
> django shims applied.
>
>

Re: Removing aliased imports ("from") in generated migration files to prevent conflicts

[Adam Johnson]

There's a 6th way, which is to alias the probematic modules rather than
django's modules, e.g.

from django.db import models

import models as models_

...
Field(
default=models_.my_default
)
...

There's also a 7th way, which is to use flake8 which will, with its default
config, complain about duplicate imports. Django could possibly even hook
into flake8 and call it on generated migration files and warn the user
they're bad, although many people already run it as part of their toolchain.

But...

While the above names arguably aren't good choices for a module name


Is this a real world problem? The ticket doesn't report any real world
clash, it just says it's possible. This whole thing seems like a
maybe-possibly edge case, for applications with badly named modules that
would confuse day-to-day development anyway.

I'm -1 on option 3, absolute imports do indeed make generated migrations
harder to read and edit.

On 9 January 2017 at 22:06, Anthony King  wrote:

> There may be a 5th way, which would be to make an alias under the clash
> conditions.
>
> from django.db import models as django_models
>
> However this could also lead to mistakes in assume the django models would
> still be called models.
>
>
> On 9 Jan 2017 21:59, "Alexey Kotlyarov"  wrote:
>
> As stated in https://code.djangoproject.com/ticket/26099, it is possible
> for a project with an unfortunately named application to result in a
> migration file being generated which will raise an error on attempting to
> migrate, without any prior warning. The problem is that the following
> imports can all be generated:
>
> from django.db import migrations, models
> from django.conf import settings
> from django.utils.timezone import utc
>
> If an application module is named models, migrations, settings or utc and
> there is, for example, a function in one of those modules used for a
> default of a field, its module will be imported as is and shadow the Django
> import.
>
> While the above names arguably aren't good choices for a module name, they
> are valid, don't conflict with anything else within Django and the behavior
> isn't mentioned in the documentation.
>
> Here are several proposed solutions to the problem:
>
> 1. Mention the module names causing the bug to manifest in the
> documentation, keep the behavior. This isn't likely to help the affected
> users, and the name list must be kept in sync if new imports are added to
> the generated migrations.
>
> 2. Warn about the name clash, refuse to generate the migration and tell
> the user that they must rename a module. This might not be possible in case
> the offending name is from a third party library.
>
> 3. Generate the imports without aliasing them (e.g. import
> django.db.models) to make clashes impossible. This, however, makes the
> migration files harder to read to a human, as all the imported names, like
> Model and Migration, use full module names: django.db.models.Model,
> django.db.migrations.Migration.
>
> 4. Only generate the un-aliased imports if there is a module name clash.
>
> I have naively gone with option 3 and provided a patch (
> https://github.com/django/django/pull/7810), but Tim Graham pointed out
> that the deficiencies I was pondering too.
>
> What is the best way forward here? I have an understanding of what's
> needed to implement 4 and 2 (won't be much easier than 4) and can change
> the patch accordingly.
>
> Alexey
>
> --
> 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/ms
> gid/django-developers/daba352d-5e97-4d70-b61f-b42f9eb65ca5%
> 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-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/CALs0z1YzVLuvGixpm44ohzA9v6GcL
> yk_gAVh57szehoKMymkzQ%40mail.gmail.com
> 

Re: Removing aliased imports ("from") in generated migration files to prevent conflicts

[Anthony King]

There may be a 5th way, which would be to make an alias under the clash
conditions.

from django.db import models as django_models

However this could also lead to mistakes in assume the django models would
still be called models.


On 9 Jan 2017 21:59, "Alexey Kotlyarov"  wrote:

As stated in https://code.djangoproject.com/ticket/26099, it is possible
for a project with an unfortunately named application to result in a
migration file being generated which will raise an error on attempting to
migrate, without any prior warning. The problem is that the following
imports can all be generated:

from django.db import migrations, models
from django.conf import settings
from django.utils.timezone import utc

If an application module is named models, migrations, settings or utc and
there is, for example, a function in one of those modules used for a
default of a field, its module will be imported as is and shadow the Django
import.

While the above names arguably aren't good choices for a module name, they
are valid, don't conflict with anything else within Django and the behavior
isn't mentioned in the documentation.

Here are several proposed solutions to the problem:

1. Mention the module names causing the bug to manifest in the
documentation, keep the behavior. This isn't likely to help the affected
users, and the name list must be kept in sync if new imports are added to
the generated migrations.

2. Warn about the name clash, refuse to generate the migration and tell the
user that they must rename a module. This might not be possible in case the
offending name is from a third party library.

3. Generate the imports without aliasing them (e.g. import django.db.models)
to make clashes impossible. This, however, makes the migration files harder
to read to a human, as all the imported names, like Model and Migration,
use full module names: django.db.models.Model,
django.db.migrations.Migration.

4. Only generate the un-aliased imports if there is a module name clash.

I have naively gone with option 3 and provided a patch (
https://github.com/django/django/pull/7810), but Tim Graham pointed out
that the deficiencies I was pondering too.

What is the best way forward here? I have an understanding of what's needed
to implement 4 and 2 (won't be much easier than 4) and can change the patch
accordingly.

Alexey

-- 
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/daba352d-5e97-4d70-b61f-b42f9eb65ca5%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-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/CALs0z1YzVLuvGixpm44ohzA9v6GcLyk_gAVh57szehoKMymkzQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Removing aliased imports ("from") in generated migration files to prevent conflicts

[Alexey Kotlyarov]

As stated in https://code.djangoproject.com/ticket/26099, it is possible 
for a project with an unfortunately named application to result in a 
migration file being generated which will raise an error on attempting to 
migrate, without any prior warning. The problem is that the following 
imports can all be generated:

from django.db import migrations, models
from django.conf import settings
from django.utils.timezone import utc

If an application module is named models, migrations, settings or utc and 
there is, for example, a function in one of those modules used for a 
default of a field, its module will be imported as is and shadow the Django 
import.

While the above names arguably aren't good choices for a module name, they 
are valid, don't conflict with anything else within Django and the behavior 
isn't mentioned in the documentation.

Here are several proposed solutions to the problem:

1. Mention the module names causing the bug to manifest in the 
documentation, keep the behavior. This isn't likely to help the affected 
users, and the name list must be kept in sync if new imports are added to 
the generated migrations.

2. Warn about the name clash, refuse to generate the migration and tell the 
user that they must rename a module. This might not be possible in case the 
offending name is from a third party library.

3. Generate the imports without aliasing them (e.g. import django.db.models) 
to make clashes impossible. This, however, makes the migration files harder 
to read to a human, as all the imported names, like Model and Migration, 
use full module names: django.db.models.Model, 
django.db.migrations.Migration.

4. Only generate the un-aliased imports if there is a module name clash.

I have naively gone with option 3 and provided a patch (
https://github.com/django/django/pull/7810), but Tim Graham pointed out 
that the deficiencies I was pondering too.

What is the best way forward here? I have an understanding of what's needed 
to implement 4 and 2 (won't be much easier than 4) and can change the patch 
accordingly.

Alexey

-- 
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/daba352d-5e97-4d70-b61f-b42f9eb65ca5%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Feature request] Template language type annotations (#27703)

[Дмитрий Симонов]

Ok. Here is my example with multiline annotations.

https://github.com/a1fred/django-template-type-annotations

What do you think?

2017-01-09 19:03 GMT+03:00 Adam Johnson :

> I think a third party implementation could be done first for the separate
> tag. I also think you'd learn more and iterate faster by building some
> tooling on top of the tags whilst a third party app before merging with
> core was considered. One idea that springs to mind is allowing multiple
> type declarations in the same tag rather than requiring *"{% var " *written
> multiple times.
>
> On 9 January 2017 at 15:38, Дмитрий Симонов  wrote:
>
>> Hi guys.
>>
>> Lets discuss about this ticket
>> 
>>
>> I think we need create new tag in template language to annotate context
>> variable types. Something like PEP 484
>>  but on templates.
>> As in pep 484 main goal is provide easier static analysis, potential
>> error checking and improve IDEs and editors support.
>> We can do this with new small tag. Something like:
>>
>> @register.simpletag(name='var')
>> def type_hint(variable,variable_type_string: str) -> None:
>> pass
>>
>> Then we can annotate variable in template:
>>
>> {% var request 'django.http.HttpResponse' %} %}
>>
>> or
>>
>> {% var is_paginated 'bool' %}
>>
>> or
>>
>> {% var user_or_none 'typing.Union[None, django.contrib.auth.models.User]'
>> %}
>>
>> maybe
>>
>> {% var user_or_none 'typing.Union[None, django.conf.settings.AUTH_USER
>> _MODEL]' %}
>>
>>
>> Main idea is add this template to django default tags, not third part
>> application.
>> Then IDE, editor plugins, and analysis tools can build support, based on
>> this.
>>
>> Similar links:
>> https://blog.jetbrains.com/idea/2009/08/enabling-implicit-
>> context-variables-resolution-in-template-files/
>> https://weblogs.asp.net/scottgu/asp-net-mvc-3-new-model-
>> directive-support-in-razor
>>
>> English is not my mother tongue; please excuse any errors on my part.
>>
>> --
>> 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/ms
>> gid/django-developers/53df8783-7234-405e-a325-a8bed448cd35%
>> 40googlegroups.com
>> 
>> .
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>
>
> --
> Adam
>
> --
> 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/CAMyDDM2jxHm-PhD4VUQt%3DUbWeHV%3D51zKW%3Das9Kzc-
> Bqg4sCoZg%40mail.gmail.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-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/CAGWEbUi8N4MgVYrJdETL_pBTaphE0TLee_QmO8NrD9yzutOOnw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Allow extra blank rows for adding new records when using list_editable in admin change list view.

[Adonys]

This ticket #11574  is open 
from many years ago. I'm interested to contribute with this new feature 
but, if this ticket has a lot of time opened, and is very possible that 
there are some reservations and consideration about this feature. Before 
use time to build a solution, i think that will be useful discuss about 
this topic with the community.
Similar to `InlineModelAdmin`, I consider that this feature won't be useful 
for all models, is really useful for models with few fields. But, adding 
new records directly in the `changelist` would be util like the feature 
`InlineModelAdmin`, for little models. For a big model won't be impossible, 
but the admin form will be more usable. 
I have an idea to complete this task and is the following:

   1. Add a new attribute to the class `ModelAdmin`, to specify how many 
   blank rows will be shown by default when the `changelist` is rendered. The 
   new attribute would be named `list_editable_extra`, as was proposed in the 
   ticket description. This attribute will be used basically to set as `extra` 
   value in ModelAdmin.get_changelist_formset 
   

   . 
   2. As was described in the ticket; "Adapt the `result_list` template tag 
   in `admin_list.py` to show the extra forms. This can be done by calling 
   `items_for_result` with an empty model for each empty form". I tested 
   that suggestion and works good. 
   3. Avoid to render the `checkbox` "action-select" for the blank rows in 
   the `changelist` action column, in order to avoid problems with 
   changelist's actions.
   4. Add functionality similar to `InlineModelAdmin`, in order to add or 
   to delete blank rows.
   5. Add tests for the solution, including `Selenium` tests.
   6. Add documentation about the new feature.

I evaluated 2 possibilities to reach that, both possibilities with 
different impact in the Django's code.

   - Render in the blank row as editable fields, only the `list_editable` 
   fields. With this solution we need to modify less code's lines to render 
   the blank rows. Is necessary to be clear in the documentation that this 
   feature only will be able if the `list_editable` has been set, and could be 
   edited only the fields added to `list_editable` tuple.
   - Render in the blank row as editable fields, all `list_display` fields. 
   With this solution we need to make more adjusts in order to render the 
   blank rows successfully. Is necessary to be clear in the documentation that 
   this feature only will be able if the `list_display` has been set, and 
   could be edited this time only the fields added to `list_display` tuple. 
   
I know that there are some obstacles that I will go finding in the way to 
reach this goal, but it's a simple resume of my idea. I'm open to better 
ideas.

-- 
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/b55c8464-89a7-4931-9fc1-bb05208cc1f6%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Feature request] Template language type annotations (#27703)

[Adam Johnson]

I think a third party implementation could be done first for the separate
tag. I also think you'd learn more and iterate faster by building some
tooling on top of the tags whilst a third party app before merging with
core was considered. One idea that springs to mind is allowing multiple
type declarations in the same tag rather than requiring *"{% var " *written
multiple times.

On 9 January 2017 at 15:38, Дмитрий Симонов  wrote:

> Hi guys.
>
> Lets discuss about this ticket
> 
>
> I think we need create new tag in template language to annotate context
> variable types. Something like PEP 484
>  but on templates.
> As in pep 484 main goal is provide easier static analysis, potential error
> checking and improve IDEs and editors support.
> We can do this with new small tag. Something like:
>
> @register.simpletag(name='var')
> def type_hint(variable,variable_type_string: str) -> None:
> pass
>
> Then we can annotate variable in template:
>
> {% var request 'django.http.HttpResponse' %} %}
>
> or
>
> {% var is_paginated 'bool' %}
>
> or
>
> {% var user_or_none 'typing.Union[None, django.contrib.auth.models.User]'
> %}
>
> maybe
>
> {% var user_or_none 'typing.Union[None, django.conf.settings.AUTH_
> USER_MODEL]' %}
>
>
> Main idea is add this template to django default tags, not third part
> application.
> Then IDE, editor plugins, and analysis tools can build support, based on
> this.
>
> Similar links:
> https://blog.jetbrains.com/idea/2009/08/enabling-
> implicit-context-variables-resolution-in-template-files/
> https://weblogs.asp.net/scottgu/asp-net-mvc-3-new-
> model-directive-support-in-razor
>
> English is not my mother tongue; please excuse any errors on my part.
>
> --
> 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/53df8783-7234-405e-a325-
> a8bed448cd35%40googlegroups.com
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>



-- 
Adam

-- 
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/CAMyDDM2jxHm-PhD4VUQt%3DUbWeHV%3D51zKW%3Das9Kzc-Bqg4sCoZg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

[Feature request] Template language type annotations (#27703)

[Дмитрий Симонов]

Hi guys.

Lets discuss about this ticket 

I think we need create new tag in template language to annotate context 
variable types. Something like PEP 484 
 but on templates.
As in pep 484 main goal is provide easier static analysis, potential error 
checking and improve IDEs and editors support.
We can do this with new small tag. Something like:

@register.simpletag(name='var')
def type_hint(variable,variable_type_string: str) -> None:
pass

Then we can annotate variable in template:

{% var request 'django.http.HttpResponse' %} %}

or

{% var is_paginated 'bool' %}

or

{% var user_or_none 'typing.Union[None, django.contrib.auth.models.User]' %}

maybe

{% var user_or_none 'typing.Union[None, 
django.conf.settings.AUTH_USER_MODEL]' %}
 

Main idea is add this template to django default tags, not third part 
application. 
Then IDE, editor plugins, and analysis tools can build support, based on 
this.

Similar links:
https://blog.jetbrains.com/idea/2009/08/enabling-implicit-context-variables-resolution-in-template-files/
https://weblogs.asp.net/scottgu/asp-net-mvc-3-new-model-directive-support-in-razor

English is not my mother tongue; please excuse any errors on my part.

-- 
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/53df8783-7234-405e-a325-a8bed448cd35%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Responsive admin

[Marc Tamlyn]

I'd suggest including this with a mechanism (on the admin site?) to disable
it for a while if that causes problems for existing custom setups?

Marc

On 9 January 2017 at 11:59, Adam Johnson  wrote:

> - perhaps supplying an empty CSS file with the same name overrides the
>> file provided by the admin? (I’m not sure)
>
>
> It does, as long as the app it's in is before django.contrib.admin in
> INSTALLED_APPS, django-grappelli
>  uses this mechanism
> to extend/replace the admin's javascript and styles.
>
> I'm totally +1 for the responsive CSS too, thanks for your work on
> django-flat-theme!
>
> On 9 January 2017 at 11:50, Aymeric Augustin <
> aymeric.augus...@polytechnique.org> wrote:
>
>> Hello Elky,
>>
>> I’d love to see this responsive design merged in Django. I’m using the
>> admin from my phone quite often and the lack of a responsive design makes
>> that painful.
>>
>> The admin gets very few CSS changes. I don’t think we should refrain from
>> adding a useful responsive design out of fear that it will be hard to
>> maintain.
>>
>> An opt-out mechanisms for third-party apps that don’t want the responsive
>> styles will a nice touch (but not absolutely necessary in my opinion). I
>> don’t think a setting is appropriate. I’d rather use the template or static
>> file overriding mechanisms, for example:
>> - perhaps supplying an empty CSS file with the same name overrides the
>> file provided by the admin? (I’m not sure)
>> - alternatively responsive styles could apply only within
>> body.responsive; the admin’s template would have a > class=“responsive”>; third party apps could override that template and
>> remove the class
>>
>> Thanks for you work on the admin’s style,
>>
>> --
>> Aymeric.
>>
>> On 9 Jan 2017, at 11:59, elky  wrote:
>>
>> Hi guys,
>>
>> Few months ago I released *django-flat-responsive*
>>  app - a simple
>> extension for admin that makes interface mobile and tablet friendly. I
>> tested it on few complex projects using major mobile browsers and it works
>> good. Now I'm going to make pull request to Django repo but before I want
>> to ask community -- is it necessary to have responsive admin?
>>
>> My thoughts:
>>
>> Pros:
>> - It's modern
>> - Few times I really needed to make some edits inside admin through my
>> mobile (it was painful), so I think some people want admin to be responsive
>>
>> Cons:
>> - New admin features should be always tested on mobile devices (or on
>> different screen sizes at least). It also uses CSS3 flexbox so developers
>> shoul learn how it works
>> - 3rd party apps should care about responsive layout. It's not so easy
>> for some apps like Django Admin Tools or some CMS based on admin
>>
>> As fas as django-flat-responsive just adds one CSS file to static folder,
>> what if to have an option in *settings.py* that enables responsive admin?
>>
>> I would glad to hear your thoughts
>>
>> Thank you
>>
>> --
>> 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/ms
>> gid/django-developers/dd915c1d-d8a8-4f91-a223-268e17044cd1%4
>> 0googlegroups.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-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/ms
>> gid/django-developers/5A95FC83-B1DD-408C-94B7-9A4E81A6F1D3%4
>> 0polytechnique.org
>> 
>> .
>>
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>
>
> --
> Adam
>
> --
> 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 

Re: Responsive admin

[Adam Johnson]

>
> - perhaps supplying an empty CSS file with the same name overrides the
> file provided by the admin? (I’m not sure)


It does, as long as the app it's in is before django.contrib.admin in
INSTALLED_APPS, django-grappelli
 uses this mechanism to
extend/replace the admin's javascript and styles.

I'm totally +1 for the responsive CSS too, thanks for your work on
django-flat-theme!

On 9 January 2017 at 11:50, Aymeric Augustin  wrote:

> Hello Elky,
>
> I’d love to see this responsive design merged in Django. I’m using the
> admin from my phone quite often and the lack of a responsive design makes
> that painful.
>
> The admin gets very few CSS changes. I don’t think we should refrain from
> adding a useful responsive design out of fear that it will be hard to
> maintain.
>
> An opt-out mechanisms for third-party apps that don’t want the responsive
> styles will a nice touch (but not absolutely necessary in my opinion). I
> don’t think a setting is appropriate. I’d rather use the template or static
> file overriding mechanisms, for example:
> - perhaps supplying an empty CSS file with the same name overrides the
> file provided by the admin? (I’m not sure)
> - alternatively responsive styles could apply only within body.responsive;
> the admin’s template would have a ; third party
> apps could override that template and remove the class
>
> Thanks for you work on the admin’s style,
>
> --
> Aymeric.
>
> On 9 Jan 2017, at 11:59, elky  wrote:
>
> Hi guys,
>
> Few months ago I released *django-flat-responsive*
>  app - a simple extension
> for admin that makes interface mobile and tablet friendly. I tested it on
> few complex projects using major mobile browsers and it works good. Now I'm
> going to make pull request to Django repo but before I want to ask
> community -- is it necessary to have responsive admin?
>
> My thoughts:
>
> Pros:
> - It's modern
> - Few times I really needed to make some edits inside admin through my
> mobile (it was painful), so I think some people want admin to be responsive
>
> Cons:
> - New admin features should be always tested on mobile devices (or on
> different screen sizes at least). It also uses CSS3 flexbox so developers
> shoul learn how it works
> - 3rd party apps should care about responsive layout. It's not so easy for
> some apps like Django Admin Tools or some CMS based on admin
>
> As fas as django-flat-responsive just adds one CSS file to static folder,
> what if to have an option in *settings.py* that enables responsive admin?
>
> I would glad to hear your thoughts
>
> Thank you
>
> --
> 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/ms
> gid/django-developers/dd915c1d-d8a8-4f91-a223-268e17044cd1%
> 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-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/ms
> gid/django-developers/5A95FC83-B1DD-408C-94B7-9A4E81A6F1D3%
> 40polytechnique.org
> 
> .
>
> For more options, visit https://groups.google.com/d/optout.
>



-- 
Adam

-- 
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/CAMyDDM3c%2B6PzGFOm63sVL0g63mMtchHRPFQsyb39rN%3D3ND8%2BHA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Responsive admin

[Aymeric Augustin]

Hello Elky,

I’d love to see this responsive design merged in Django. I’m using the admin 
from my phone quite often and the lack of a responsive design makes that 
painful.

The admin gets very few CSS changes. I don’t think we should refrain from 
adding a useful responsive design out of fear that it will be hard to maintain.

An opt-out mechanisms for third-party apps that don’t want the responsive 
styles will a nice touch (but not absolutely necessary in my opinion). I don’t 
think a setting is appropriate. I’d rather use the template or static file 
overriding mechanisms, for example:
- perhaps supplying an empty CSS file with the same name overrides the file 
provided by the admin? (I’m not sure)
- alternatively responsive styles could apply only within body.responsive; the 
admin’s template would have a ; third party apps could 
override that template and remove the class

Thanks for you work on the admin’s style,

-- 
Aymeric.

> On 9 Jan 2017, at 11:59, elky  wrote:
> 
> Hi guys,
> 
> Few months ago I released django-flat-responsive 
>  app - a simple extension for 
> admin that makes interface mobile and tablet friendly. I tested it on few 
> complex projects using major mobile browsers and it works good. Now I'm going 
> to make pull request to Django repo but before I want to ask community -- is 
> it necessary to have responsive admin?
> 
> My thoughts:
> 
> Pros:
> - It's modern
> - Few times I really needed to make some edits inside admin through my mobile 
> (it was painful), so I think some people want admin to be responsive
> 
> Cons:
> - New admin features should be always tested on mobile devices (or on 
> different screen sizes at least). It also uses CSS3 flexbox so developers 
> shoul learn how it works
> - 3rd party apps should care about responsive layout. It's not so easy for 
> some apps like Django Admin Tools or some CMS based on admin
> 
> As fas as django-flat-responsive just adds one CSS file to static folder, 
> what if to have an option in settings.py that enables responsive admin?
> 
> I would glad to hear your thoughts
> 
> Thank you
> 
> -- 
> 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/dd915c1d-d8a8-4f91-a223-268e17044cd1%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-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/5A95FC83-B1DD-408C-94B7-9A4E81A6F1D3%40polytechnique.org.
For more options, visit https://groups.google.com/d/optout.

Responsive admin

[elky]

Hi guys,

Few months ago I released *django-flat-responsive* 
 app - a simple extension 
for admin that makes interface mobile and tablet friendly. I tested it on 
few complex projects using major mobile browsers and it works good. Now I'm 
going to make pull request to Django repo but before I want to ask 
community -- is it necessary to have responsive admin?

My thoughts:

Pros:
- It's modern
- Few times I really needed to make some edits inside admin through my 
mobile (it was painful), so I think some people want admin to be responsive

Cons:
- New admin features should be always tested on mobile devices (or on 
different screen sizes at least). It also uses CSS3 flexbox so developers 
shoul learn how it works
- 3rd party apps should care about responsive layout. It's not so easy for 
some apps like Django Admin Tools or some CMS based on admin

As fas as django-flat-responsive just adds one CSS file to static folder, 
what if to have an option in *settings.py* that enables responsive admin?

I would glad to hear your thoughts

Thank you

-- 
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/dd915c1d-d8a8-4f91-a223-268e17044cd1%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Use of HTML autofocus attribute in admin (#27692)

[Adam Johnson]

>
> I just found out that's it not new behavior in Django 1.9. The javascript
> autofocus that existed previously has the same effect.


Oh yeah, so it does. Yes it's still annoying but changing the default could
be more confusing. If there were a way to autofocus on first page load only
that would be the best, it might be possible with JS.

On 8 January 2017 at 20:33, Ciske Boekelo  wrote:

> I just found out that's it not new behavior in Django 1.9. The javascript
> autofocus that existed previously has the same effect. This doesn't change
> my request though, I'd still like the autofocus to be either removed or
> optional.
>
> Op vrijdag 6 januari 2017 18:54:54 UTC+1 schreef Adam Johnson:
>>
>> I think we should remove it and maybe add the Javascript back, this is
>> going to affect many peoples' workflows, some of whom are in my
>> organization.
>>
>> On Friday, January 6, 2017 at 5:48:12 PM UTC, Tim Graham wrote:
>>>
>>> As part of removing inline JavaScript in the admin [0], snippets such as
>>> document.getElementById("id_old_password").focus() were replaced with
>>> the HTML5 autofocus attribute.
>>>
>>> This attribute has a possibly undesired behavior [1]: "*Warning*: this
>>> attribute will force a page scroll to the field with the autofocus attribute
>>> set, even within an iframe. So: know your audience, know the position of
>>> the form."
>>>
>>> This attribute could be problematic on the change list's admin's search
>>> box: "When coming back to the list screen from the edit screen, the
>>> browser normally remembers your scroll position and restores it. This is
>>> desirable behavior if you want to work through a long lists of objects.
>>> However, when you include a search field in the list screen, it has
>>> autofocus enabled, which prevents the scroll position from being restored.
>>> This is annoying and unhelpful." [2]
>>>
>>> Do you think we should remove autofocus from the search box to remedy
>>> this complaint (and possibly go back to using JavaScript for that) or are
>>> there any better solutions here?
>>>
>>> [0] https://github.com/django/django/commit/d638cdc42acec608
>>> c1967f44af6be32a477c239f
>>> [1] http://www.wufoo.com/html5/attributes/02-autofocus.html
>>> [2] https://code.djangoproject.com/ticket/27692
>>>
>> --
> 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/d02bfbaa-be99-46da-9a11-
> a8fad7fac7cc%40googlegroups.com
> 
> .
>
> For more options, visit https://groups.google.com/d/optout.
>



-- 
Adam

-- 
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/CAMyDDM2v2_we-KFPmoDixkCW7tfgehvx7B_N1rpLR5WbwCX4yw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.