Re: Streaming HttpResponse revisted. Any core devs, please take a look if you can :)

> I don't think what you are suggesting would be necessary. Stream-capable > middleware could avoid having to handle both cases by simply wrapping > response.content with a new iterator in all cases, if they want to. > Non-streaming responses can still be iterated. They just have fewer >

Re: Perception of attitude in tickets

On May 13, 2013, at 3:21 PM, Peter wrote: > I have a thought on an action we could take out of this that might be > constructive. > > Would it be possible to customise trak at all to make the workflow clearer? > > I'm thinking if someone tries to open a ticket that was

Re: first() and last(), earliest() and latest()

Only is a different purpose than first, and as such it would make sense to me if it was a separate method. First has some implication that there may be second, third as well. It comes down to taste, but I think my buds would prefer a separate method. Ryan — Sent from Mailbox for iPhone On

Django sprint

Have the details of the sprint at BitBucket / Atlassian been confirmed? If so, I'm wanting to participate, and am looking for where to RSVP, etc. -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to

Re: Model Docs Questions

On Mon, Nov 4, 2013 at 9:31 AM, Andre Terra wrote: > > On Sun, Nov 3, 2013 at 5:13 PM, Cody Scott wrote: >> >> 3 >> Why do Q objects use '&', '|' and '~' for AND, OR and NOT when python uses >> 'and', 'or' and 'not'? >> source > > > Because Python

Re: App-loading reloaded - running code at startup

On Mon, Dec 30, 2013 at 10:16 AM, Aymeric Augustin wrote: > The real question — is requiring django.setup() acceptable? Explicit is > better than implicit, after all… It's probably obvious to others, but where would that `django.setup()` be? -- You

Re: 1.7 Schema migrations and AUTH_PROFILE_MODULE / get_profile() deprecation

On Thu, Jan 23, 2014 at 7:24 PM, Russell Keith-Magee < russ...@keith-magee.com> wrote: > > On Fri, Jan 24, 2014 at 9:05 AM, Brian Neal wrote: > >> Hello, >> >> The deprecation timeline says this about Django 1.7: >> >> "The AUTH_PROFILE_MODULE setting, and the get_profile()

Re: 1.7 Schema migrations and AUTH_PROFILE_MODULE / get_profile() deprecation

On Thu, Jan 23, 2014 at 7:42 PM, Russell Keith-Magee < russ...@keith-magee.com> wrote: > > > On Fri, Jan 24, 2014 at 9:33 AM, Ryan Hiebert <r...@ryanhiebert.com>wrote: > >> >> >> >> On Thu, Jan 23, 2014 at 7:24 PM, Russell Keith-Magee < >>

Re: 1.7 Schema migrations and AUTH_PROFILE_MODULE / get_profile() deprecation

On Thu, Jan 23, 2014 at 11:25 PM, Carl Meyer <c...@oddbird.net> wrote: > Hi Ryan, > > On 01/23/2014 09:50 PM, Ryan Hiebert wrote: > > Assuming that the changes from the deprecation policy are in trunk now > > that the alpha has landed, any use of the AUTH_PROFILE_MO

Re: [GSoC] Switching to Jinja2 proposal

On Fri, Feb 21, 2014 at 3:22 PM, Camilo Torres wrote: > - Then, we can create dummy implementations of `render_to_response` (and >> all >>other functions) that checks the template extension and dispatch to >>corresponding function from `django.dtl` or `jinja2`.

Re: APPEND_SLASH skip per URL or per base_uri

In your example, APPEND_SLASH On Thu, Mar 13, 2014 at 4:12 PM, Val Neekman wrote: > Some JavaScript frameworks(e.g. AngularJS) remove the ending slash before > making a request. > If APPEND_SLASH = True, then the API would not be consumable by AngurlarJS. > > Would it be a

Re: APPEND_SLASH skip per URL or per base_uri

). On Thu, Mar 13, 2014 at 4:19 PM, Ryan Hiebert <r...@ryanhiebert.com> wrote: > In your example, APPEND_SLASH > > > On Thu, Mar 13, 2014 at 4:12 PM, Val Neekman <v...@neekman.com> wrote: > >> Some JavaScript frameworks(e.g. AngularJS) remove the ending

Re: APPEND_SLASH skip per URL or per base_uri

On Fri, Mar 14, 2014 at 10:07 AM, Val Neekman wrote: > > Localized solution is fine, but when I saw the number posts from people > who were trying to find a solution to this, I thought, perhaps it would be > a nice little enhancement to the APPEND_SLASH functionality. > You

Re: Migrations in Django 1.7 make unit testing models harder

> > I thought TextField did have a default, the empty string? > > Like every other field, the "default default" is None (NULL). -- You received this message because you are subscribed to the Google Groups "Django developers" group. To unsubscribe from this group and stop receiving emails from

Re: 1.7 release status (RC2 coming soon)

My opinion is worth less than 2c, but I’m inclined to agree with the dissent. It seems to me that its easy enough to install the very latest from the github repository versus from a tarball, so leaving RC versions to actually be candidates for release seems like a reasonable idea. Were we

Re: 1.7 release status (RC2 coming soon)

> On Jul 25, 2014, at 12:22 AM, Ian Kelly wrote: > > It seems to me that a new release would be useful to have for the > reasons given, but it should be called what it is: a beta version, not > an RC. > I agree, but I don’t think that releasing a beta after an RC makes

Re: 1.7 release status (RC2 coming soon)

> On Jul 25, 2014, at 10:06 AM, Ian Kelly <ian.g.ke...@gmail.com> wrote: > > On Fri, Jul 25, 2014 at 7:12 AM, Ryan Hiebert <r...@ryanhiebert.com> wrote: >> >>> On Jul 25, 2014, at 12:22 AM, Ian Kelly <ian.g.ke...@gmail.com> wrote: >>> &g

Re: 1.7 release status (RC2 coming soon)

> On Jul 25, 2014, at 2:22 PM, Andre Terra <andrete...@gmail.com> wrote: > On Fri, Jul 25, 2014 at 12:17 PM, Ryan Hiebert <r...@ryanhiebert.com> wrote: > > I see two benefits. One is that users who are interested in testing > > aren't necessarily going to think t

Re: [GSOC] Weekly update

> On Aug 6, 2014, at 7:14 AM, Collin Anderson wrote: > > Communication. > > From a purist theoretical perspective, there shouldn't be any argument - the > data we're talking about is a list. Lists have homogeneous elements; Tuples > have heterogeneous elements, but

Re: 1.7 release?

> On Aug 19, 2014, at 12:02 PM, Andrew Godwin wrote: > > At this point, we're still a few weeks away from a final release at best. > The release itself is pretty stable; the problem is that migrations are so > complicated and provide such a large new feature surface that

Re: HTTP/2 and WSGI

Being the idealist I am, I hope we can find a way to rid ourselves of the pain of cgi. I'd be more than willing to help, but my help would probably be more of a hindrance because of the limited exposure I've had with developing wsgi. However, I did want to register my support to those looking

Re: Settings: lists or tuples?

> On Dec 17, 2014, at 5:48 PM, Carl Meyer wrote: > > On 12/17/2014 04:39 PM, Russell Keith-Magee wrote: >> >> I agree that lists are preferable to tuples. >> >> One option for handling existing projects might be to define our own >> subclass of list that defines __add__,

Re: Settings: lists or tuples?

> On Dec 17, 2014, at 6:12 PM, Carl Meyer <c...@oddbird.net> wrote: > > On 12/17/2014 04:57 PM, Ryan Hiebert wrote: >>> >> What would __iadd__ do in this subclass? Would it behave like tuple and >> create a new DjangoList, or would it behave like

Re: Settings: lists or tuples?

> On Dec 18, 2014, at 12:49 AM, Russell Keith-Magee > wrote: > > So - I retract my suggestion - I think I can live with just documenting this > as a backwards compatibility. Sounds good. In case anyone is interested, I made a pull request (not complete) with an

Re: docstring verbs

I follow the PEP for at least 3 reasons: 1. The PEP. I like using the Python standards. 2. It matches a (the primary?) widespread convention for commit messages. 3. Imperative verbs tend to also be the shortest of the tenses, so that’s a nice side-effect. Ryan > On Jan 23, 2015, at 11:27 AM,

Re: About Class Based views

As a anecdotal data point, when I getting started with class-based views I put everything into get_context_data method, because that’s where I thought the code for constructing the context should go. I eventually figured out that I should probably never override that method, but rather override

Re: Django Admin New Look

In the likely event that it won’t be back ported to 1.8, can you release it on PyPI? Actually, you may wish to do that anyway for older versions. I use setup.py to install my django app, so it’s difficult to add direct github url dependencies. (It takes a flag when installing with pip, which

Guessable entry points

https://github.com/django/django/pull/4588 I this PR I suggest to add a `django` entry point that is identical to `django-admin`, and a `__main__.py` that also is a mirror of `django-admin`. There’s also related discussion at

Re: Proposal: Manually login without authenticate

> On May 22, 2015, at 3:07 PM, Carl Meyer wrote: > > Hi Paulo, > > On 05/22/2015 01:49 PM, Paulo Gabriel Poiati wrote: >> I understand your points Carl, but I'm more inclined to think about the >> average django developer and the new comers. Most people don't know or >> don't

Re: 1.9 release planning

An alternative would be for the LTS to be the second-to-last minor release before a major version bump. I'm also ignoring the transition for the sake of hypotheticals. I'm also assuming that 2.2 is the last release of the 2.X series. 2.1 - 0 mos - (LTS) No features dropped 2.2 - 8 mos - No

Re: 1.9 release planning

Given the negative reaction to quick deprecation of LTS releases, I also now most prefer Loïc's proposal. It's semver with a little extra to help folks out. I'd also most prefer seeing 1.9 being changed to 2.0 if this proposal were accepted, but that is not a strong opinion given that I am not

Re: Pre-DEP: community support of unmaintained versions of Django

> On Aug 24, 2015, at 5:37 PM, Carl Meyer wrote: > >> Any ideas on alternative ways to tackle this? I'm officially stuck. > > I'm afraid I don't have any solution to offer, other than embracing the > "abstract vs concrete" dependencies distinction, and accepting the fact >

Re: re-thinking middleware

Sent from my iPhone > On Jan 7, 2016, at 20:50, Carl Meyer wrote: > > Hi all, > > Back at the Django Under the Hood sprints in November, Florian and I > started batting around some ideas for fixing some of the problems with > the existing middleware abstraction. Florian put

Re: re-thinking middleware

> On Jan 8, 2016, at 11:35 AM, Aymeric Augustin > wrote: > > +1 > > Great work. > > The only (and minor) concern I have is about allowing function-based > middleware factories to return None. > > In the spirit of “there should be only one way to do it”,

Re: re-thinking middleware

> On Jan 8, 2016, at 11:57 AM, Ryan Hiebert <r...@ryanhiebert.com> wrote: > >> On Jan 8, 2016, at 11:35 AM, Aymeric Augustin >> <aymeric.augus...@polytechnique.org> wrote: >> >> In the spirit of “there should be only one way to do it”, I would requir

Re: re-thinking middleware

> On Jan 8, 2016, at 12:38 PM, Carl Meyer wrote: > > Yes, you and Ryan are absolutely right, allowing `None` was a mistake > and I've removed it from the spec. For function-based middleware, > there's also the option to simply return the ``get_response`` callable > you were

Re: re-thinking middleware

> On Jan 8, 2016, at 12:53 PM, Carl Meyer <c...@oddbird.net> wrote: > > On 01/08/2016 11:48 AM, Ryan Hiebert wrote: >> >> While class-based middleware factories couldn't just do the same thing >> in the __init__ method, they could do that in a __new__ method i

Re: Feedback on Django Channels

> On Mar 18, 2016, at 9:58 AM, Andrew Godwin wrote: > > routing = [ > route("http.request", ViewConsumer), > route("websocket.connect", path="^chat/(?P[^/]+)/$", ChatConnect), > route("sms.receive", sender="+44(?P[0-9]+)$", > UkSmsConsumer), >

Re: [GSOC] Original Idea/Seeking Mentor: Conditions API (Related to Auth)

> On Mar 16, 2016, at 11:55 AM, Connor Boyle wrote: > > I'm hoping to add a feature that I've thought Django has needed for a long > time, and thought that Google Summer of Code would be an excellent > opportunity for it. Basically, it would be an API for defining

Re: Django template 'if ... is' feature design

The `is` operator in Python checks for identical objects. A string is not guaranteed to be exactly the same object as another string (in this example "True" is not the same object (bytes in memory) as the second "True", so Python rightly sees that they are not the same object. True, False, and

Re: Django template 'if ... is' feature design

> On Apr 7, 2016, at 5:13 PM, Stephen Kelly wrote: > > Daniel Chimeno wrote: > >> I think we should give an emphasis on this because are going to cause >> problems to some people. > > Yes, this is why I suggested in my original mail that the feature needs more > design

Re: Making Django more PaaS-friendly

I'd love to see better support for PaaS configuration, especially 12-factor. We use Heroku, and I've been directly exposed to the challenges and had to come up with some of my own solutions. Here's some thoughts I have on the matter, in no particular order. The SECRET_KEY needs to _not_ be

Re: My Take on Django Channels

Thank you, Mark, for starting this discussion. I, too, found myself simply accepting that channels was the right way to go, despite having the same questions you do. I realize this shouldn't be, so I've chimed in on some of your comments. > On May 5, 2016, at 2:34 PM, Mark Lavin

Re: My Take on Django Channels

uple things. I totally get it. Focus on the Jedi, not the Padawan. > > On Thursday, May 5, 2016 at 4:21:59 PM UTC-4, Ryan Hiebert wrote: > [snip] Anything that doesn't use celery's `acks_late` is a candidate, because > in those cases even Celery doesn't guarantee delivery,

Re: Withdrawing Channels from 1.10

Thank you, Andrew, for your hard work. Channels is an exciting new feature, and I'm glad that you're bringing it together. You're doing an excellent job. -- You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group. To

Re: DEP pre-proposal for a simpler URLs syntax.

Loving this work! There's one thing that Flask's routing syntax does that strikes me as backward, and it may be a good idea to consider reversing it: the converter indication. I suggest that rather than it being `` it should be ``, because the converter is very similar to a type, and we have

Re: Should SECRET_KEY be allowed to be bytes?

> On Dec 22, 2016, at 2:32 PM, Tim Graham wrote: > > Perhaps times have changed but I forgot to mention that 8 years ago Malcolm > rejected the idea that more randomness is required in the secret key. From > the reporter of #9687: You're right, and I knew that, but

Re: Should SECRET_KEY be allowed to be bytes?

> On Dec 22, 2016, at 5:22 PM, Adam Johnson wrote: > > +1 to what Aymeric wrote. I was just drafting an email with a similar > argument about how it's hard to manage pure bytes in config management > systems that write to env vars, that's why ascii strings are so useful. >

Re: A New Design for the "Congratulations!" Page

On Tue, Apr 18, 2017 at 11:27 AM Daniele Procida wrote: > On Tue, Apr 18, 2017, Tim Allen wrote: > > >It struck me that this page is valuable real estate > > Yes it is! Firstly, I think that both your idea and design are excellent > and I approve. > >

Re: Setting defaults in the DB to support zero-downtime migrations

I've found other places where things are fiddly for production migrations as well. Migrating a nullable to a non-nullable field is one of a range of cases where the migration cannot be run until the code has been fully deployed to no longer write nulls to the database. A similar case, that's even

Re: Django ORM Handling of Reverse Relationships and Multi-Value Relationships

It's a subtle difference between how a single filter works and two filters work together over to-many relationships. Here's a writeup that I found helpful: https://blog.ionelmc.ro/2014/05/10/django-sticky-queryset-filters/ On Thu, Mar 29, 2018 at 4:26 PM, Andrew Standley

Re: Request to reconsider ticket #27910: using an Enum class in model Field choices

I would also love to see a decent way to use enums as choices. The translation issues seem the stickiest to me, but I'm kinda hoping we can come up with something reasonable. I'm a heavy user, but mostly a lurker on this list, but +1 from me for what it's worth. Ryan On Mon, Dec 31, 2018, 17:41

Re: revisiting the Python version support policy

I don't feel like my voice should have much weight, but I think that the policy as written is better. Debian aims to be stable long term, and for us to match Debian, especially when not in our LTS releases, seems excessive to me. On Mon, Jan 21, 2019 at 9:56 AM Tim Graham wrote: > When deciding

Re: Django 2.2 release candidate 1 released

That won't be possible, Django 2.2 has been feature-frozen for a while now. You might want to follow the following issue which is related to what you're suggesting. https://code.djangoproject.com/ticket/10227 On Wed, Mar 20, 2019 at 10:52 AM Mohammad Etemaddar < mohammad.etemad...@gmail.com>

Re: Show applied datetime in showmigrations

I personally like the option better. This seems like a different use-case than I'd normally expect from a verbosity level. On Sun, Feb 3, 2019 at 12:45 PM Tim Schilling wrote: > Not changing the default output makes a lot of sense. I initially was > wondering if it should have its own option.

Re: revisiting the Python version support policy

On Thu, Jan 24, 2019 at 11:29 AM Tim Graham wrote: > Let's hear from people who find the current Python support policy > insufficient for their needs. > Agreed. I'm not one of them, dropping 3.5 support disadvantages me in no way. I don't use it in production or in development, and would have

Re: revisiting the Python version support policy

On Thu, Jan 24, 2019 at 10:55 AM Adam Johnson wrote: > So, phrasing... maybe... as a draft: "Typically, we will support a Python >> version unless it will be end of life before the corresponding version of >> Django is outside of mainstream support. For example, Python 3.5 security >> support

Re: [Feature Request][Model, ORM] Disabling a field before removal to support continuous delivery

On Mon, Jun 24, 2019, 21:29 Dan Davis wrote: > > Some questions: > >- How does the "safe" field of migrations work with other migrations >related commands, such as squashmigrations? It seems to me that only >migrations that share the same value of "safe" could be squashed. > > If

Re: Thoughts on Django Model attribute (descriptor) inheritance.

I'm not sure what the reasoning was, but it does ring some bells for me, as I think this sounds like the case of the of the issue discovered in https://code.djangoproject.com/ticket/28198. Hopefully that's a correct connection, and I'm not sending you chasing something irrelevant to your current

Re: [Feature Request][Model, ORM] Disabling a field before removal to support continuous delivery

I'm not sure about the solution you mentioned, but the problem you mention is one that I definitely do deal with. At my work we have been happy with using a "safe" migrate command that only runs migrations that are marked as safe to run before the deployment happens, to address exactly this kind

Re: Migrations in Django 1.7 make unit testing models harder

On Sat, Sep 14, 2019 at 10:09 AM Dylan Young wrote: > why do you need the model changes without the migrations? I.e. why would > you want to be in a state that's inconsistent between the ORM and the DB? > Is it just so you can recover more easily if something goes wrong? > I expect that its to

Re: Migrations in Django 1.7 make unit testing models harder

On Sat, Sep 14, 2019, 12:44 Adam Johnson wrote: > (Fixed Ryan's link: https://github.com/aspiredu/django-safemigrate ) > Doh. Thanks. > -- You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group. To unsubscribe

Re: Stop QuerySet repr from executing queries

On Thu, Oct 10, 2019 at 10:50 AM Matt wrote: > > I think we ought to reconsider the behavior of repr on QuerySets. I'm of > the opinion that we should scrap it completely. It could be replaced by > something that generates the SQL that would be executed (although that may > be tricky), or some

Re: Stop QuerySet repr from executing queries

On Fri, Oct 11, 2019 at 9:29 PM Matt wrote: > I think it should just show instead of . > I agree, I think this makes the most sense. I think it can be argued that QuerySet should be consistent with [RawQuerySet, > which just uses a string of the query in the repr] > I can see the argument I

Re: Use "raise from" where appropriate, all over the codebase

> > I think the conclusion should be to ask for a change in Python, not > Django. The rule "if an exception is raised explicitly from an except > clause then it is considered raised-from" seems simple enough to me. > I really like that. It makes perfect sense, and I can't think of a case where

Re: Generate JWTs with Django

On Sun, Apr 26, 2020 at 8:29 AM James Bennett wrote: > JWTs are an absolute security nightmare. Some of the Django security > team have heard me rant on this topic already, but: there is no such > thing as a safe JWT implementation, because there are fundamental > flaws in the design of JWT that

Re: Generate JWTs with Django

On Sun, Apr 26, 2020 at 9:53 PM James Bennett wrote: > On Sun, Apr 26, 2020 at 8:46 AM Adam Johnson wrote: > > The short summary is: JWT is over-complex, puts too much power in the > attacker's hands, has too many configuration knobs, and makes poor > cryptographic choices. This is why we see

Re: Rename request.GET and POST, and lowercase COOKIES, FILES, and META

It seems that many of the people who want a different name are not understanding that this name is going to be exclusively for dealing with POST forms that are using the standard `x-www-form-urlencoded` media type*, *and won't be attempting to interpret any other media type. Some generic names,

Re: Rename request.GET and POST, and lowercase COOKIES, FILES, and META

I can agree that there might be better things to do, but this falls into the category of warts for me, so I'm +1. Having the name be pythonic is a plus, but avoiding a beginner footgun is better. And I believe the conventions used did indeed come from PHP. There even used to be a parallel to

Re: Proposal: Drop dependency on pytz in favor of zoneinfo

I'm almost exclusively a lurker on this list, but a constant user, and have in the past a keen observer in the datetime discussions. I think you've made your case well. I'd be happy for this migration from Django to be as aggressive as the maintainers are comfortable. I agree that doing step 1 at

Re: Integrating migrations with the check framework

This is an interesting discussion that is separate from, but related to, django-safemigrate, which we use to separate which migrations may run before or after deployment. I intend follow along with this discussion, to see if there are reasonable ways to identify when these zero-downtime operations

Re: Revisiting Python support for after Django 3.2 LTS

> On Feb 2, 2021, at 03:42, Carlton Gibson wrote: > > Possibly we could support Python 3.7 just for Django 4.0, as an exception, > leveraging the "typically" in the existing policy, and clearly stating what > we were doing. > > Can I ask for (limited) thoughts just on that smaller

Re: Revisiting Python support for after Django 3.2 LTS

> On Feb 2, 2021, at 11:29 AM, Carlton Gibson wrote: > > That is a good question. Do we take the X in an X.Y series in the SemVer way. > I’ve always thought not When we switched the version scheme ahead of 2.0, we wanted it to roughly match SemVer. We’ve strategically weakened it in some

Re: Do people actually squash migrations?

You’d run the migrations that you manually created with --fake. My experience also corroborates the idea that squashmigrations may be unsuitable for many situation that are similar to mine, where I am able to fully control the full set of places that the code is deployed. Ryan > On May 12,

Re: Drop CSRF middleware from the settings template

On Tuesday, April 18, 2023 at 8:34:14 AM UTC-5 Stratos Moros wrote: [...] In my experience there are legitimate cases for setting SameSite=None, especially concerning iframes. Specifically, when developing a web app intended to be embedded as an iframe by a different top-level origin, you

Drop CSRF middleware from the settings template

I've recently been working with other new frameworks, particularly Remix. Coming from Django, which has had excellent CSRF for many years, one of my first questions was how to handle CSRF protection. And the response I got lead me to the "Lax" SameSite cookie parameter, and that I really

Re: Drop CSRF middleware from the settings template

I've been working on setting up a new project that's never going to see the light of production, so I went down the road of just disabling CSRF for that purpose. I notably found that the Django admin still requires CSRF, even when the middleware has been removed from the MIDDLEWARE setting. I