The PBKDF2 speed improvements are in Python 2.7.8 and 3.4+, so you'd need
to use Python 2.7.7 or earlier to get the slower version.
On Tuesday, January 3, 2017 at 7:56:35 PM UTC-5, Martin Koistinen wrote:
>
> H, I just tried this using a simple management command to do some
> basic benchmark
Is the situation bad enough that you would volunteer to maintain the
project?
The Django team is a collection of volunteers (excepting me) who work on
Django. It seems that no one on the team or reading this mailing list has
time or interest in maintaining the project. We need to clarify the
m
H, I just tried this using a simple management command to do some basic
benchmarking of password hashing. I made this little package Py2/Py3
compatible. You can find it here:
https://github.com/mkoistinen/hash_benchmark
(Just install it from the repo into an existing project, then add
'has
H, I just tried this using a simple management command to do some basic
benchmarking of password hashing. I made this little package Py2/Py3
compatible. You can find it
here: https://github.com/mkoistinen/hash_benchmark
(Just install it from the repo into an existing project, then add
'has
This is really bad. django-formtools used to be part of the core of Django.
Is this getting the attention it deserves from the Django Foundation?
On Monday, November 28, 2016 at 9:55:48 PM UTC-7, Asif Saifuddin wrote:
>
> Hi Tim,
>
> In case there is lack of active maintainers for the project the
Thanks. I updated my code accordingly. But I open the websocket
connection after one second if the python application does not send an
Send/Close/Accept message. In other case the software would not be
compatible with the examples in
https://github.com/andrewgodwin/channels-examples
I uploaded th
August 2016: PyPy gets funding from Mozilla for Python 3.5 support
"Within the next year, we plan to use the money to pay four core PyPy
developers half-time to work on the missing features and on some of the big
performance and cpyext issues. This should speed up the progress of
catching up wit
On Tue, Jan 3, 2017 at 1:14 PM, Adam Johnson wrote:
> But, to be consistent with Django 1.x going forward, let's define 36,000
>> iterations as "acceptable performance" for a Python2 with Django 1.11
>> install on a typical piece of server hardware today (beginning of 2017). A
>> useful benchmark
>
> But, to be consistent with Django 1.x going forward, let's define 36,000
> iterations as "acceptable performance" for a Python2 with Django 1.11
> install on a typical piece of server hardware today (beginning of 2017). A
> useful benchmark would be to determine how many iterations would yield
Mhm, just thought about the fact that this means we are also dropping
support for PyPy and Jython -- not sure about the Jyton usage, but loosing
PyPy sounds sad, how far along are there python 3 efforts? It looks like it
is/was close to 3.3 according to
https://morepypy.blogspot.co.at/2016/08/p
I think the best practice is to set the iterations as high as you can
tolerate without adversely affecting the user experience as they log-in.
Iteration numbers as high as 200,000 for SHA-256 or even more are not
unheard of these days. Without looking at an application's password
expiration pol
On Mon, Jan 2, 2017 at 1:10 PM, Oskar Hahn wrote:
> Hi,
>
> this is a question on how to interpret the asgi specs of django channels:
>
> https://channels.readthedocs.io/en/latest/asgi.html
>
> If this is the wrong place to discuss it, then please point me to the
> right place.
>
I think it's th
I think this is probably too disruptive a change for Django core,
especially after so long with the current GCBV implementations - it would
require all users to rewrite their CBV's. Possibly the documentation could
recommend django-vanilla-views?
On 3 January 2017 at 13:02, Asif Saifuddin wrote:
I agree with Carl's comment on the PR:
"I don't think it would complicate the API too much to have a count=1
kwarg, and if count > 1 expect received_kwargs to be a list of lists
instead of just a list. This keeps the API identical to what it is
currently for the common case, but makes it possib
Hi,
I have started work on https://github.com/django/django/pull/7783 for
converting django built in generic views to django-vanilla-views.
I would like to hear what you think before I proceed for more.
Thanks,
Asif
On Friday, September 16, 2016 at 1:37:36 AM UTC+6, Asif Saifuddin wrote:
>
>
Hi,
We'd like to receive some feedback on the pull request
https://github.com/django/django/pull/7560
that address the ticket https://code.djangoproject.com/ticket/27332.
This pull request allows to pass custom filtering within the "ON" SQL
clauses.
This functionality might improve performance of
On Tue, Jan 3, 2017 at 1:14 AM, Aymeric Augustin <
aymeric.augus...@polytechnique.org> wrote:
> Regarding arguments, since signal receivers must accept **kwargs (that’s a
> document requirement), I think it’s acceptable for assertSignalSent to
> ignore unexpected arguments.
>
It's often the case
Hello,
On 3 Jan 2017, at 09:16, James Bennett wrote:
> Personally I'm against trying to do this in assertSignalSent, and would argue
> for a separate assertSignalSentMultiple if that use case is deemed important
> enough; coming up with a unified API that cleanly handles both the case of a
>
At DUTH this year I opened a ticket to add test-case assertions checking
whether (or not) a signal was sent:
https://code.djangoproject.com/ticket/27447
And corresponding PR:
https://github.com/django/django/pull/7508
The PR has gotten bogged down in API design discussion, so I'd like to hash
t
19 matches
Mail list logo
