Re: graphics artist (e.g. OmniGraffle) needed for updated middleware graphic

[Lee Trout]

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 is and isn't
called...

It might be best to expand this in to 2 or 3 graphics and show the various
states (or an animated gif)...

Lee

On Mon, May 9, 2016 at 9:48 PM, Tim Graham  wrote:

> 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
> is done in OmniGraffle [2] but I guess we're open to other solutions too.
>
> [0]
> https://docs.djangoproject.com/en/1.9/topics/http/middleware/#hooks-and-application-order
> [1] https://github.com/django/django/pull/6501
> [2]
> https://github.com/django/django/tree/bf3057d10bc1e78a8e45142a8288a733b3e908a2/docs/topics/http/_images
>
> --
> 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/890120ba-3f7e-40ad-86d0-f3f9c7a08a6b%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/CAABi-Dq485Ncy7vqhHEe6Q6sk-cLOsXeiDxzVe6y3yXvpw%2BxYQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Django Integration

[Andrew Godwin]

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 selectively backporting somes fixes for Django's monthly bug fix
> releases. If channels continues to live externally, I assume there won't be
> the complication of a master vs. stable branch and that releases could
> happen more often. If this feature is exciting enough, whether or not its
> in Django itself shouldn't make too much of a difference, should it? Also,
> if we do include this in 1.10 and then start paying people using the
> Mozilla money, that might result in master changing even more aggressively
> compared to the stable branch at which point having a 1.10 release that's X
> months old in terms of the latest features might not be all that valuable.
>

A lot of the future work is not on the core code itself but additional code
around it; this was the whole point of getting a core amount of it into
1.10, so that there was something consistent to build around.


>
> Tell me if I'm wrong, but I get the sense that you are somewhat burned out
> maintaining this project on your own and you feel that merging this to
> Django will help offload your burden and attract other contributors. If
> that's the case, there's a possible solution in using some of the Mozilla
> money to try to get help in more of the code review/maintenance tasks. If
> we have an accepted DEP and plans to merge it to core in 1.11, I would try
> to get more involved with those projects too.
>

I'm not burned out maintaining it - I'm burned out trying to argue about
getting it into core, so I'm inclined to stop arguing for that reason
alone, and instead revert to the tactic I know best of running huge
features out of a slightly-monkeypatchy external package :)

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 arising there.


>
> I don't see a problem in continuing to refine this externally even if that
> means it lands in an LTS. I sure would feel less overwhelmed if I didn't
> have to review the big patch up against the alpha deadline and/or if this
> threatens to delay the 1.10 release.
>
>
I understand, and I'm sorry for not getting this done in a more timely
fashion; I should have had the patch ready earlier than it was, but didn't
get round to it for a while, and (mistakenly) thought a few weeks would be
enough.

If we do keep it external, I would suggest that we still move to adopt it
as an official Django project, moving ownership of the git repos and
mentioning it in official documentation; this to me seems like a less
severe thing than merging it into core, and also something that there is
not a deadline preventing so we can discuss it further if needs be.

Andrew

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

graphics artist (e.g. OmniGraffle) needed for updated middleware graphic

[Tim Graham]

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 
is done in OmniGraffle [2] but I guess we're open to other solutions too.

[0] 
https://docs.djangoproject.com/en/1.9/topics/http/middleware/#hooks-and-application-order
[1] https://github.com/django/django/pull/6501
[2] 
https://github.com/django/django/tree/bf3057d10bc1e78a8e45142a8288a733b3e908a2/docs/topics/http/_images

-- 
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/890120ba-3f7e-40ad-86d0-f3f9c7a08a6b%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Django Integration

[Tim Graham]

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 fix 
releases. If channels continues to live externally, I assume there won't be 
the complication of a master vs. stable branch and that releases could 
happen more often. If this feature is exciting enough, whether or not its 
in Django itself shouldn't make too much of a difference, should it? Also, 
if we do include this in 1.10 and then start paying people using the 
Mozilla money, that might result in master changing even more aggressively 
compared to the stable branch at which point having a 1.10 release that's X 
months old in terms of the latest features might not be all that valuable.

Tell me if I'm wrong, but I get the sense that you are somewhat burned out 
maintaining this project on your own and you feel that merging this to 
Django will help offload your burden and attract other contributors. If 
that's the case, there's a possible solution in using some of the Mozilla 
money to try to get help in more of the code review/maintenance tasks. If 
we have an accepted DEP and plans to merge it to core in 1.11, I would try 
to get more involved with those projects too.

I don't see a problem in continuing to refine this externally even if that 
means it lands in an LTS. I sure would feel less overwhelmed if I didn't 
have to review the big patch up against the alpha deadline and/or if this 
threatens to delay the 1.10 release.

On Friday, May 6, 2016 at 1:16:20 AM UTC-4, Andrew Godwin wrote:
>
>
>
> On Thu, May 5, 2016 at 9:28 PM, Anssi Kääriäinen  > wrote:
>
>> On Thursday, May 5, 2016, Andrew Godwin > > wrote:
>>>
>>> Do you have a link to the presentation about them removing it?
>>>
>>
>> https://youtu.be/839rskyJaro around 34 minutes and onwards, another 
>> version is https://youtu.be/2dG5HeM7MvA at 24 minutes.
>>
>
> Summarising their issues here for future people to save on video watching:
>
> - Large response bodies/streamed/chunked bodies are hard to serialise into 
> Redis
> - Working out the order to restart things in is tricker than standard HTTP 
> loadbalancing
> - Healthchecking the Rails process was difficult as they didn't listen on 
> HTTP (just to Redis)
> - Hard to do rate-limiting and monitoring as it lacked context
> - HAProxy got a lot more featureful and grew the features they needed 
> (hot-swapping of backends), and was a lot more battle-tested
>
> In general, it seems they were mainly using it to achieve HA, and it 
> didn't quite pull through for them on that front. Some of these issues also 
> apply to Channels, some less so as it's not designed as a HA solution and 
> just being used for that.
>
> In particular, they were doing a lot more to keep requests around, whereas 
> Channels will drop them if it's unsure what's going on, which gives it a 
> lot more leeway (but makes it less "perfect" at HA).
>  
>
>>
>> They were tackling a bit different problem, so their lessons might not 
>> apply. Most importantly they weren't aiming for websockets at all, just for 
>> high availability and throughput for normal HTTP traffic. On the other 
>> hand, the architecture of broxy itself is pretty much the same as Daphne, 
>> and they felt they had problems with it.
>>
>
> I need to start writing up my preferred large-scale deployment 
> architecture for Channels more, which is "small clusters of interfaces and 
> workers with an external loadbalancer across all clusters"; all of the 
> stories I've heard, this included, the common theme is trying to push all 
> of the site traffic through just the one bus and having great issues when 
> it keels over under unexpected load or machine failure.
>
> I'm also starting to think we should have a local shared-memory channel 
> layer that only works between processes on the one machine, so one could in 
> theory just run clusters like this on decently sized multicore boxes; that 
> would make a lot of people happier who don't want to have to run Redis in 
> production but still want the multi-process behaviour that Channels gives. 
> Running Channels would then just mean two processes, Daphne and workers.
>  
>
>>
>> The way we have approached recent feature additions is that we let them 
>> prove themselves outside of core. I think the crucial question is why 
>> Channels can't do this, that is why can't we wait some time and let actual 
>> production deployments prove the design?
>>
>> I know South is an example of why some features have a hard time living 
>> outside core. But DRF is an example that a feature crucial to modern web 
>> development can work very well outside of core.
>>
>>
> Channels sits somewhere between these two; it's not quite as deeply 
> involved in hacking around core parts 

Re: ***SPAM*** Re: Middleware+Transactions:

[Kevin Tran]

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 actually work in 
> > a well defined and easy to use way. Currently, there is no 
> > guarantee(!) that either process_exception or process_response gets 
> > called after process_request has been called for given middleware, and 
> > this makes it impossible to implement a transaction middleware purely 
> > as a middleware. 
>
> It's the same with TestCase.setUp() and TestCase.tearDown() does not work 
> well together with decorators. 
>
> You are right. Instead of 
>
>   settings.MIDDLEWARES_INSIDE_TRANSACTION 
>
>   settings.CONTEXT_MANAGERS 
>
> would be better. 
>
> The atomic() could be one entry in the list of context managers. 
>
> > An idea... Would investigating and implementing better middlewares (or 
> > urlpattern wrappers) make for a good GSoC project? Maybe the "wrap 
> > URLs" approach could be part of the URL resolve refactoring GSoC 
> > project? 
>
> I don't know if GSoC is a good solution. It is appealing, since 
> it looks that someone else does the work (not me and my team mates). 
> But I am a little bit afraid that will this result in a more complicated 
> implementation. My perfect solution are only very few lines of code. 
> I guess this could be possible. I guess the diff for the docs 
> could be longer then the diff for the code. 
>
> Regards, 
>Thomas 
>
> -- 
> Thomas Güttler 
> http://thomas-guettler.de/ 
>

-- 
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/c1ea2f8b-e976-4ef8-97e4-491a24ecc711%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Making Django more PaaS-friendly

[Carl Meyer]

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 evolves. What we do with DEPs is different, we first design
> something, then we document the design decision, often mostly because
> DEPs are a required document. We don't get what we could from DEPs as
> they are written too late.

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 engines and rethinking middleware), I
don't think this is an accurate description of what happened. Both those
DEPs were written relatively early in the design process and evolved as
we learned from discussion and implementation.
They were done quite similarly to how the PEPs I've worked on were done.

I'm also curious about your use of the word "enforced." I don't really
see the DEP process as something that needs "enforcement" (and I'm
curious where you see it as having been lacking in "enforcement"). IMO
the only relevant "enforcement," really, is that the implementation of a
DEP which is rejected by the technical board (has never happened yet)
should not be merged.

DEPs, like PEPs, aren't supposed to be a legalistic policy: there is no
hard and fast rule about which features should have DEPs, and I don't
think we need a hard and fast rule. DEPs should happen when someone
observes that the discussion around a feature is getting quite complex
or contentious, and suggests that a DEP would be helpful. DEPs should be
a tool, not a barrier: a tool for helping to focus discussions on
contentious issues, and record the perspectives expressed in those
discussions, both for posterity and to help keep the discussion from
going around in circles.

> Could we try an approach where we *first* require a DEP, then have the
> design discussion?

In the PEP process, it's very typical to start into design discussions
before realizing that the issue is contentious/complex enough to require
a PEP, then someone collects the knowledge generated from that early
discussion into a first draft PEP, which then receives further
discussion. (In the Python world most of this pre-PEP discussion happens
on the python-ideas mailing list, so if you aren't subscribed there you
might not see it.) I think this thread is a great example of that
working precisely the way it should work: first post some general
thoughts, collect ideas and responses to those thoughts, then work that
into a DEP with a specific proposal, followed by more detailed
discussion of that specific proposal.

Carl

-- 
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/573113D6.90503%40oddbird.net.
For more options, visit https://groups.google.com/d/optout.


signature.asc
Description: OpenPGP digital signature

Re: Template-based widget rendering

[Carl Meyer]

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) 'django.forms' in
> INSTALLED_APPS (so the APP_DIRS loader can find the DTL widget
> templates) or b) Jinja2 to be installed so that the
> TemplateRenderer.default_engine() initialization of Jinja2 doesn't fail.
> If these items were accepted and acknowledged as upgrade requirements,
> it wasn't clear to me.

Nope, I just overlooked the "Jinja2 is not installed" case there. In
that case we should just use a DjangoTemplates engine instead of a
Jinja2 engine as the fallback, which is what you've done in
https://github.com/django/django/pull/6498/commits/83e0138a85ada2a8139af8a35629b78ec5e539d8

> In trying to make the Django test suite pass without Jinja2 installed, I
> noticed that the 'django.forms' in INSTALLED_APPS requirement is a bit
> annoying because this requires any use of
> @override_settings(INSTALLED_APPS=[...]) that does widget rendering to
> now include 'django.forms'.

Yeah... so relatedly, you also mentioned in IRC and on GH that you don't
see why we should deprecate the automatic fallback in case you don't
have django.forms in INSTALLED_APPS and a loader with APP_DIRS=True. The
answer to that, IMO, is that checking specifically for "django.forms in
INSTALLED_APPS and APP_DIRS=True" is janky and inadequate, and I really
don't think it belongs in there permanently. In fact I'm wondering now
whether it even belongs in there temporarily as a deprecation path.

The problem with that check is that there are various legitimate ways
one could use the TemplateRenderer, and putting django.forms in
INSTALLED_APPS and using a loader with APP_DIRS=True is only one of
them. If you don't want to use APP_DIRS=True, it's also reasonable to
put a separate engine in TEMPLATES pointing to the form templates (this
might be a nicer solution for the Django test suite, for instance). Some
people might even want to supply all their own form templates and not
use any of the default ones, and that should be supported, too. By
automatically overriding with our own fallback template engine if we
don't detect "django.forms in INSTALLED_APPS and APP_DIRS=True", we
effectively prohibit any other approach. I thought that might be OK as a
temporary state of affairs during a deprecation path, but I definitely
don't think it's OK permanently.

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 the built-in templates if a template
is not found via the engines configured in TEMPLATES.

I still think that in the long run, it's simpler and more predictable if
the developer is simply responsible to either set up TEMPLATES such that
the form templates needed are findable (startproject would set this up
by default), or use a custom subclass of TemplateRenderer that does
something entirely different. So I would still favor deprecating the
fallback (in which case we should also update the startproject template
so the fallback isn't needed for new projects). But I think this
fallback is more flexible and simple enough that we could consider
keeping it in place permanently, if you and others prefer that.

(I also removed the whole engine_name thing in that commit; it doesn't
really seem worth it. If you're subclassing TemplateRenderer, it's easy
enough to just override get_template and do whatever you like.)

If you like that approach, I can re-add some TemplateRenderer tests and
update the docs and push it to the main `15667` branch.

Carl

-- 
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/57310F15.2060401%40oddbird.net.
For more options, visit https://groups.google.com/d/optout.


signature.asc
Description: OpenPGP digital signature

Re: Unicode normalization for username field

[Claude Paroz]

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.

Claude 

-- 
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/9c69b956-5443-42dc-9b53-474fc7fbdbd5%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: failure to load fixtures during unit tests

[Rich Rauenzahn]

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 
created objects that conflicted with the fixtures loaded in other TestCase 
classes.  Somehow Django-nose's FastFixtureTestCase hid this problem.

What I'm not sure about (and need to investigate) is if Django-nose's 
TestRunner is the optimizing away fresh databases between TestCase classes, 
or if that is standard.

Rich

-- 
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/f74ac850-26d4-4db2-8aef-1d595f8279b7%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Template-based widget rendering

[Tim Graham]

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 can find the DTL widget templates) 
or b) Jinja2 to be installed so that the TemplateRenderer.default_engine() 
initialization of Jinja2 doesn't fail. If these items were accepted and 
acknowledged as upgrade requirements, it wasn't clear to me.

In trying to make the Django test suite pass without Jinja2 installed, I 
noticed that the 'django.forms' in INSTALLED_APPS requirement is a bit 
annoying because this requires any use of 
@override_settings(INSTALLED_APPS=[...]) that does widget rendering to now 
include 'django.forms'. 

On Wednesday, June 10, 2015 at 6:14:11 PM UTC-4, Preston Timmons wrote:
>
> Hi Carl,
>
> Thanks for the feedback. I agree with your suggestions. I didn't think 
> about
> running a check for a combination of INSTALLED_APPS and a loader with
> APP_DIRS. That would be sufficient for customizing loading.
>
> I'll update and convert this to a PR.
>
> Preston
>

-- 
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/378b1cbd-e2a2-4ee9-b088-29c21f9cfd61%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Making Django more PaaS-friendly

[Anssi Kääriäinen]

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, then we document the design decision, often mostly because
DEPs are a required document. We don't get what we could from DEPs as
they are written too late.

Could we try an approach where we *first* require a DEP, then have the
design discussion?

 - Anssi

On Mon, May 9, 2016 at 2:42 PM, Shai Berger  wrote:
> 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 look like, and ask
>> for feedback on that.
>>
>
> Looking at what we just had in other threads, this is probably DEP-worthy;
> even if the results end up being a relatively small modification, it would be
> helpful to record why we decided to reject the other suggestions.
>
> Shai.

-- 
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/CALMtK1HrKje7%3DQLi-51sw4ZRSY3jFE1VTu_BKsL1y4u2EiVRJQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Unicode normalization for username field

[Tim Graham]

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
> -optionally, UTF8 with normalization
> -based on Claude's code
> -Python 3 required so we are not distracted by compatibility issues
> Cheers -- Rick

-- 
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/bb711bc1-e645-48c1-aa12-10bf950e3ad7%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Making Django more PaaS-friendly

[Shai Berger]

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 look like, and ask
> for feedback on that.
> 

Looking at what we just had in other threads, this is probably DEP-worthy; 
even if the results end up being a relatively small modification, it would be 
helpful to record why we decided to reject the other suggestions.

Shai.