On Tue, May 10, 2016 at 4:54 AM, Andrew Godwin wrote:
> My concern around using the Mozilla money to refine it was that it was
> applied for under the pretense this would be core Django, though if that's
> still our intention and we keep it external for now I don't see too much of
> a problem aris
I agree with Carl’s arguments about the fallback strategy (specifically,
the four paragraphs quoted below).
--
Aymeric.
> On 10 May 2016, at 00:28, Carl Meyer wrote:
>
> Yeah... so relatedly, you also mentioned in IRC and on GH that you don't
> see why we should deprecate the automatic fallbac
I’m the author of the current graphic. If it’s just a matter of tooling, I can
take a sketch (e.g. a picture of hand-drawn diagram) and do it in a consistent
style with the other graphic in the docs.
--
Aymeric.
> On 10 May 2016, at 03:48, Tim Graham wrote:
>
> Would someone like to help upd
Le mardi 10 mai 2016 00:28:57 UTC+2, Carl Meyer a écrit :
>
> I pushed an alternative approach in
>
> https://github.com/carljm/django/commit/7d734cfb9da2f64e4bf59c55167c70748b3bd092
>
> that removes the INSTALLED_APPS checking. Instead, it has the `render`
> method unconditionally fallback to
On Tue, May 10, 2016 at 1:48 AM, Carl Meyer wrote:
> Hi Anssi,
>
> On 05/09/2016 06:53 AM, Anssi Kääriäinen wrote:
> I'm curious to hear more about this - could you give some example DEPs
> where this was a problem? In the case of the two DEPs I was most closely
> involved with (multiple template
I have an omnigraffle license and could help a bit later this week if no
one else is interested.
I'm out of touch with Django lately... I read the DEP and I'm assuming
you're after an updated graphic to explicitly show the behavior of proper
short circuiting and the better guarantees around what i
On Mon, May 9, 2016 at 6:42 PM, Tim Graham wrote:
> I'm not convinced either way about whether putting this in core will help
> mature it and fix bugs more quickly or not. I don't have any sense of how
> the code might change after we merge it, but things get more complicated if
> we start select
Would someone like to help update the graphic in this section [0] for the
new-style middleware implemented in PR#6501 [1]. I'm not quite sure what
the updated graphic will look like yet, but there isn't any use thinking
about that if we don't have someone to do the work. :-) The existing image
I'm not convinced either way about whether putting this in core will help
mature it and fix bugs more quickly or not. I don't have any sense of how
the code might change after we merge it, but things get more complicated if
we start selectively backporting somes fixes for Django's monthly bug fi
Thomas, did you ever find a solution to your problem? I'm having similar
thoughts and am looking for an answer.
On Friday, February 6, 2015 at 4:18:53 AM UTC-8, guettli wrote:
>
>
>
> Am 04.02.2015 um 14:04 schrieb Anssi Kääriäinen:
> > I'd really like to be able to define middlewares that actu
Hi Anssi,
On 05/09/2016 06:53 AM, Anssi Kääriäinen wrote:
> I'm very much afraid we are in a situation where we have a documented
> DEP process which isn't actually enforced, nor does it document what
> we actually do.
>
> Python's PEP process is useful as the document evolves while the
> design e
Hi Tim,
On 05/09/2016 08:03 AM, Tim Graham wrote:
> I've been working on testing and writing documentation for Preston's PR:
> https://github.com/django/django/pull/6498
>
> About backwards compatibility, the current implementation which seems to
> be based on Carl's proposal requires either a) '
Le lundi 9 mai 2016 14:48:06 UTC+2, Tim Graham a écrit :
>
> Rather than change the behavior of Python 2 near its last supported
> version of Django, I would make the default validator ASCII on Python 2 and
> Unicode on Python 3.
>
I can buy this, providing we don't face migration issues.
Claud
FYI, I was finally able to resolve this. I had an assumption that
TestCase's began with a freshly created database between TestCase classes.
I asserted this in _fixture_setup() and found that assumption to be false.
Upon further research I found a setUpClass() in another TestCase that
create
I've been working on testing and writing documentation for Preston's PR:
https://github.com/django/django/pull/6498
About backwards compatibility, the current implementation which seems to be
based on Carl's proposal requires either a) 'django.forms' in
INSTALLED_APPS (so the APP_DIRS loader ca
I'm very much afraid we are in a situation where we have a documented
DEP process which isn't actually enforced, nor does it document what
we actually do.
Python's PEP process is useful as the document evolves while the
design evolves. What we do with DEPs is different, we first design
something,
Rather than change the behavior of Python 2 near its last supported version
of Django, I would make the default validator ASCII on Python 2 and Unicode
on Python 3.
On Tuesday, May 3, 2016 at 9:29:06 AM UTC-4, Rick Leir wrote:
>
> Hi all
> Could there be a consensus with
> -default to ASCII
> -o
On Monday 09 May 2016 05:06:47 James Bennett wrote:
> Whee, this thread got big!
>
> The takeaway I'm getting here is that we should be careful about what we
> adopt into core and when; I'm going to take a couple days and write up some
> notes on what I think a good conservative approach would loo
18 matches
Mail list logo
