Re: Methodology for increasing the number of PBKDF2 iterations

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

Re: Methodology for increasing the number of PBKDF2 iterations

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

Re: Methodology for increasing the number of PBKDF2 iterations

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

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

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

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

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

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

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"

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

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

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

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

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

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

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

[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

Re: Responsive admin

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

Re: Responsive admin

> > - 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

Re: Responsive admin

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

Responsive admin

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

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

> > 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