Updated the sheet with more recent GPU pricing.
On Thursday, January 19, 2017 at 1:19:57 PM UTC-5, Martin Koistinen wrote:
>
> All, I've converted my worksheet into a Google Docs Sheet here:
> https://docs.google.com/spreadsheets/d/16_KdYAW03sb86-w_AFFnM79IaTWQ7Ugx4T0VMfGteTM/edit?usp=sharing
>
>
Hi,
An alternative option with 'six' is to replace it with an alias of six
propper (not vendored), something like this:
# django/utils/six.py
try:
from six import *
except ImportError:
raise ImportError((
"`django.utils.six` is deprecated, install six from pypi "
Okay, I updated the PR to use a deprecation. I'd rather not complicate
things with an accelerated deprecation.
On Tuesday, January 24, 2017 at 6:39:32 AM UTC-5, Adam Johnson wrote:
>
> Ok fair point, I agree it should go through the short deprecation process.
> It's also very small and not that
Yes, that's probably the best short-term fix and will keep it working with
older versions - I'll put that in as a fix for this now.
I agree it's potentially dangerous, but then I also think the current
behaviour is a bit misleading. I'll dig around some third party apps and
see if I can see exampl
The change you proposed might be acceptable, although I'm a bit nervous
about breaking backwards-compatibility in some unforeseen use case. I
wonder if modifying the condition in the
channel_session decorator to: if session.modified and not
session.is_empty(): would solve the issue? This seems s
For reference there are some discussions about this
in https://code.djangoproject.com/ticket/13906. The short version of the
discussions is that MySQL is very interesting when it comes to transaction
isolation levels and things like SELECT FOR UPDATE...
I think it would be ok to allow changing
Hello,
Django is earning a lot of goodwill from its well-defined deprecation policy.
It was recently improved to allow pluggable apps to work without import shims
and without deprecation warnings from one LTS to the next. I don’t know the
exact details but I believe that's the intent.
Combined
Ok fair point, I agree it should go through the short deprecation process.
It's also very small and not that bothersome to keep around.
On 24 January 2017 at 10:46, Josh Smeaton wrote:
> I remembered a thing from Michaels talk at #DUTH. Let me present a use
> case for subclassing a backend:
>
>
Hi Raphaël ,
the goal of DCP is to "unite" the behaviour of different django versions,
so that all the code needed by a project (misc. pypi dependencies, as well
as custom project modules) may work together, whatever the exact django
version each of these module actually targets. That's closer to
I remembered a thing from Michaels talk at #DUTH. Let me present a use case
for subclassing a backend:
https://github.com/opbeat/django-postgres-readonly/blob/master/django_postgres_readonly/base.py
I think if we end up favouring immediate deprecation, we could proactively
find and inform backe
10 matches
Mail list logo
