Django sprint

[Ryan Hiebert]

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 django-developers@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

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

[Ryan Hiebert]

> 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 
> iterations (as few as one).
> 
> The only reason for a stream-capable middleware to access response.content 
> explicitly in this case is for improved efficiency when the user doesn't care 
> about streaming the response. I think GZipping the whole content is probably 
> more efficient than GZipping chunks of it.

Tai, thanks for your response.

I was more than a bit confused on how the response object is normally consumed, 
which caused me to write a message that made me look more than a bit silly.

I see that a single-string iterator is a perfectly good way to do things, thank 
you for helping me see it. It seems obvious in hindsight.

Ryan

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: Perception of attitude in tickets

[Ryan Hiebert]

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 closed by a committer 
> then they should get an intermediate page pointing them to this group and 
> asking them to confirm before the ticket is reopened.
> 
> I don't know if Trak is customisable to that extent, or if this would even be 
> effective, but it would be nice to get something out of this.

If Trak is customizable enough, it might be good to have the ticket template 
always have a link to the Google Group. Label it "Google Group/Mailing List", 
and then a comment that says "let's move this discussion over to the mailing 
list" can be a simple click on a link, and you're at the mailing list. 
Hopefully, that could help to eliminate the overhead associated with getting 
the discussion to the right place to make progress.



smime.p7s
Description: S/MIME cryptographic signature

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

[Ryan Hiebert]

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 Thu, May 16, 2013 at 12:08 AM, Shai Berger  wrote:

> Two notes:
> 1) I think it is better to leave the *args, **kw on the manager methods; 
> since 
> they are just forwarding to the qset anyways, there's no harm in that, and it 
> makes them more "future proof" (i.e. you wouldn't need to change them next 
> time you change the interface of the qset methods).
> Case in point:
> 2) I'd like to add an argument to the first() method, something like 
>def first(self, only=True):
> Where the sense of only=True is that if there is more than one object to get, 
> that's an error (MultipleObjects, like in get).
> As this feature was mainly designed to replace the anti-pattern,
> try:
>   x = qset.get(...)
> except DoesNotExist
>   x = None
> I think the default for "only" should indeed be True. Other people may 
> disagree. I think without at least the ability to set only=True, this feature 
> is essentially broken -- since it is the equivalent of
> try:
>   x = qset[0]
> except IndexError
>   x = None
> it encourages people to give up an integrity check.
> My 2 cents,
>   Shai.
> On Wednesday 15 May 2013, Selwin Ong wrote:
>> I've updated the first() and last() to not accept any arguments. Please
>> review it and let me know if there's anything else I need to change.
>> Hopefully this can get merged in during the sprints and make it into 1.6
>> :).
>> 
>> The pull request is here: https://github.com/django/django/pull/1056
>> 
>> Best,
>> Selwin
>> 
>> On Monday, May 13, 2013 8:12:35 PM UTC+7, Michal Petrucha wrote:
>> > > > I initially modeled "first()" and "last()"'s behaviors to mimic
>> > > > "latest()", but in this new pull request, you can pass multiple field
>> > 
>> > names
>> > 
>> > > > into "first()" and "last()" so it behaves like "order_by()". It's
>> > > > more flexible and requires less typing, but I wonder if we should
>> > > > just get
>> > 
>> > rid
>> > 
>> > > > of the optional field arguments and rely on "order_by" for ordering.
>> > 
>> > "There
>> > 
>> > > > should be one-- and preferably only one --obvious way to do it".
>> > > 
>> > > Considering "There should be one-- and preferably only one --obvious
>> > > way
>> > 
>> > to
>> > 
>> > > do it", I definitely prefer to rely on order_by to do the ordering, not
>> > 
>> > on
>> > 
>> > > first.
>> > > 
>> > > .order_by('name').first()
>> > > 
>> > > is clear and readable in my opinion.
>> > 
>> > My thoughts exactly, we already have one method that does ordering, I
>> > don't think it is necessary to make these methods incorporate that
>> > functionality. If we did, we might argue that other QuerySet
>> > operations could be supported as well and that would just result in a
>> > bloated API. Especially if there's no performance gain (the QuerySet
>> > would be cloned anyway), and it only saves a few lines of code.
>> > 
>> > Also, skimming through this thread, I think there was a consensus on
>> > first() and last() not taking any ordering arguments, i.e. the first
>> > 
>> > proposed syntax:
>> > .filter(last_name__startswith='b').order_by('last_name').first()
>> > 
>> > Michal
> -- 
> 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 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 http://groups.google.com/group/django-developers?hl=en.
> For more options, visit https://groups.google.com/groups/opt_out.

-- 
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 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 http://groups.google.com/group/django-developers?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Settings: lists or tuples?

[Ryan Hiebert]

> 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__, __iadd__, and __radd__ such that it
>> will accept a tuple, converting to a list, and raise a DeprecationWarning;
>> in a later version, we can replace that subclass with a simple list. We
>> wouldn't document this class, and it would only be used in
>> global_settings.py. This would cover the most common use case (adding
>> something to a default setting), and provide a migration path. Thoughts?
> 
> FWIW, I think the subclass-of-list approach is neat enough, I'd be in
> favor of going ahead and doing this with that approach, if someone's
> motivated to write the patch.
> 
What would __iadd__ do in this subclass? Would it behave like tuple and
create a new DjangoList, or would it behave like list and extend the
original list?

I’m interested at taking a whack at it, though I can imagine somebody else
getting it done faster.

Ryan

-- 
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 http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/D0921E76-49EC-4750-8013-DE117AEC5544%40ryanhiebert.com.
For more options, visit https://groups.google.com/d/optout.

Re: Settings: lists or tuples?

[Ryan Hiebert]

> On Dec 17, 2014, at 6:12 PM, Carl Meyer  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 list and extend the
>> original list?
> 
> For maximum backwards-compatibility during the deprecation period, if
> it's called with a tuple, it should create and return a new tuple, I
> think. That way the deprecation warning only gets fired once for a
> particular setting, which is all that's needed, even if they go and add
> to the resulting value several more times.
> 
> If it's called with a list, it should behave as a normal list does.
> 
> And before you get too far, you may want to wait and see if any other
> core devs step in to tell me I'm crazy and there's no way we should have
> a deprecation path just to switch some settings from tuples to lists.
> 
> (I'm only in favor of it myself because I think in practice the impact
> will be small.)

Thanks for the warning, and your solution makes perfect sense to me.
I’m gonna go ahead and keep working on it for fun, but I understand
that we might find that it’s not worth the deprecation period, and
I’m OK with that.

Thinking about it a bit, I’m going to see if just watching for tuple
and returning a tuple, otherwise returning a native list might be
sufficient.

Ryan

-- 
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 http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/8B6067E2-43DF-454A-BC0C-3928239F7C5B%40ryanhiebert.com.
For more options, visit https://groups.google.com/d/optout.

Re: Settings: lists or tuples?

[Ryan Hiebert]

> 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 implementation of a ‘ConfList’ that could detect operations with 
tuples. Scrapping it doesn’t bother me, it was a fun challenge. Perhaps someone 
else will think it’s interesting too.

https://github.com/django/django/pull/3752

-- 
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 http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/9DB0375E-4772-43A9-9936-F137B616211E%40ryanhiebert.com.
For more options, visit https://groups.google.com/d/optout.

Re: docstring verbs

[Ryan Hiebert]

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, Tim Graham  wrote:
> 
> The current version of our style guide [1] recommends to use "action verbs" 
> (Checks instead of Check). However this contradicts PEP 257 (Docstring 
> Conventions) [2]. The current code mixes these two forms. Claude advocates to 
> follow the PEP [3]. Anyone care to comment on the historical reason we 
> deviated from it and whether or not we should switch?
> 
> [1] 
> https://docs.djangoproject.com/en/dev/internals/contributing/writing-code/coding-style/#python-style
> 
> [2] ​https://www.python.org/dev/peps/pep-0257/
> 
> [3] https://code.djangoproject.com/ticket/24175
> 
> -- 
> 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 http://groups.google.com/group/django-developers 
> .
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/django-developers/a37f3514-1d2e-46b0-b104-c020166b8125%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 http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/5EB6D262-380E-4401-9A68-B57F63E09811%40ryanhiebert.com.
For more options, visit https://groups.google.com/d/optout.

Re: About Class Based views

[Ryan Hiebert]

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 get() or 
post(), etc, and _call_ it with the context I desired.

Having some better documentation of what the Right Way to subclass these views 
would have been a great help. The fact that the documentation is fragmented 
because of the mixin inheritance definitely makes understanding how to use 
those generic class based views more challenging.

I’m not sure what magical visualization would make the proper override methods 
obvious, but if there was one, I think it would definitely have helped me grok 
how to use class-based views effectively.

> On Mar 17, 2015, at 6:40 PM, Curtis Maloney  
> wrote:
> 
> No... I'm well aware of CCBV, and think it's a great tool... however, I had 
> in mind something that would more clearly show (a) the stratified layers of 
> interface, and (b) the typical call paths [through the layers] of the various 
> Views and Mixins.
> 
> Such a visualisation, I feel, would help many people more readily grasp how 
> all the pieces fit together, and where to hook in to get the results they 
> want.
> 
> --
> C
> 
> 
> On 18 March 2015 at 10:19, Russell Keith-Magee  > wrote:
> 
> On Wed, Mar 18, 2015 at 5:38 AM, Curtis Maloney  > wrote:
> I found when taking the CBGV session in MelbDjango School, it was best to 
> approach teaching CBV as an exercise in Interfaces.
> 
> Once the students were familiar with writing basic views, and the patterns 
> therein, much of CBGV became "obvious", and the lesson focused more on the 
> power of interfaces.
> 
> As I've said many times on IRC I'd love a site that shows the layers of 
> interfaces in various CBGV so it becomes clearer how they interact.  
> Unfortunately, I don't have the time or skills to pull this off :/
> 
> 
> You mean something like:
> 
> http://ccbv.co.uk 
> 
> or did you have something else in mind?
> 
> Yours,
> Russ Magee %-)
> 
> -- 
> 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 http://groups.google.com/group/django-developers 
> .
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/django-developers/CAJxq848-7%3D%2BL_foUTvkH3rDw1n_c-zDbpqUtkHdVA0wKJbY3_w%40mail.gmail.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 http://groups.google.com/group/django-developers 
> .
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/django-developers/CAG_XiSBb3iT9RXS87HHY2WJekR53LuDbTpCZ_sW3%3DhmyRA-sTA%40mail.gmail.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 http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/E5DF520E-6EED-4E2B-8230-20CF6D77EF95%40ryanhiebert.com.
For more options, visit https://groups.google.com/d/optout.

Re: Django Admin New Look

[Ryan Hiebert]

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 isn’t 
enabled in my environment).

Ryan

> On Mar 18, 2015, at 1:34 PM, elky  wrote:
> 
> Awesome!! Sounds fantastic. Thanks, Aymeric
> 
> On Monday, 16 March 2015 22:24:39 UTC+5, Aymeric Augustin wrote:
> For what it's worth, I've deployed your theme on an internal application and 
> received positive feedback from users. I don't receive feedback often, let 
> alone positive feedback.
> 
> Which branch is better to open pull request? Theme works perfectly in 1.8b2 
> but seems it's too late to catch the last train.
> 
> Thanks
> 
> 
> -- 
> 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 http://groups.google.com/group/django-developers 
> .
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/django-developers/b0d28a51-e9c8-4725-a3b5-e234d7996f56%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 http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/DA5CF423-0EA0-4B08-A006-5BE82DD00448%40ryanhiebert.com.
For more options, visit https://groups.google.com/d/optout.

Guessable entry points

[Ryan Hiebert]

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 https://github.com/django/django/pull/3861 


There’s precedent for using these as the primary methods of use all over the 
place. Flask, in particular, uses both the `flask` command as well as `python 
-m flask`. Celery also uses the `celery` command as well as `python -m celery`.


I see value in adding these endpoints that are more easily guessable. However, 
there’s a cost too, the cost of having more than one way to do it. We already 
have `django-admin` and `django-admin.py`, would adding these obvious entry 
points give too many options?

Ryan

-- 
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 http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/90DC7B87-35F5-4B77-93EA-7734DA31EA86%40ryanhiebert.com.
For more options, visit https://groups.google.com/d/optout.

Re: Proposal: Manually login without authenticate

[Ryan Hiebert]

> 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 want to know what an Authentication Backend is, they just want to
>> write their app. That is why I don't like exposing this kind of detail
>> in the client code. I mean, we can add an optional param to
>> login (backend) for people like you and me but IMO it shouldn't
>> be mandatory and we should fallback to the backend iteration if it isn't
>> specified.
> 
> Logging a user in without authenticating them first is an advanced
> technique with serious security implications. If someone "doesn't know
> or doesn't want to know what an Authentication Backend is," then they
> have no business doing this, and we should absolutely make it very hard
> for them to do it without learning about authentication backends first.
> 
> Which backend is persisted with the user in the session is not a minor
> implementation detail. It's critical information, because it determines
> how and from where that user will be loaded on future requests, which
> could have wide-ranging effects on their permissions and authorization.
> 
> I agree with you that the current system of annotating the user object
> with an attribute that usually isn't present is bad API, and that it
> would be good to have a supported, documented API for this use case. But
> I strongly disagree with you that the backend is an implementation
> detail which should be hidden in this API. The backend should be more
> visible in this API than it is now, not less visible.

I agree completely.

The couple times I've found myself muddling through creating an auth backend, 
I've had a hard time figuring out what needs to go in the login view, and what 
should be in the authentication backend. I think that making it clearer what 
the distinction is between login() and authenticate() is would help that 
immensely, and making it clear that the backend need not be set by authenticate 
would also make it clearer.

Ryan

-- 
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 http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/500FF35F-4039-4BF6-B36A-5129C48235C8%40ryanhiebert.com.
For more options, visit https://groups.google.com/d/optout.

Re: 1.9 release planning

[Ryan Hiebert]

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 features dropped
3.0 - 16 mos - Drop all features deprecated by 2.1
3.1 - 24 mos - (LTS) No features dropped
3.2 - 32 mos - No features dropped
4.0 - 40 mos - Drop all features deprecated by 3.1
4.1 - 48 mos - (LTS) No features dropped 

It would mean that features deprecated before an LTS cannot be dropped until 
two versions after the LTS, but it fits semver pretty well, and doesn't speed 
up our deprecation removal.

I'd argue for a major version dropping _all_ deprecated features. This has the 
downside of speeding up our removal process in the last version of a major 
release, and it encourages people to stay longer on the release previous, since 
they won't have as much opportunity to fix them. It would also mean that 
features deprecated in the last minor version of a major version line would 
need to skip the pending deprecation warnings.

If it were acceptable to do that, then I'd argue for the LTS to be the _last_ 
in a major version line, rather than the second-to-last. That would probably be 
my overall preferred, though I do recognize the previously mentioned drawbacks. 
Anything deprecated in an LTS in that case would skip the pending deprecation 
warning, and go straight to the deprecation warning. The deprecation timeline 
would then look like this:

2.2 - 0 mos - (LTS) No features dropped
3.0 - 8 mos - All deprecations, including the LTS deprecations, are removed
3.1 - 16 mos - No features dropped
3.2 - 24 mos - (LTS) No features dropped
4.0 - 32 mos - All deprecations, including the LTS deprecations, are removed
4.1 - 40 mos - No features dropped
4.2 - 48 mos - (LTS) No features dropped


I think those are probably the two best LTS support release schedules that 
follow semver.

Ryan

-- 
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 http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/F36EA2A5-4D9F-489C-82B9-7AE4D93B258F%40ryanhiebert.com.
For more options, visit https://groups.google.com/d/optout.

Re: 1.9 release planning

[Ryan Hiebert]

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 familiar with 
the pain involved with renaming the deprecation warnings.

Sent from my iPhone

> On Jun 15, 2015, at 08:54, Loïc Bistuer  wrote:
> 
> I'm -0 (borderline -1) on that proposal. I don't think we should compromise 
> on our historical commitment of deprecating over 2 releases, especially since 
> it's aligned with the policy of Python itself and much of the ecosystem.
> 
> It should be as easy as possible for 3rd-party apps to straddle 2 LTS 
> releases, but when it comes to user projects we should make it as easy as 
> possible to keep up with the latest stable. Sticking to LTS versions deprive 
> you from up to three years of innovation in Django, IMO it's only appropriate 
> for projects in maintenance mode. Our current policy allows you to take 
> advantage of new features right away while having almost a year and a half to 
> deal with deprecations.
> 
> The only additional overhead of my counterproposal is an extra 8 months of 
> support for features deprecated in an LTS for a total of 16 months. 
> Considering non-LTS releases require between 16 months and 24 months I think 
> it's very manageable.
> 
> Regarding timeline for adoption, I prefer switching right away but I'm also 
> happy with a 2.1 > 3.0 switch, so whatever is more popular. Also it shouldn't 
> get lost because regardless of the SemVer decision we'll need to update 
> RemovedInDjango21Warning in master.
> 
>> On Jun 15, 2015, at 19:37, Josh Smeaton  wrote:
>> 
>> I really like Ryan's second proposal (quoting here again):
>> 
>> 2.2 - 0 mos - (LTS) No features dropped 
>> 3.0 - 8 mos - All deprecations, including the LTS deprecations, are removed 
>> 3.1 - 16 mos - No features dropped 
>> 3.2 - 24 mos - (LTS) No features dropped 
>> 4.0 - 32 mos - All deprecations, including the LTS deprecations, are removed 
>> 4.1 - 40 mos - No features dropped 
>> 4.2 - 48 mos - (LTS) No features dropped
>> 
>> It'll mean that the maximum time a feature can be supported while 
>> deprecating is 2 years. The shortest it can be supported is a single release 
>> if the deprecation is made in an LTS - which I think is fine because the LTS 
>> is supported for 3 years anyway. It perfectly adheres to semver (which is a 
>> nice property, but not the be-all and end-all), and still allows libraries 
>> to straddle two LTS releases. Is there a good reason we couldn't use this 
>> model?
>> 
>> And I agree with Tim that changing the version numbers of already planned 
>> releases is not a good idea. The version naming can wait until the current 
>> Removed* warnings are gone - and timing it with the Python 3 only release 
>> sounds like a fairly good motivation to bump the major version and continue 
>> with semver from there. Provided we remember/document the plan :)
>> 
>> On Sunday, 14 June 2015 09:58:41 UTC+10, Tim Graham wrote:
>> Of course RemovedInDjango19Warning is also in 1.7 and a lot of docs 
>> reference Django 1.9. I'm not enthusiastic about updating all that.
>> 
>>> On Sunday, June 14, 2015 at 1:43:50 AM UTC+2, Loïc Bistuer wrote:
>>> 
>>> On Jun 13, 2015, at 20:43, Tim Graham  wrote: 
>>> 
>>> I don't have a strong opinion either way on semver, but I think it's a bit 
>>> late to rebrand 1.9 as 2.0 considering we've release code and docs with 
>>> reference to "RemovedInDjango19Warning". Do you have any thoughts on that? 
>>> We could plan the change for after the next LTS (2.1 -> 3.0) to correspond 
>>> with the cutover to Python 3.
>> 
>> 
>> Currently we have: 
>> 
>> 1.8: 
>>RemovedInDjango19Warning(DeprecationWarning) - Deprecations from 1.7 
>>RemovedInDjango20Warning(PendingDeprecationWarning) - Deprecations from 
>> 1.8 
>> 
>> master: 
>>RemovedInDjango20Warning(DeprecationWarning) - Deprecations from 1.8 
>>RemovedInDjango21Warning(PendingDeprecationWarning) - Deprecations from 
>> master 
>> 
>> In any case, implementing the new policy will require updating warnings from 
>> master: RemovedInDjango21Warning needs to become either 
>> RemovedInDjango22Warning or RemovedInDjango31Warning with the switch to 
>> SemVer. 
>> 
>> The question is whether it's too invasive to update warnings in a 1.8 patch 
>> release. If we ensure that RemovedInDjango19Warning remains importable by 
>> aliasing it to RemovedInDjango20Warning(DeprecationWarning), I think it's 
>> compatible enough not to delay implementing the scheme by another two years, 
>> especially considering how warnings are normally used. But if we want to be 
>> super cautious we could just leave the code as it is and document the 
>> problem in the 1.8 release notes, after all we are extending the lifespan of 
>> the shims (at least in appearance) which isn't 

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

[Ryan Hiebert]

> 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
> that users of your wheels/eggs are choosing to be more "on their own"
> when it comes to their chosen dependency versions.

I definitely agree. setup.py files, for the reason you mentioned, are not 
intended for concrete dependencies, while requirements.txt files are. They are 
the right tool for the job. If I was you, that's what I would do.

-- 
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 http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/486DA079-7F97-4597-A7FB-CD179DFB54DC%40ryanhiebert.com.
For more options, visit https://groups.google.com/d/optout.

Re: Model Docs Questions

[Ryan Hiebert]

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 actually does use &, | and ~.

The and/or/not operators are meant for flow control, and as such
cannot be overridden to allow us to use them for composing queries.

-- 
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 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 http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CABpHFHSq7dsr-hfuPck_Bk%3DYBu6NCMd3FmW4g7eCKT%2Bgdds_hQ%40mail.gmail.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: App-loading reloaded - running code at startup

[Ryan Hiebert]

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 received this message because you are subscribed to the Google Groups 
"Django developers" 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 http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CABpHFHQRrnic5j_wqPRNGgPuAXRwpq3mbSH0A3_UtinBqKGExA%40mail.gmail.com.
For more options, visit https://groups.google.com/groups/opt_out.

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

[Ryan Hiebert]

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() method on the
>> User model, will be removed."
>>
>> The dev 1.7 release notes say that the new schema migration is scheduled
>> to land in 1.7.
>>
>> Does this mean we cannot use the new schema migration functionality to
>> migrate away from AUTH_PROFILE_MODULE? Would it be better to deprecate the
>> AUTH_PROFILE_MODULE in 1.8? That way the features could co-exist together
>> for a brief time in order to facilitate migration.
>>
>> Hi Brian,
>
> There's a problem with your proposal - what profile are you suggesting
> that we migrate *to*?
>
> Migrations are only helpful if you've got a plan for how the data is
> changing. We've removed AUTH_PROFILE_MODULE because there's a number of
> ways that this data could be stored:
>
>  * On a custom User model
>  * On a related model linked with a FK
>  * On a related model linked with a O2O relation
>  * On a separate model indexed by user ID
>
> There's no migration path for simply *removing* AUTH_PROFILE_MODULE
> either. The database table for User never had a formal representation of
> AUTH_PROFILE_MODULE - it was just a O2O relation that had a specialised
> caching implementation. When AUTH_PROFILE_MODULE disappears, you'll still
> be able to access profile modules - the name will just change.
>
> So - there might be a role for migrations to play, but it's not something
> Django can specify as a project -- you'll have to handle it on a
> per-project basis.
>

That's true,  but if profiles won't work in 1.7, then it seems that he
wouldn't be able to use the native django migrations to aid the developer
in migrating his existing profiles to something better, which is what I
understood the problem to be.

Using south might be an option for migrating, but if we were to keep the
profile around one release longer, perhaps that would ease the pain of
migrating profiles to a better solution.

Or maybe it's not worth the hassle, or maybe there's a better way?

Ryan

-- 
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 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 http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CABpHFHTpgFJmyMnMzL11Am9hr8XPUzUbLOoCoAq_NY_LRc%3DwDw%40mail.gmail.com.
For more options, visit https://groups.google.com/groups/opt_out.

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

[Ryan Hiebert]

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 wrote:
>
>>
>>
>>
>> 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() method on the
>>>> User model, will be removed."
>>>>
>>>> The dev 1.7 release notes say that the new schema migration is
>>>> scheduled to land in 1.7.
>>>>
>>>> Does this mean we cannot use the new schema migration functionality to
>>>> migrate away from AUTH_PROFILE_MODULE? Would it be better to deprecate the
>>>> AUTH_PROFILE_MODULE in 1.8? That way the features could co-exist together
>>>> for a brief time in order to facilitate migration.
>>>>
>>>> Hi Brian,
>>>
>>> There's a problem with your proposal - what profile are you suggesting
>>> that we migrate *to*?
>>>
>>> Migrations are only helpful if you've got a plan for how the data is
>>> changing. We've removed AUTH_PROFILE_MODULE because there's a number of
>>> ways that this data could be stored:
>>>
>>>  * On a custom User model
>>>  * On a related model linked with a FK
>>>  * On a related model linked with a O2O relation
>>>  * On a separate model indexed by user ID
>>>
>>>  There's no migration path for simply *removing* AUTH_PROFILE_MODULE
>>> either. The database table for User never had a formal representation of
>>> AUTH_PROFILE_MODULE - it was just a O2O relation that had a specialised
>>> caching implementation. When AUTH_PROFILE_MODULE disappears, you'll still
>>> be able to access profile modules - the name will just change.
>>>
>>> So - there might be a role for migrations to play, but it's not
>>> something Django can specify as a project -- you'll have to handle it on a
>>> per-project basis.
>>>
>>
>> That's true,  but if profiles won't work in 1.7, then it seems that he
>> wouldn't be able to use the native django migrations to aid the developer
>> in migrating his existing profiles to something better, which is what I
>> understood the problem to be.
>>
>> Using south might be an option for migrating, but if we were to keep the
>> profile around one release longer, perhaps that would ease the pain of
>> migrating profiles to a better solution.
>>
>> Or maybe it's not worth the hassle, or maybe there's a better way?
>>
>
> You appear to be missing my point. I would gladly ship a migration to aid
> the transition.
>
> Now, what will that migration be?
>
> Unless I'm mistaken, there's no authoritative answer to this question;
> Django's deprecation of AUTH_PROFILE_MODULE requires only that you:
>
>  * Remove the AUTH_PROFILE_MODULE='foo.myprofile' definition in your
> settings file
>  * Replace uses of user.get_profile() in your codebase with user.myprofile
>
> Neither of these things require a migration - it's all code changes. And
> any other change (e.g., moving the contents of my profile onto User)
> requires a per-project understanding of the most appropriate solution,
> which isn't something Django is in a position to provide.
>
> Yours,
> Russ Magee %-)
>

Django clearly cannot know what migration to perform, so cannot ship any
generic migration. It could, however, allow the migration system to exist
while the profiles still work, so that a developer can use the built in
Django migrations to create a migration away from it.

It's not about shipping the actual migrations, but allowing him to use the
new native migration system to create migrations away from his profiles.
That takes a per-project understanding, but having the built-in migration
system may be helpful in his quest to find the right place to store the
data that he's had in his profiles.

-- 
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 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 http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CABpHFHQchVpgRa_-qQdGj6SMVO-P1XpzNNcsHj_qrNZdRkGKTg%40mail.gmail.com.
For more options, visit https://groups.google.com/groups/opt_out.

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

[Ryan Hiebert]

On Thu, Jan 23, 2014 at 10:30 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() method on
>> the User model, will be removed."
>>
>> The dev 1.7 release notes say that the new schema migration is
>> scheduled to land in 1.7.
>>
>
> I must be missing something -- why is this not possible with the current
> code in trunk?
>

I think its much more likely that I'm the one missing something. Thanks for
going back and forth with me.

>
> I'm afraid I either don't see the dependency on AUTH_PROFILE_MODULE that
> concerns you, or the problem that it's deprecation will cause. What
> migration are you trying to perform that requires the existence of a
> code-level API to support it?
>

Assuming that the changes from the deprecation policy are in trunk now that
the alpha has landed, any use of the AUTH_PROFILE_MODULE must be eliminated
_before_ moving to 1.7, since they are not just deprecated, but _removed_
in 1.7. Migrating to 1.7 will _break_ code that uses it. This is normal and
expected.

Since the new migration system lands in 1.7, and AUTH_PROFILE_MODULE is
removed in 1.7, then it is clear that it won't be possible to use the new
migration system to do the custom migrations that may be required to stop
using the AUTH_PROFILE_MODULE.

Allowing one more release before AUTH_PROFILE_MODULE is removed would allow
him to use the new migration system to create a custom migration to migrate
away from using the profiles. Otherwise, he'd need to use South or go
through two code change cycles.

I hope this clears up either why you're confused, or why I am. I'm very
sorry if it's me, I hate to waste your time.

-- 
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 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 http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CABpHFHTc277wKDVSKM302EfeN5Fi76UmkU-aZ32EHNfJiELjaA%40mail.gmail.com.
For more options, visit https://groups.google.com/groups/opt_out.

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

[Ryan Hiebert]

On Thu, Jan 23, 2014 at 11:25 PM, Carl Meyer  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_MODULE must be
> > eliminated _before_ moving to 1.7, since they are not just deprecated,
> > but _removed_ in 1.7. Migrating to 1.7 will _break_ code that uses it.
> > This is normal and expected.
> >
> > Since the new migration system lands in 1.7, and AUTH_PROFILE_MODULE is
> > removed in 1.7, then it is clear that it won't be possible to use the
> > new migration system to do the custom migrations that may be required to
> > stop using the AUTH_PROFILE_MODULE.
>
> I think this is the point of confusion. No migrations are required to
> stop using AUTH_PROFILE_MODULE, since the AUTH_PROFILE_MODULE feature
> does not affect the database in any way, it simply changes (very
> slightly) the code you use to access the database.
>
> If you have a Profile model in an "accounts" app, and you have
> AUTH_PROFILE_MODULE set to "accounts.Profile", here are the sum total of
> steps needed to stop using AUTH_PROFILE_MODULE:
>
> 1. Remove the AUTH_PROFILE_MODULE setting.
>
> 2. Replace occurrences of "user.get_profile()" in your code with
> "user.profile".
>
> Note the lack of any database migrations in those steps.
>
> > Allowing one more release before AUTH_PROFILE_MODULE is removed would
> > allow him to use the new migration system to create a custom migration
> > to migrate away from using the profiles. Otherwise, he'd need to use
> > South or go through two code change cycles.
>
> You are correct that _if_ you should happen to _also_ want to move the
> data you are storing in the Profile table to somewhere else, you won't
> be able to do that using a Django 1.7 migration at the exact same time
> as you remove the occurrences of "user.get_profile()" in your code. But
> there's no particular reason the removal of AUTH_PROFILE_MODULE should
> make you want to move data out of the Profile table, unless it just
> happened to remind you that you'd been wanting to do that anyway.
>
> So I think in a sense you and Russell are both right :-) But I don't
> think there's a strong enough case here to justify extending the
> lifetime of AUTH_PROFILE_MODULE. There's no harm in changing
> "user.get_profile()" to "user.profile" right now, and then waiting until
> 1.7 to do your migration. Or if you really want to do them in a single
> change to your codebase, you just do it now under Django 1.5 or 1.6
> using South.
>

Thanks Carl. I suspected that the code migration is seen as a small enough
issue not to warrant keeping get_profile() around, thanks for understanding
and answering that specifically. I think that's what the OP was all about,
and I wanted to make sure we all understood the tradeoff.

I personally use South, so this is not any issue for me, but I understand
the use case being presented.

-- 
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 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 http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CABpHFHSjS8S85e12kayTVmc-Jz2H9x0hVo4EgnkmOTqF7J5gRg%40mail.gmail.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [GSoC] Switching to Jinja2 proposal

[Ryan Hiebert]

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`.
>>
>
> Hello,
>
> Could this create a little problem for the people in charge of the
> template construction?. Let's say the templates are HTML, many tools uses
> the file extension to 'detect' the file type, so these people can get
> confused when their tools do not recognize the templates as expected; in
> addition, the people in charge of templates could not be developers, but
> graphic designers or authoring tools users.
>
> That argument makes sense to me: '.html' would have to be assumed to be
DTL, because in order to get Jinja2 you'd have to specify it in the
extension.

-- 
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 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 http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CABpHFHQdmERqSHVQot7c2UxOAxXKvNXA4hXdABFjX%2B56eqEW5A%40mail.gmail.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: APPEND_SLASH skip per URL or per base_uri

[Ryan Hiebert]

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 good idea to add options to disable the APPEND_SLASH
> behaviour per *url()*, or per a *base_uri*?
>
> *Example 1:*
> *settings.py:*
> APPEND_SLASH = True
>
> *urls.py:*
> url(r'^profile', views.profile, name='profile', append_slash=False),
>
> *Example 2:*
> *settings.py*
> APPEND_SLASH = True
> APPEND_SLASH_EXCLUDE = ('/api/v1/', '/api/v2/', '/etc/)
>
> What do you think?
>
> If the answer is YES, then would it be too late to push a patch up for
> inclusion in 1.7?
>
> Thanks,
>
> Val
>
>  --
> 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 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 http://groups.google.com/group/django-developers.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/e01272a7-585f-42fe-85e5-8b0020aef882%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" 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 http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CABpHFHQatxQjPtS_OpEXT%3D59ZRO6qq81ggQ1e6bewsSXqmCSiQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: APPEND_SLASH skip per URL or per base_uri

[Ryan Hiebert]

Sorry, auto-send.

In your example, APPEND_SLASH wouldn't add a slash, because the URL in the
URLConf doesn't have a slash on it.

I figure you probably meant this, though:

url(r'^profile$', views.profile, name='profile', append_slash=False),

(with a dollar sign at the end of the regex pattern).


On Thu, Mar 13, 2014 at 4:19 PM, Ryan Hiebert  wrote:

> 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 good idea to add options to disable the APPEND_SLASH
>> behaviour per *url()*, or per a *base_uri*?
>>
>> *Example 1:*
>> *settings.py:*
>> APPEND_SLASH = True
>>
>> *urls.py:*
>> url(r'^profile', views.profile, name='profile', append_slash=False),
>>
>> *Example 2:*
>> *settings.py*
>> APPEND_SLASH = True
>> APPEND_SLASH_EXCLUDE = ('/api/v1/', '/api/v2/', '/etc/)
>>
>> What do you think?
>>
>> If the answer is YES, then would it be too late to push a patch up for
>> inclusion in 1.7?
>>
>> Thanks,
>>
>> Val
>>
>>  --
>> 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 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 http://groups.google.com/group/django-developers.
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/django-developers/e01272a7-585f-42fe-85e5-8b0020aef882%40googlegroups.com<https://groups.google.com/d/msgid/django-developers/e01272a7-585f-42fe-85e5-8b0020aef882%40googlegroups.com?utm_medium=email&utm_source=footer>
>> .
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>

-- 
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 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 http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CABpHFHRSM%2BwirffyTWVtAn5spojQ%3DY6QWcr%3DHukPnAj-sejgqQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: APPEND_SLASH skip per URL or per base_uri

[Ryan Hiebert]

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 don't need to avoid APPEND_SLASH. Just remove the trailing slash from
the URL pattern, and Django won't ever append a slash to the URL. Of
course, then it also won't work if caller puts a slash at the end.

-- 
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 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 http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CABpHFHSjRKpfQ5T3UXv6evgMx6%3D0XovgngOZyKCKWe0djFM4VA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Migrations in Django 1.7 make unit testing models harder

[Ryan Hiebert]

>
> 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 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 http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CABpHFHQK9UdEK6x4Mb3eDqXd5f%3D9egzJp5A21UZYXAQJw8HRDw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: 1.7 release status (RC2 coming soon)

[Ryan Hiebert]

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 releasing 
prerelease versions on PyPI, then I’d probably reverse that opinion, because at 
that point it would be easier to install (though only marginally).

Ryan

> On Jul 24, 2014, at 6:42 PM, Tim Graham  wrote:
> 
> 2 weeks later and we still have a fairly strong stream of new bugs (thanks 
> everyone for testing), so I wouldn't expect a second RC until next week at 
> the earliest.
> 
> There was a suggestion among the core team to release another RC (even if the 
> list of release blockers isn't zero). This would make testing easier and help 
> us avoid getting duplicate bug reports for issues fixed since RC1, but others 
> were against it: "We should not release RC2 until there are 0 release 
> blockers, though - remember, an RC is supposed to be identical to the final 
> release if there's no blockers." Opinions from the community on that would be 
> welcome.
> 
> On Thursday, July 10, 2014 5:49:10 PM UTC-4, Tim Graham wrote:
> It's been 2 weeks since the release of 1.7 RC1 and we've seen several bugs 
> opened and fixed, with several still open [1]. We plan to issue a second RC 
> sometime next week if we can empty that list. Help us fix the issues if you 
> have some time and keep testing!
> 
> [1] 
> https://code.djangoproject.com/query?status=assigned&status=new&version=!master&severity=Release+blocker&col=id&col=summary&col=status&col=owner&col=type&col=component&col=changetime&desc=1&order=changetime

-- 
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 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 http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/12B812D6-CA3D-498C-9D57-B08C6B9D389B%40ryanhiebert.com.
For more options, visit https://groups.google.com/d/optout.

Re: 1.7 release status (RC2 coming soon)

[Ryan Hiebert]

> 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 good sense 
either. If there was a really significant benefit to the release, then calling 
it an RC even though it’s more of a beta seems like a reasonable compromise. I 
don’t really see a significant benefit to the release over just using latest 
git branch, though.

-- 
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 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 http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/7C2E3124-0B7B-40E2-AC06-EA54289D3E9A%40ryanhiebert.com.
For more options, visit https://groups.google.com/d/optout.

Re: 1.7 release status (RC2 coming soon)

[Ryan Hiebert]

> On Jul 25, 2014, at 10:06 AM, Ian Kelly  wrote:
> 
> On Fri, Jul 25, 2014 at 7:12 AM, Ryan Hiebert  wrote:
>> 
>>> 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 good 
>> sense either. If there was a really significant benefit to the release, then 
>> calling it an RC even though it’s more of a beta seems like a reasonable 
>> compromise. I don’t really see a significant benefit to the release over 
>> just using latest git branch, though.
> 
> I see two benefits. One is that users who are interested in testing
> aren't necessarily going to think to go to github; they're likely to
> look for the most recent release and use that (on the other hand, if
> they see a beta 4 and an RC 1, they might not necessarily realize the
> beta 4 is most recent either, so I take your point). The second
> benefit is that the instructions "pull the latest from github" can
> *sound* like a lot of work if the user is not a contributor and isn't
> experienced with git, and that might deter them from testing.

That makes sense to me. It’s basically the same reasons that a release on PyPI 
would be helpful: it sounds easier to a newcomer. If there’s consensus on that 
point (I still think git is pretty easy, but I’ve been using it quite a while), 
then I’m comfortable with the compromise of the RC nomenclature.

On a somewhat-related tangent, I seem to recall there being a good reason for 
not releasing pre-release versions on PyPI, but I’m having trouble finding the 
discussions that document that reason. Anybody care to enlighten me, or give me 
a link?

-- 
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 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 http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/3A65D698-6876-47C9-A666-24F527A39B1A%40ryanhiebert.com.
For more options, visit https://groups.google.com/d/optout.

Re: 1.7 release status (RC2 coming soon)

[Ryan Hiebert]

> On Jul 25, 2014, at 2:22 PM, Andre Terra  wrote:
> On Fri, Jul 25, 2014 at 12:17 PM, Ryan Hiebert  wrote:
> > I see two benefits. One is that users who are interested in testing
> > aren't necessarily going to think to go to github; they're likely to
> > look for the most recent release and use that (on the other hand, if
> > they see a beta 4 and an RC 1, they might not necessarily realize the
> > beta 4 is most recent either, so I take your point). The second
> > benefit is that the instructions "pull the latest from github" can
> > *sound* like a lot of work if the user is not a contributor and isn't
> > experienced with git, and that might deter them from testing.
> 
> That makes sense to me. It’s basically the same reasons that a release on 
> PyPI would be helpful: it sounds easier to a newcomer. If there’s consensus 
> on that point (I still think git is pretty easy, but I’ve been using it quite 
> a while), then I’m comfortable with the compromise of the RC nomenclature.
> 
> I respectfully disagree. Honestly, newcomers benefit more from learning 'git 
> clone foo' than from downloading tarballs from PyPI. For one thing, they are 
> probably going to need to learn it sooner or later and use version control in 
> their own projects, together with pip and virtualenv, lest they want to go 
> into a rabbit hole of frustrating import errors. *This* is what will make a 
> newcomer give up on Django/Python.
> 
> The learning curve for pulling something off a git repo is inexistent. We're 
> not asking them to git bisect, after all. It should be the standard, IMHO.

I agree that learning to deal with git is probably one of the best things we 
can encourage a new user to do. To that extent, I agree with your sentiment, 
and if we can encourage more usage of git, I’m all for it. We are the entry 
point to development for many people, and if we can use our position of 
authority to encourage newcomers to do things right, that’s a great idea.

However, I perceived that the debate was more about the bastardization of the 
“release candidate” version name for something that’s not possible to release, 
and I’m OK with it, if it’s really going to be helpful. I, for instance, would 
prefer to be testing some of my projects off of a pre-release version on PyPI, 
at least partially because I know that pip freeze will have a version string 
that works (and isn’t -e with a huge git commit hash).

We can’t go back and make another beta, because the versioning won’t be 
properly ordered, and that’s a Bad Thing. That leaves us with either not 
releasing, or releasing an RC with known bugs. The RC turning into a release 
possibility isn’t such a hard requirement for me, it’s just another, more 
polished, beta version, that’s closer to release. I certainly don’t want to 
stop being able to versioning things just because we’re getting lots of help 
finding bugs.

Ryan

-- 
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 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 http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/93DA56F4-1F2E-480F-8DF3-C5F7B95B18F5%40ryanhiebert.com.
For more options, visit https://groups.google.com/d/optout.

Re: [GSOC] Weekly update

[Ryan Hiebert]

> 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 have *positional* homogeneity. A "Point" is 
> a tuple, because element 0 of the tuple "means" the x coordinate. A Database 
> row is a tuple - The first element is the primary key (an integer), second is 
> the "name" column (a string), and so on.
> 
> A tuple is *not* "just an immutable list".
>  
> So maybe we should be using lists instead of tuples in our list_display docs? 
> https://docs.djangoproject.com/en/1.6/intro/tutorial02/#customize-the-admin-change-list
>  
> 
No, the list_display is a template of a _row_ in the list display, which is 
properly represented as a tuple, just like a database row.

-- 
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 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 http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/EA5117EA-3921-4424-9CF7-D6F42C2799CC%40ryanhiebert.com.
For more options, visit https://groups.google.com/d/optout.

Re: 1.7 release?

[Ryan Hiebert]

> 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 people are 
> finding "crash bugs" (i.e. where you give Django some set of inputs and it 
> crashes during migrations) every day or two with increasingly complex sets of 
> apps. These are the sorts of things I would have released South with and 
> fixed in a later release, but we hold Django to a higher standard.

While I’m very impatient to get 1.7, I’m also very grateful that you guys take 
the time to build and test a release so that it is solid. Thank you.

-- 
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 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 http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/B146A12B-E45C-4F6E-9ECE-93DE194BD8EC%40ryanhiebert.com.
For more options, visit https://groups.google.com/d/optout.

Re: Setting dictionaries (was Re: integrating django-secure)

[Ryan Hiebert]

On Fri, Sep 5, 2014 at 12:49 PM, Russell Keith-Magee <
russ...@keith-magee.com> wrote:

>
> On Fri, Sep 5, 2014 at 9:57 AM, Carl Meyer  wrote:
>
>> On 09/05/2014 10:46 AM, Tim Graham wrote:
>> > In the meantime, shall we abandon the idea of organizing settings in
>> > dictionaries for "purity"? May we add new settings as described here:
>> > https://code.djangoproject.com/ticket/22734#comment:22
>>
>> IMO, yes.
>>
>> When we already have a subsystem, like email, which is configured via
>> global settings, and it really needs a new configuration knob (we should
>> continue to be generally conservative in making that assessment), I see
>> very little downside to a new setting. If there's to be a new knob, best
>> to put it in the same place as the existing knobs for that component.
>>
>
> +1. If we actually need a new email setting for timeouts, I have no
> objection to adding EMAIL_TIMEOUT.
>

​I'd like to see the email settings get moved into a dictionary so that I
can use a single environment variable to configure it very easily, ala
dj-database-url. There's dj-email-url right now, but it requires 7 lines to
configure unless I want to restore to using vars() to update them all at
once. There should be a way to set this one logical setting (based on the
environment variable)​ without being implicit (using var().update) or
spending 7 lines on something this stupidly simple.

-- 
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 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 http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CABpHFHQ2Hn7JPqh7F9rzXz6CA1yr1hG3Bc1Zi%2BGXDkLzsBdOTQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: HTTP/2 and WSGI

[Ryan Hiebert]

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 to change things.

Thank you for working on this.

Sent from my iPhone

> On Sep 20, 2014, at 2:34 AM, Aymeric Augustin 
>  wrote:
> 
> 2014-09-20 6:42 GMT+02:00 Russell Keith-Magee :
>> 
>> Historically, Django hasn't been deeply involved in process of developing 
>> WSGI and related standards; this is an opportunity for us to change that 
>> trend.
> 
> To me the situation is pretty clear.
> 
> Either this line will win: 
> https://mail.python.org/pipermail/web-sig/2014-September/005257.html
> 
> Then maybe there's a chance we'll end up with a gateway interface that 
> doesn't make every framework undo the transformations performed by the 
> gateway to get back to the HTTP stuff.
> 
> Or that line will: 
> https://mail.python.org/pipermail/web-sig/2014-September/005258.html.
> 
> Then we'll carry the legacy of PEP  and WSGI will remain the bastard 
> child of CGI that it is and we'll keep doing stuff like value = 
> value.encode(ISO_8859_1).decode(UTF_8) and we'll want to stab ourselves 
> whenever we look at WSGI-related code.
> 
> I'll get in touch with Graham. For the record I once started writing a PEP 
> for a better WSGI, then I read web-sig and I carefully archived my draft 
> without telling anyone.
> 
> -- 
> Aymeric.
> -- 
> 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 http://groups.google.com/group/django-developers.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/django-developers/CANE-7mXtravDT%2BLhN0-hS9h4uewSGVXqWdEuD-oz%3DLLgSV5%2B1A%40mail.gmail.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 http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/29FFE9AA-823C-4D5F-94A7-D86537157E43%40ryanhiebert.com.
For more options, visit https://groups.google.com/d/optout.

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

[Ryan Hiebert]

>
> 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 that rule would be incorrect.

>

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CABpHFHQwL8aGCA8k7aU10xuv6fJnrURu5cD9kv8b%2BWS52gqdEw%40mail.gmail.com.

Re: Generate JWTs with Django

[Ryan Hiebert]

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 cannot be remedied by just writing
> better implementations.
>

Given this thesis, your conclusion makes sense. I use JWTs in my
application, because my domain is particularly suited to it IMO, and while
I can't speak for everyone on this list, I'd be interested to hear your
complaints about the design of JWTs. For my own thinking, I find that the
inclusion of the standardized algorithm field was a design mistake. It can
be papered over by a good library implementation, but that so many
libraries got it wrong is evidence of a flaw in the protocol design, IMO.

However, I'm not aware of any other standard payload-signing mechanism that
has the well-defined capabilities that JWTs have, without that issue.
That's fairly likely to be ignorance on my part, and if a more suitable
standard were available to me, I'd happily switch my application to using
it. Obviously JWTs are indeed popular, and I don't particularly find that
the issue I mentioned above to be a total showstopper (although obviously
very unfortunate).

Perhaps in email or a blog post or just a list of links, would you be
willing to share your complaints? Are there better designs for a similar
protocol that overcome your objections?

Ryan

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CABpHFHQ6M6ODzjX9aXxY-nbZRu5hFHq-nUcviGvzdX8U_NwePw%40mail.gmail.com.

Re: Generate JWTs with Django

[Ryan Hiebert]

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 vulnerabilities in JWT
> libraries and JWT-using systems again and again and again.
>
> And even if you get every single bit of it right, in the ideal perfect
> world with the ideal perfect implementation, the payoff is you've put
> in a ton of work to get something that already existed: signed
> cookies, for the use case of session identification, or any of several
> better token or token-like systems -- everything from PASETO to just
> timestamped HMAC'd values -- for the use case of inter-service
> communication.
>

Thank you very much for this write-up. The mention of PASETO was
particularly helpful to me. I was aware of the big all-library issue due to
algorithm negotiation and public/symmetric forgery, but not the others you
mentioned.

For my use-case, I need a signed payload that is server-verified and
client-readable. It sounds like PASETO is what you might recommend that I
use, instead of JWTs, IIUC.

Would you think that the motivation that started this thread might be well
served with having that as PASETO, or would it be better in your estimation
to avoid either JWT or PASETO in Django at this time? I can imagine that
Django using PASETO could give it a signal boost, but of course if there
were discovered some design flaw there, it would also entrench it more as
well as making it a security issue that Django has to address.

Either way, I really appreciate you taking the time to let us hear your
thoughts.

Ryan

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CABpHFHTTYkQ3FsK4LOj%2B_kc-ZMyicdBSFTqFd1e370EnFHoPXA%40mail.gmail.com.

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

[Ryan Hiebert]

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 `$_REQUEST`.
https://code.djangoproject.com/ticket/18659

On Wed, May 6, 2020, 04:07 Tom Carrick  wrote:

> > This often confuses beginners and “returners” alike.
>
> I'm neither a beginner nor returner and I still have to remind myself that
> request.POST doesn't contain my JSON data.
>
> I think it's a positive change. I agree there are things that would
> provide a better ROI, but people have to be willing to do them. I also
> think there's no harm in tackling things with a lower ROI.
>
> Tom
>
> On Wed, 6 May 2020 at 10:49, Steven Mapes  wrote:
>
>> Ah yes that's true, totally forgot about *request.body*  just then even
>> though I was using it a few days ago. So yes renaming it would help in that
>> regard as I do remember seeing a few S/O question where it's confused
>> people in the past.
>>
>> *Mr Steven Mapes*
>> Software Development and Solutions
>> E: st...@jigsawtech.co.uk
>> P: 07974220046
>> W: https://uk.linkedin.com/in/stevemapes/
>> [image: Twitter] 
>>
>> This E-Mail and its contents are confidential, protected by law and
>> legally privileged. Only access by the addressee is authorised. Any
>> liability (in negligence, contract or otherwise) arising from any third
>> party taking any action or refraining from taking any action on the basis
>> of any of the information contained in this E-Mail is hereby excluded to
>> the fullest extent of the law. In the event that you are not the addressee,
>> please notify the sender immediately. Do not discuss, disclose the contents
>> to any person or store or copy the information in any medium or use it for
>> any purpose whatsoever.
>> On May 6 2020, at 9:43 am, Adam Johnson  wrote:
>>
>> I always took the capitalisation of GET &co to come from HTTP
>>  — I'd say that's where PHP
>> took it from too but 🤷‍♀️
>>
>>
>> Yes GET and POST are capitalized in HTTP, but then COOKIES is not
>> (Set-Cookie / Cookies headers), and FILES and META aren't direct references
>> to anything in HTTP.
>>
>> Also I'm not sure it's a particularly good argument. Capitalization
>> inside Python should be based upon the conventions of Python, not the
>> conventions of the system the code talks to. For example, we have SELECT
>> ... FOR UPDATE in SQL, but .select_for_update() in the ORM.
>>
>>
>> Hmmm. I have to say I think there are areas where we could get a better
>> ROI on our time than this.
>>
>>
>> I think if we took the amount of time spent by users due to the confusion
>> of GET/POST, divided by the amount of time to make the code and docs
>> changes, it would come out with a relatively good ratio.
>>
>> My inspiration (or "the final straw") for making this proposal was a
>> recent forum question with confusion on the meaning of POST:
>> https://forum.djangoproject.com/t/ajax-post-to-view-not-displaying-content/2034
>>  .
>> I'm pretty sure I saw another one in the past month but can't find it But
>> it's an issue I've seen repeatedly. I know I've even spent time figuring
>> out how I'd get the query params during a POST request.
>>
>> please do not use *request.form_data* as that is also misleading as you
>> can POST many more sources than form data such as with APIs. post_data
>> would be much clearer.
>>
>>
>> Steven - I think you're confused by the current name. request.POST *only*
>> contains POST'd form data. It does not contain other POST'd data, such as
>> JSON bodies. So perahps that's another point for the name change?
>>
>> On Wed, 6 May 2020 at 09:29, Steven Mapes  wrote:
>>
>> Combined them would be very very bad and you would have the same problems
>> as with $_REQUEST in PHP where you have to decide which one wins as you can
>> make a POST to a URL with querystring where one of the parameters uses the
>> same name as a element of the POST and but where the value is different.
>> It's bad practice but it's valid
>>
>>
>> On Wednesday, 6 May 2020 08:00:56 UTC+1, Jure Erznožnik wrote:
>>
>> I agree. If anything, I've always had issues with GET & POST being
>> different entities in the first place, but never with their names. I would
>> really like to see an entity combining both of them. THAT one, maybe the
>> preferred way of doing so, would be lowercase, but RAW representations of
>> incoming data, I for one like them being upper case. Always makes me think
>> twice before playing with them.
>>
>> The content negotiation thingy is also something I would like to see more
>> time invested in: I have a project where I have to hack & slash DRF's
>> implementation in order to get what I want, but perhaps I'm tackling the
>> issue incorrectly. But that's beside the point. People will always

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

[Ryan Hiebert]

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, like "data" might be really good for a generic interface that
interprets various content types, like Django Rest Framework has, but this
isn't where Django is right now, and shouldn't be part of this question.
All we are trying to accomplish is to give access to POST form data with
the normal form submission content type that is not already accessible by
the `query_params`, which are of the url parameters (like a GET form). This
is just matching the current behavior of request.POST with a different name.

It is my opinion that the suggested `query_params` and `form_data` are
great. While `form_data` can be slightly ambiguous if you're thinking of
GET forms, once you realize that GET forms will show up in `query_params`,
and are available even in a POST request, then all `form_data` would have
left are the default POST forms. So +1 to the names as well.

On Fri, May 8, 2020 at 10:30 AM Carlton Gibson 
wrote:

>
>
> On 7 May 2020, at 22:03, Florian Apolloner  wrote:
>
> forms with method="GET" are legitimate and wouldn't end up in `form_data` 
> forms
> with method="GET" are legitimate and wouldn't end up in `form_data` which
> is imo quite confusing. Do we have any other options?
>
>
> Would there be an issue with `.post`?
>
> Bar the suggested `query_params` change, the proposal would then amount to
> “lowercase these names”.
>
> Then there’s the additional “Also rename `get` to `query_params`, to match
> DRF”.
>
>
>
>
> --
> 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 view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/66AB2042-8344-436B-A86A-2B9060BFAA17%40gmail.com
> 
> .
>

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CABpHFHTCzjQS9xfOPoc7kG9fBsQSTEoguBwkrZPu5E7qdRe3Bg%40mail.gmail.com.

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

[Ryan Hiebert]

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 a minimum seems like the right thing to me. I'm very
interested in using zoneinfo over pytz for my projects, and I'm willing to
shoulder more risk in order to do so. I hope Django will allow me to make
that choice.

On Wed, Jun 17, 2020 at 9:32 AM Paul Ganssle  wrote:

> Greetings all,
>
> Now that PEP 495  (the fold
> attribute, added in Python 3.6) and PEP 615
>  (the zoneinfo module, added
> in Python 3.9) have been accepted, there's not much reason to continue
> using pytz, and its non-standard interface is a major source of bugs
> . In
> fact, the creator and maintainer of pytz said during the PEP discussions
> that he was looking forward to deprecating pytz
> .
> After merging zoneinfo upstream into CPython, I turned the reference
> implementation into a backport to Python 3.6+
> , which I continue to maintain
> alongside the upstream zoneinfo module, so it is already possible to
> migrate Django *today*.
>
> Right now, Django continues to use pytz as its source of time zones, even
> for simple zones like UTC; I would like to propose starting the migration
> to zoneinfo *now*, to enable Django users to start doing their own
> migrations, and so there can be ample time for proper deprecation cycles. I
> apologize in advance for the huge wall of text, the TL;DR summary is:
>
>- It's important to start this migration as soon as possible, because
>it will take a long time and some of the bugs it fixes get worse as time
>goes on; right now Django's assumption that all time zones are from pytz
>will likely block Django users from migrating before Django does.
>- The combination of pytz's non-standard interface and Hyrum's Law
> makes this less straightforward than one
>would hope. Likely the best solution is to adopt "zoneinfo" immediately
>with a wrapper that deprecates the pytz-specific interface. I have provided
>a library to do this .
>- There are some open questions (which may only be open because I
>don't know Django's process well enough) in the migration plan:
>   - Should this change be put under a feature flag of some sort? If
>   so, what should be the default values for coming releases?
>   - Should *all* the pytz-specific tests be kept with zoneinfo tests
>   added, or should they be migrated and pytz tests confined to a smaller
>   subset?
>
> *Rationale*
>
> Before I get into the detailed migration plan, I'd like to lay out the
> case for *why* this needs to be done. I expect it to be at least somewhat
> painful, but and I'd prefer it if y'all were convinced that it's the right
> thing to do *before* you hear about the costs 😉. I am not the kind of
> person who thinks that just because something is in the standard library it
> is automatically "better" than what's available on PyPI, but in the case of
> pytz, I've been recommending people move away from it from a long time,
> because most people don't know how to use it correctly. The issue is that
> pytz was originally designed to work around issues with ambiguous and
> imaginary times that were fixed by PEP 495 in Python 3.6, and the
> compromise it made for correctness is that it is not really compatible with
> the standard tzinfo interface. That's why you aren't supposed to directly
> attach a timezone with the tzinfo argument, and why datetime arithmetic
> requires normalization. Any substantial code base I've ever seen that uses
> pytz either has bugs related to this or had a bunch of bugs related to this
> until someone noticed the problem and did some sort of large-scale change
> to fix all the bugs, then imposed some sort of linting rules.
>
> In addition to the "pytz is hard to use" problems (which, honestly, should
> probably be enough), pytz also has a few additional issues that the
> maintainer has said will not be fixed (unless pytz becomes a thin wrapper
> around zoneinfo, which is at best just using a slower version of zoneinfo).
> The biggest issue, which is going to become increasingly relevant in the
> coming years, is that it only supports the Version 1 spec in TZif files,
> which (among other issues), does not support datetimes after 2038 (or
> before 1902) — this was deprecated 15 years ago, and it is unlikely that
> you will find modern TZif files that don't have Version 2+ data. Pytz also
>

Re: Integrating migrations with the check framework

[Ryan Hiebert]

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 should be run compared with deployments.

https://github.com/aspiredu/django-safemigrate

On Wed, Dec 23, 2020 at 10:01 AM Paveł Tyślacki 
wrote:

> Want to share lib I work previously for migration safety with postgres
> some time ago: https://github.com/tbicr/django-pg-zero-downtime-migrations
> there are also checker and replacement of unsafe mirations with safe
> replacement.
>
> ср, 23 дек. 2020 г. в 12:18, Adam Johnson :
>
>> Hi Tom,
>>
>> I love this idea and would like to help developers write safe migrations
>> too.
>>
>> You didn't mention this pre-existing project:
>> https://github.com/3YOURMIND/django-migration-linter . It might be worth
>> checking how that works.
>>
>> I'm not sure what any public API could look like here. In
>> django-linear-migrations (
>> https://github.com/adamchainz/django-linear-migrations ) I tapped a bit
>> into the MigrationLoader class, which is undocumented but fairly stable.
>> Perhaps we could just document a few more of the migration internals?
>>
>> On Tue, 22 Dec 2020 at 22:58, Tom Forbes  wrote:
>>
>>> Hey,
>>> A fairly common problem with large and/or highly trafficked web
>>> applications is migration safety: you want your migrations to be
>>> non-locking and instantaneous. The specifics are very database dependent
>>> but in Postgres simply altering the nullability of a column can incur
>>> serious downtime depending on the size of the table in question. The same
>>> thing goes for adding a new non-nullable column to a table or even just
>>> creating an index without the `CONCURRENTLY` option.
>>>
>>> Code review is one way of catching these issues but an automated
>>> solution that runs as part of the test suite would be the preferred
>>> solution. I don’t think using some kind of linter for this is a good idea
>>> as it doesn’t have the context to decide if it _is_ a safe migration (i.e
>>> removing `NOT NULL` from a column in the same migration that creates the
>>> column is safe). A linter also doesn’t know which migrations are pending
>>> and which have been applied.
>>>
>>> Rails has the pretty nice strong_migrations Gem (
>>> https://github.com/ankane/strong_migrations) which attempts to detect
>>> dangerous migrations. Unless I’m missing something right now it seems quite
>>> hard to add automated checks like this to Django migrations that can
>>> inspect the full set of “pending migration operations". We have the
>>> `pre_migrate` signal that takes a “plan” argument with the scary sounding
>>> caveat that the passed object has no public API, but using a signal feels
>>> kind of wrong. It should be part of a system check - i.e a warning that
>>> says “your app may die if this migration is applied”.
>>>
>>> I’d like to make this simpler to implement on a per-project basis (or in
>>> a third party app) but I’m not sure how. It should be a system check but
>>> the only suitable hook we have is the generic `register()` callback that
>>> takes a set of `app_configs`, and I’d expect going from that to a pending
>>> set of operations would be non trivial. A user-facing interface for this
>>> might be a function that is called for every specific type of migration
>>> operation with the operation itself and a list of all operations that would
>>> be applied of “migrate” was run.
>>>
>>> ```
>>> @some_migration_callback_decorator(AlterField)
>>> def check_null(operation, pending_operations):
>>> If operation.is_going_to_not_null:
>>> if not table_being_created(operation.table_name,
>>> pending_operations):
>>> return Warning(f’Setting {operation.field_name} to NOT NULL
>>> may cause downtime’)
>>> ```
>>>
>>> I’m not sure if Django should ship migration warnings itself but having
>>> the ability for projects to enforce arbitrary constraints on their
>>> migrations might be an interesting feature?
>>>
>>> Slightly related to https://code.djangoproject.com/ticket/31700, where
>>> we want to add more contextual/coloured outputs for dangerous operations.
>>>
>>> Tom
>>>
>>> --
>>> 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 view this discussion on the web visit
>>> https://groups.google.com/d/msgid/django-developers/CAFNZOJNoi583wUoQp%2BRBB_%2B3i_vqSPRbVNwhiU_OG7V2eL8x3g%40mail.gmail.com
>>> 
>>> .
>>>
>>
>>
>> --
>> Adam
>>
>> --
>> You received this

Re: Revisiting Python support for after Django 3.2 LTS

[Ryan Hiebert]

> 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 proposal? 
> As I've said, I'd be sympathetic to this, but what is the reason why not?

I may have missed it being stated in this conversation, so I want to make sure 
the reason for the current policy is understood. The reason why not to make 
this exception is to avoid releasing breaking changes at a minor version. To 
follow SemVer. We get to decide whether that’s enough reason.

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/39C52096-7251-4597-B879-BCC7146AE683%40ryanhiebert.com.

Re: Revisiting Python support for after Django 3.2 LTS

[Ryan Hiebert]

> 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 places, and recognize that 
breaking changes may be practical in any version.

One place that SemVer was strategically weakened was by allowing features that 
were only deprecated at the LTS release to persist until the .1 release, so 
that there would always be at least 2 versions before a feature is removed 
after deprecation.

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/6333A98C-EC9F-474D-9D6E-5A659B9EEE30%40ryanhiebert.com.

Re: Do people actually squash migrations?

[Ryan Hiebert]

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, 2021, at 11:40 AM, 'Mike Lissner' via Django developers 
> (Contributions to Django itself)  wrote:
> 
> Oh, I guess there's also a step in the manual process to reset the migrations 
> table in the DB, but I don't know how to do that. Tricky stuff! 
> 
> On Wednesday, May 12, 2021 at 9:37:53 AM UTC-7 Mike Lissner wrote:
> So sort of sounds like an update to the squash migration docs is needed if 
> this is representative of the general sentiment. Looking at the section on 
> this 
> ,
>  the general outline is:
> 
> 1. Overview
> 2. How it works
> 3. The commands
> 4. Gotchas
> 5. A bunch of wonky stuff you have to do ("Update all migrations that depend 
> on the deleted migrations", "Remove the 'replaces' attribute in the Migration 
> class ")
> 6. Another gotcha in an info box
> 
> Would it be a bad idea to update the docs to bifurcate this section so it has 
> an intro that says something like:
> 
> As you work on your project you will create more and more migrations. When 
> they get to be too many, there are two approaches to trimming them down. The 
> first is to use the squashmigrations command and process to create a merged 
> migration file, however this approach comes with a number of caveats and 
> gotchas that often make it impractical. The second way is to coordinate with 
> your team to ensure that all installations of your app are up to date, then 
> to have a coordinated day when migrations are removed and recreated from 
> scratch. Which one is best for your organization will depend on the 
> complexity of your project and the flexibility of your team.
> 
> From there, the docs could go on to explain first how to do this manually, 
> then move onto the squashmigrations docs. This disfavors squashmigrations by 
> putting it after the manual approach, but after this conversation (and my 
> experience) that seems right to me. 
> 
> I haven't done the manual approach but I imagine it's something like:
> 
> 1. Check your migrations across all apps with interdependencies for RunPython 
> or RunSQL code.
> 2. If found, make a decision about keeping or deleting that code.
> 3. Delete all migrations across all apps that have interdependencies.
> 4. Run the makemigrations command
> 5. Add your custom RunPython or RunSQL code back
> 
> That'd be a big demotion for the squashmigrations code. I don't know how 
> married we are to it, but it seems like there's not much energy for making it 
> better and that lots of people have already demoted it in their minds and 
> workflows.
> 
> Thanks, 
> 
> 
> Mike
> 
> 
>  
> 
> -- 
> 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 view this discussion on the web visit 
> https://groups.google.com/d/msgid/django-developers/ce1cb4d6-905f-4411-93df-4449796558a8n%40googlegroups.com
>  
> .

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/274F3484-1784-4C0C-8ADC-552E1870C61C%40ryanhiebert.com.

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

[Ryan Hiebert]

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 
wrote:

> I have recently become acquainted with some ORM behaviour for reverse
> relationships that "makes no sense", and I'm hoping someone can explain the
> justification for the current behaviour.
>
> This specifically relates to `filter` behaviour referenced in 29271
> , and 16554
>  which seems tangentially
> related to several issues with `exclude` (24421
> , 14645
> , 17315
> ) and aggregate expressions (
> 16603 , 19415
> )
>
> Most of the confusion about 'intended' behaviour and confirmed 'bugged'
> behaviour seems to relate to the ORM's use of joins for reverse
> relationships.
> I think my personal confusion boils down to two questions.
>
> 1) Is there some fundamental limitation in the ORM that prevents reducing
> the number of joins? Several of these tickets indicate how the ORM could
> potentially produce similar results with queries that did not use multiple
> joins. Why is that not desirable behaviour?
>
> 2) Why is the current behaviour of `filter` for multi-value relationships
> 'intended'? I'm hoping I am missing something obvious but it seems to me
> that `Q` objects would support the type of behaviour suggested in the spanning
> multi-valued relationships
> 
>  documentation
> in a much more inituative manner. In a test case with models
>
> class Related(models.Model):
> field = models.CharField(max_length=100)
>
> class Main(models.Model):
> field_one = models.CharField(max_length=100)
> field_two = models.CharField(max_length=100)
> related = models.ForeignKey(Related, on_delete=models.CASCADE)
>
>
> both
>
> >>> Related.objects.filter(Q(main__field_two='2')|Q(main__field_one='1'))
>
> SQL:
> SELECT "test_app_related"."id", "test_app_related"."field" FROM
> "test_app_related" INNER JOIN "test_app_main" ON ("test_app_related"."id"=
>  "test_app_main"."related_id") WHERE ("test_app_main"."field_two" = "2"
>  OR "test_app_main"."field_one" = "1")
>
> and
>
> >>> Related.objects.filter(main__field_two='2').filter(main__field_one='1'
> )
>
> SQL:
> SELECT "test_app_related"."id", "test_app_related"."field" FROM "test_app_
> related" INNER JOIN "test_app_main" ON ("test_app_related"."id"= "test_
> app_main"."related_id") INNER JOIN "test_app_main" T3 ON ("test_app_
> related"."id" = T3."related_id") WHERE ("test_app_main"."field_two" =
> "two" AND T3."field_one" = "one")
>
> Produce exactly the same results but the second seems to have an
> unnecessary extra join, and directly contradicts the behaviour of filter
> with non multi-valued fields.
>
>
>
> In short, could someone be kind enough to explain the justification for
> all this weird behaviour with multi-value relationships?
>
>
> Cheers,
>   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/22234c13-3152-473f-86bd-
> 04b41efd9203%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/CABpHFHQBTdZ%3DVSeDa1APVZUTpoT7cFhgRFxxVgY4cVtnS4GYvg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

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

[Ryan Hiebert]

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 a little bit more tricky, is removing fields. It's not sufficient in
general to just avoid using the field in your user code. You also have to
remove the field from the model itself, or else the model in many cases
will, by default, attempt to gather that field from the database and cause
an error.

I'm using Heroku, and that meant that I needed to have a first commit that
removed the field from the model, and leave the migration for a second
commit (and deployment). This meant that there was a time where things were
inconsistent. In the case of removing the null-ability of a field (assuming
that in your situation it won't take the lock for longer than you can
permit) they would not have to be split into a separate commit, but the
code needs to be fully deployed before the migration can be run.

Things got even more complicated when I wanted to start using Heroku's
Release Phase to automatically run migrations, which would automatically
migrate _before_ the release is out, which doesn't work for either the
to-not-null case or attempting to remove a field in a single commit. My
team addressed that by introducing a concept of "safe" migrations, which
for us is referring to the ability to run it before the associated code is
released. Now we have a `safemigrate` command, which will only run
migrations that are safe, based on the presence of a manual property added
to the migration classes, and thus is acceptable to always run in the
release phase. This allows us to mark migrations as unsafe when we need to
ensure that a migration gets run manually after the associated code is
deployed.

There are a couple complexities with the approach, especially related to
dealing with sets of inter-dependent migrations where some are safe and
some are unsafe, but the approach does seem to be working for us. A known
challenge, but one that is, for our purposes, enough of an edge-case that
we've not addressed it, is that the reverse of safe migrations are often
unsafe, and the reverse of unsafe migrations are often safe. This is
further complicated because in some cases, such as data migrations, the
forward and reverse may _both_ be safe or unsafe, so it's not as simple as
being the opposite of the forward direction. We have, so far, completely
ignored this bit of complexity. We also have not attempted to automatically
figure out whether a migration is safe or not based on the operations
included.

If what we've done here is of interest to others, I will look into sharing
the code to get further feedback on it. Please let me know if you're
interested in seeing it.

On Thu, Mar 22, 2018 at 10:19 PM, Paul Tiplady  wrote:

> It can be quite fiddly to support zero-downtime DB migrations in Django.
> For example see https://dev.mysql.com/doc/refman/5.7/en/data-type-
> defaults.html for tricks in Postgres; I'll refer to MySQL herein.
>
> In general the sequence is to first upgrade the DB schema to the new
> version, while keeping the old version of the application running. This
> works if the DB fields have a `DEFAULT NULL`, or if strict mode is not
> enabled; in either case omitted fields are defaulted to NULL or the
> implicit default, respectively  (under MySQL).
>
> However it seems that manual SQL must be written in order to support
> adding fields that aren't nullable; since Django's ORM drops the DB-level
> default when the field is not nullable, there's a window after the schema
> migration, but before the application code has been upgraded, where the
> old-version code could try to write a None to the DB, while the new-version
> DB schema doesn't support it.
>
> For example, a NullBooleanField(default=None) produces this SQL:
>
> `bool_field` tinyint(1) DEFAULT NULL,
>
> Whereas a BooleanField(default=False) (or NullBooleanField with a default)
> produces:
>
> `bool_field` tinyint(1),
>
> This is the same for the other field types I've investigated; Django
> explicitly removes the default from the DB when migrating from a Nullable
> Field to a non-Nullable one.
>
> In MySQL using non-strict mode, this would often go unnoticed (since MySQL
> coerces NULL to the implicit default in that case), but under strict mode
> is recommended, that option is not available (per
> https://dev.mysql.com/doc/refman/5.7/en/data-type-defaults.html).
>
> Achieving zero-downtime migrations would be much easier if the default
> value was set in the DB; is there a reason that Django does not do this?
> Even if this was an optional flag which only worked for literal values
> (i.e. not functions), it would seem to be a very useful feature. (e.g.
> `Field(set_default_in_db=True)`).
>
> Indeed it seems to me that (based on the paucity of articles/documenta

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

[Ryan Hiebert]

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 Tom Forbes  Unfortunately I made this for a python 2 app before enums where in the
> standard library. I think it has some useful ideas though especially around
> categories, which I find I needed a lot. I'd be interested to know if
> anyone else has written any workflow-driven apps in Django that require
> groups of choice values (i.e "if value in Choices.SOME_GROUP)?
>
> Its a shame about the way xgetext worked, but I guess it's not too bad to
> duplicate this if you require it. I'm not too familiar with it and assumed
> it worked by importing modules and recording calls to the function.
>
> In any case, we could make the display text optional if you do not require
> translations and generate them from the keys?
>
> The way Django handles choices has always irked me as it's really not DRY,
> you need to create sort-of enums using class or global variables and
> tuples. It's repetitive and boring, and honestly enums made this much more
> usable.
>
> We currently have a -1 and a +1, does anyone else have any input on this?
>
> Tom
>
> On Mon, 31 Dec 2018, 22:15 Shai Berger 
>> Hi Tom,
>>
>> On Mon, 31 Dec 2018 18:26:14 +
>> Tom Forbes  wrote:
>>
>> > I was describing my django-choice-object library[1] and forgot to
>> > link it!
>> >
>>
>> Thanks, I took a look -- the library looks nice, but notably, Choice
>> objects are not Python enums, although they share some of their traits.
>>
>> > I would be +1 on re-opening it, I've used enums for this before and I
>> > find it much more DRY than the more 'standard' Django way.
>>
>> Thanks.
>>
>> > Perhaps we could reduce some boilerplate here by somehow automatically
>> adding
>> > the key names to gettext?
>> >
>>
>> This, I'm afraid, won't fly. The way xgettext (the engine used by
>> makemessages) generates the translation files is by scanning the text
>> of source files, looking for specific function calls, and picking their
>> arguments with a simple text transformation. So, for the key name to
>> somehow be identified, it must be a parameter in a function call (not
>> the target of assignment), and the form to be translated must be the
>> form that's in the source -- no changing capitalization, or
>> underscores-to-spaces, or anything of the sort. So, the best we could
>> do to minimize repetitions would create Choice classes looking like
>>
>> class SchoolYear(Choices):
>> choice('Freshman', 'FR')
>> choice('Junior', 'JR')
>>
>> where the choice() calls add members to the class, and the name of the
>> member is generated by some transformation over the label. That,
>> IMO, would be unacceptably unpythonic.
>>
>> Have fun,
>> Shai.
>>
>> > 1. https://github.com/orf/django-choice-object
>> >
>>
>> --
>> 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/20190101001534.29c8c673.shai%40platonix.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/CAFNZOJPJcqi7bELk_1QFOp3ZMZV1njYd9nWSc_bumymkzta1BQ%40mail.gmail.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/ms

Re: revisiting the Python version support policy

[Ryan Hiebert]

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 when to drop support for Python 2 in Django, there was
> consensus to adopt this Python version support policy [0]: "Typically, we
> will support a Python version up to and including the first Django LTS
> release whose security support ends after security support for that version
> of Python ends. For example, Python 3.3 security support ends September
> 2017 and Django 1.8 LTS security support ends April 2018. Therefore Django
> 1.8 is the last version to support Python 3.3."
>
> Since then, we didn't abide by this policy when dropping Python 3.4,
> mainly because Debian stable still used Python 3.4 at the time and Claude
> argued that some people like him would have difficulty contributing to
> Django if they had to install another version of Python [1].
>
> Based on the policy, it's time to drop support for Python 3.5 in the
> master branch (Django 3.0) -- with Django 2.2 LTS supported until April
> 2022 and Python 3.5 supported until September 2020). I created a ticket [2]
> and PR [3] for dropping support for Python 3.5 [2], however, Claude
> commented, "I'm not so enthusiast to drop Python 3.5 now (it is still the
> default version in Debian stable). Couldn't this be done in Django 3.1
> instead?"
>
> Are you in favor of amending the Python support version policy to account
> for the Python version in Debian stable?
>
> [0]
> https://docs.djangoproject.com/en/dev/faq/install/#what-python-version-can-i-use-with-django
> [1]
> https://groups.google.com/d/msg/django-developers/4rbVKJYm8DI/TTh3i04pBQAJ
> [2] https://code.djangoproject.com/ticket/30116
> [3] https://github.com/django/django/pull/10864
>
> --
> 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/ce5f3cdb-a623-4bcc-a661-bf88d91a5a7f%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/CABpHFHTSo%3D80GWdA6kLqk%3DXBxFa6s1d3V%3D_LBmoj4oCJQwJMLA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: revisiting the Python version support policy

[Ryan Hiebert]

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 ends September 2019, whilst Django 3.1 ends mainstream support in
>> April 2021. Therefore Django 3.0, which is end of life August 2019 is the
>> last version to support Python 3.5."
>
>
> +1. A subtle change on the existing policy but it makes a difference.
>

That seems better to me as well. It only ties us to the support policy of
Python, not various special-cased distributions. My concern, though, is
that it weakens semantic versioning a bit, so we should do it carefully. We
don't follow it precisely, but if we drop support for a version of Python,
that seems to me like it would qualify as a breaking change, and should be
preferred to be done when changing major versions after an LTS release. If
that is deemed to not be a significant concern, then I think this proposed
policy is a reasonable one.

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

Re: revisiting the Python version support policy

[Ryan Hiebert]

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 no
problem with 3.5 support being dropped.

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

Re: Show applied datetime in showmigrations

[Ryan Hiebert]

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. Making it an addition to a
> higher verbosity level will work too.
>
> --
> 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/4f3d3816-94c6-4065-b7ea-8b21bfb3d4e6%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/CABpHFHQSxyRkfuH06d0P7YU0hYdUydWE%3DGxXAQ_y%2BYe7nGigUQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Django 2.2 release candidate 1 released

[Ryan Hiebert]

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> wrote:

> Is it possible to have this option in Django 2.2?
> When we select a OneToOne object by related_name, rises DoesNotExists when
> have no object related.
> Is it possible to add the behaviour to return None instead of
> DoesNotExists?
>
> Thank you
>
> On Monday, March 18, 2019 at 12:33:15 PM UTC+3:30, Carlton Gibson wrote:
>>
>> We've made the final (hopefully) release on the way to Django's next
>> major release, Django 2.2! Check out the blog post:
>> https://www.djangoproject.com/weblog/2019/mar/18/django-22-rc1/
>>
> --
> 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/ba861ea5-8916-4293-82c0-89461418af89%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/CABpHFHR1H%3Dii6tQD9f7MULmxNvTuoCKCC8b1tnOsO06Bi7QcFQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

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

[Ryan Hiebert]

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 task.

On Fri, Jun 21, 2019 at 8:39 AM Carlton Gibson 
wrote:

> Hi All
>
> Can I ask folks to have a look at this please?
>
> Ticket is: https://code.djangoproject.com/ticket/30427
> PR is: https://github.com/django/django/pull/11337
>
> The original change that introduced the current behaviour is
>
> https://github.com/django/django/pull/6491/files#diff-bf776a3b8e5dbfac2432015825ef8afeR699
>
> *Question: *What was the reason for this comment:
>
> # Don't override classmethods with the descriptor. This means that
> # if you have a classmethod and a field with the same name, then
>
> #such fields can't be deferred (we don't have a check for this).
>
>
> In case it rings any bells...
>
> PR there was called:
>
> "Replaced dynamic classes with non-data descriptors for deferred
> instance loading."
>
> Related mailing list discussion:
> https://groups.google.com/forum/#!msg/django-developers/BDAlTyJwQeY/Fh2Qy07cAQAJ
>
> Thanks.
> Carlton
>
> --
> 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/94d1f059-8cb2-435b-be52-66d3ae1a4721%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/CABpHFHR-mhQGneh-bjUV6Oa_DubVVDOC2jc_CWaBoR6LPVdZTg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

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

[Ryan Hiebert]

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 of
scenario. You still need to make sure you don't mix stuff in the same
migration that delete and add a column, for example, but it makes the
process much easier, and we've been able to add the safemigrate command to
our regular automated deployments. The full migrate then only runs when
manually triggered, to deal with removing columns, etc.

You can check out our repository. We've been pretty happy with how it's
working for us. https://github.com/aspiredu/django-safemigrate

On Mon, Jun 24, 2019 at 8:15 AM Matthieu Rudelle 
wrote:

> Hi there,
>
> I can't find any previous ticket proposing a solution to this problem so
> here are my findings:
>
> **Use case**:
> When using continuous delivery several versions of the code can be running
> in parallel on se same DB. Say for instance that release 2.42 is in
> production, 2.43 is about to be rolled out and in this release one field
> (say ''MyModel.my_unused_field'') is not used anymore and was removed.
> Before rolling out 2.43 the DB is migrated and column ''my_unused_field''
> of ''MyModel'' is removed. This makes 2.42 crash saying that one column is
> not found even though 2.42 does not use the field anywhere in the code.
>
> **Temporary solution**:
> Do not makemigrations until de 2.44 release, but it does not scale well
> with many contributors and CI tools (doing their awesome job of making sure
> migrations and models are in sync) will complain.
>
> **Proposed solution**:
> Have a ''disabled'' param on Field. When activated this field is not
> fetched from the DB but replaced by a hardcoded value.
> In our use case, ''disabled'' is added at the 2.42 release, then when 2.43
> rolls out and migrates the DB no error is thrown.
>
> **Refs**:
> - django-users discussion:
> https://groups.google.com/forum/#!topic/django-users/HY_6rZZ0Kk8
> - the same problem discussed in this article, but with a slightly
> different solution:
> https://pankrat.github.io/2015/django-migrations-without-downtimes/#django-wishlist
> (third item in the wishlist)
> - Previous django-developpers discussion:
> https://groups.google.com/d/msg/django-developers/5ofrxeLT95E/XhppgA_KAQAJ
>
> What do you guys think?
>
> --
> 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/637c3542-c5bd-4493-8b12-44eb61f34a68%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/CABpHFHSa4hXVrp7M2MWLcsPXSRnCnvhMQ%3D8D3q1Rg8AsAXU4Cw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

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

[Ryan Hiebert]

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 does not affect squashing. I think this is roughly reasonable, at least
for my uses, although I haven't had any real world use for squash myself. I
recently had to remake the migrations in my repo for $WORK project, and it
made the most sense to keep them as the default safe after deploy, to match
what other apps would get. I think in most cases it won't matter when the
first migration is safe for practical use.


>- Can makemigrations figure out which migrations are "safe", such as:
>   - It is always safe to add a column or table.
>   - It is never safe to drop or rename a column or table.
>
> This is a feature that has sounded neat to me, approximately feasible, but
hasn't yet been worth the time to implement. We've been happy adding the
safety annotations manually.

>

-- 
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/CABpHFHSb2AHKb-XhZcAk6gZ3%2B%2Bt5nz7UkBUNyQ_FC%3DsYGgO_Yw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Migrations in Django 1.7 make unit testing models harder

[Ryan Hiebert]

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 allow for shipping the ORM code changes separately
from the database migrations. That was my use-case anyway. If the migration
needed to run first, then I wanted to deploy the migrations by themselves,
then the ORM changes. Sometimes I'd want to ship the ORM changes first, and
the migrations later (though usually just running them after deploy was
effective).

Then when Heroku added release phase, which can automatically run
migrations immediately before a release is deployed, I really wanted to do
something better. So we created django-safemigrate (
https://github.com/aspiredu/dango-safemigrate), which allows you to mark
your deploys as safe to run before, after, or at any time relative to the
code changes to the ORM they match. This allows my team to avoid splitting
up the ORM changes from the migrations, which keeps matching things
together in the commit history. It's been working fairly well for us,
barring the occasional human error mis-marking the migrations. Feel free to
give it a try, to see if its also a good workflow for you!

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CABpHFHT0OZmKQ%2BfH7%3DSgGCugwVW56QdJ2%2Bgi5ZPXPCH1E%2BF7OA%40mail.gmail.com.

Re: Migrations in Django 1.7 make unit testing models harder

[Ryan Hiebert]

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 from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CABpHFHTKwxXPsZ-9A%3Dx0tLVc2uOgXrALsNjq4NwZHGqwsk7FMg%40mail.gmail.com.

Re: Stop QuerySet repr from executing queries

[Ryan Hiebert]

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 kind of representation of the query filter.
>

Just speaking for myself, I think I'm roughly in agreement with the general
sentiment and reasoning behind your proposal. There's one place that I
think there's common utility, and which I think is the most likely the
cause disruption to people, the interactive prompt. The issues that you've
mentioned are also present on the interactive prompt as well, so the change
would be optimal there as well. Perhaps it would be possible to ease the
pain somewhat if there were a setting to do reprs as currently, perhaps
_only_ on the interactive prompt, to avoid the issues you've pointed out
with tools like Sentry. I'm not sure what the default setting value should
be, though I do think new projects should include whatever settings would
be needed to make this the default behavior for new projects, even if the
setting default was to maintain backward compatibility, as has been done
for other settings.

tl;dr: I like the motivation, but I'm not sure how the backward
compatibility aspects will play out for the community.

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CABpHFHS1%3DirRaQVWgiUnmTX%2By%3DB7Vy%2BpGLha-aoYmqTGUSj20g%40mail.gmail.com.

Re: Stop QuerySet repr from executing queries

[Ryan Hiebert]

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 suppose, but I think most of the time that's just
noise. When you want to see that, you'll say you want to see that by
getting the repr of the query itself. It seems like too much for a default
repr for QuerySet, IMO.

>
> Regarding other things that have been mentioned: I'm not too keen about
> introducing a setting for this behavior, or doing things differently in an
> interactive console. Django already has a lot of settings, and this seems
> like such a minor thing. And I don't know of any precedent for changing the
> behavior of Django in an interactive shell (and you can tell I'm not a fan
> of inconsistent behaviors).
>

Me either, and I'm one that mentioned it. I personally have no misgivings
about changing the repr unconditionally, and it would be my preference. I
was trying to consider potential dissent to give balanced feedback.

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CABpHFHTF0%2BNHWhtdhziqtsKPeJo1nih77WMt%3DzY4kM0j%3DGTcSg%40mail.gmail.com.

Re: re-thinking middleware

[Ryan Hiebert]

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 together an initial
> pull request with a POC for some of those ideas. I've now updated the
> proposal (incorporating some implementation ideas from Pyramid's
> middleware equivalent) and written it up in the form of a DEP. You can
> find the DEP at
> 
> https://github.com/django/deps/blob/master/draft/0005-rethinking-middleware.rst
> 
> and I'm also pasting the full text below, to ease in-line commenting via
> email.
> 
> Comments welcome!

Only one comment from me. This is awesome!

-- 
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/7E2126FA-0178-4F4F-B8AB-F49B9BD7B684%40ryanhiebert.com.
For more options, visit https://groups.google.com/d/optout.

Re: re-thinking middleware

[Ryan Hiebert]

> 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”, I would require 
> raising MiddlewareNotUsed explicitly to disable a middleware. A middleware 
> factory that returns None would cause an ImproperlyConfigured exception. 
> Otherwise middleware could be skipped by mistake, if the developer forgets to 
> return the middleware from the factory. This is especially a concern for 
> production-only middleware that developers can’t run locally.
> 
> It’s easy to imagine scenarios where this would escalate into a security 
> issue. For instance, consider a middleware that hooks into a centralized 
> corporate authentication system and rejects unauthorized users. It’s common 
> not to have a testing version of that kind of infrastructure and for 
> developers not to have keys for the production version. Add an incomplete 
> testing strategy that only check that authorized users have access…

I definitely agree with this critique. I regularly forget to return the wrapper 
function when writing decorators, and this seems likely to have the same issue. 
Having it warn me early and loud that I screwed up would be very helpful.

-- 
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/B96A169F-9B6A-4E3A-A9B1-763C47A6FC1C%40ryanhiebert.com.
For more options, visit https://groups.google.com/d/optout.

Re: re-thinking middleware

[Ryan Hiebert]

> On Jan 8, 2016, at 11:57 AM, Ryan Hiebert  wrote:
> 
>> On Jan 8, 2016, at 11:35 AM, Aymeric Augustin 
>>  wrote:
>> 
>> In the spirit of “there should be only one way to do it”, I would require 
>> raising MiddlewareNotUsed explicitly to disable a middleware.
> 
> I definitely agree with this critique. I regularly forget to return the 
> wrapper function when writing decorators, and this seems likely to have the 
> same issue. Having it warn me early and loud that I screwed up would be very 
> helpful.

And perhaps instead of raising, it could just return MiddlewareNotUsed, in a 
similar way as you would return NotImplemented on implementations of dunder 
methods. This case doesn't require doing things that way, as there's no 
equivalent to the right-side fallback of operators, but I think it may still be 
an option worth considering.

-- 
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/4024A245-7A77-4F4E-905D-3712308BCC7B%40ryanhiebert.com.
For more options, visit https://groups.google.com/d/optout.

Re: re-thinking middleware

[Ryan Hiebert]

> 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 given, which has the same effect of "skipping yourself." That
> falls out naturally from the concept, so I don't see any reason to
> disallow it, but we don't need to mention it in the docs if we want to
> stick to "one way to do it."

I hadn't considered the option of just returning ``get_response``.
I really like it, because it avoids both raising an exception and
importing a common symbol.

While class-based middleware factories couldn't just do the same thing
in the __init__ method, they could do that in a __new__ method instead,
and then we could make returning the ``get_response`` function the
"one way to do it."

-- 
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/8C97647F-48A2-477F-BEC8-D2BC7C676959%40ryanhiebert.com.
For more options, visit https://groups.google.com/d/optout.

Re: re-thinking middleware

[Ryan Hiebert]

> On Jan 8, 2016, at 12:53 PM, Carl Meyer  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 instead,
>> and then we could make returning the ``get_response`` function the
>> "one way to do it."
> 
> I'd be more sympathetic to this viewpoint if Django hadn't already had
> the `MiddlewareNotUsed` exception for many years in this very role.
> There's no reason to break it if we don't absolutely have to. And since
> we've got it, and it works in any scenario, it may as well be the
> preferred method.
> 
> [snip]
> 
> That said, I expect plenty of people (probably myself included) to use
> the "just return ``get_response``" trick, whether it's documented or
> not, and I think that's totally fine.
> 
Your reasoning makes sense. I'll probably be one of those that will prefer
the return ``get_response`` trick, even in classed based middlewares.

-- 
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/1A12E94D-9D03-4C6B-8771-A22F00903C8E%40ryanhiebert.com.
For more options, visit https://groups.google.com/d/optout.

Re: Feedback on Django Channels

[Ryan Hiebert]

> 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),
> include(path="^notifications", "notification.routing.routing"),
> ]

Something's up with this example, it has postional arguments after keyword 
arguments, which is invalid Python. Is there supposed to be a keyword used for 
the final parameters?

-- 
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/68C930D0-1C2E-4CF4-B3B8-DA8450C468AB%40ryanhiebert.com.
For more options, visit https://groups.google.com/d/optout.

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

[Ryan Hiebert]

> 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 'Conditions' 
> and applying them to Views. [snip]
> 
> 1. How clear and convincing is the section describing what's wrong with the 
> current solution ('The Problem(s)')? Any criticisms on that section would be 
> very welcome.

It seems like a neat idea, and reasonably well thought out, though I don't have 
the standing needed to speak to its viability as a GSOC project or for 
inclusion in Django. I'd be interested to see a write-up comparing this with 
Django Rest Framework's Permissions, which seem pretty similar in concept. 
http://www.django-rest-framework.org/api-guide/permissions/ 


-- 
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/046E080A-B21F-437A-AAD0-2151CF61CCE4%40ryanhiebert.com.
For more options, visit https://groups.google.com/d/optout.

Re: New `pre_handler()` method on Class-Based Views

[Ryan Hiebert]

I have taken to using a prepare method called from dispatch which takes the 
request  args, and I use it primarily to resolve ids in the url to db objects. 
This sounds like it fills a similar purpose.

Sent from my iPhone

> On Apr 3, 2016, at 14:07, Pablo Recio  wrote:
> 
> Hey there,
> 
> Wanted to share an idea I had during some discussions in DjangoCon EU. When 
> using CBV, sometimes we have to replicate behaviour between different 
> handlers. For instance setting up certain objects, extra user checks... 
> Normally the way to achieve this is to override the `dispatch()`, but it's a 
> bit error-prone and doesn't feel too clean sometimes.
> 
> So I wrote a little piece of code that adds a `pre_handler()` method that 
> gets called before the handler method, whatever that is. Here is the code: 
> https://github.com/pablorecio/django/tree/pre-handler-view-method, if it's 
> something that would get merged I'll happily submit a PR.
> 
> Thanks!
> Pablo Recio
> 
> 
> -- 
> 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/df0c7703-b496-4bfa-ad31-68b35be482fa%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/AFBC3432-F9C6-40CA-9A4E-A194AA84C5C7%40ryanhiebert.com.
For more options, visit https://groups.google.com/d/optout.

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

[Ryan Hiebert]

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 None are singletons, that are guaranteed to always point to 
the exact same object in memory, and `is` is the appropriate operator to use 
there. It is for those singletons that this feature is being added.

> On Apr 7, 2016, at 4:42 PM, Stephen Kelly  wrote:
> 
> Hello,
> 
> I reviewed 
> 
> https://github.com/django/django/commit/c00ae7f5
> 
> while updating the features of Grantlee, and I have the following notes:
> 
> * The unit tests added both have the same name ("template"). They should 
> have different names of the form 'if-tag-isNN'
> * The feature does not work the same way as django 'is' works. For example:
> 
>In: t = e.from_string(
> "{% if \"True\" is \"True\" %}yes{% else %}no{% endif %}")
>In: t.render(c)
> 
>Out: 'no'
> 
> The feature 'if ... is' feature looks like it needs more design 
> consideration before it is released.
> 
> Thanks,
> 
> Steve.
> 
> 
> -- 
> 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/ne6k90%249b3%241%40ger.gmane.org.
> 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/4FEBF18F-960B-4650-AE49-0E03D7E84AF3%40ryanhiebert.com.
For more options, visit https://groups.google.com/d/optout.

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

[Ryan Hiebert]

> 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 consideration. 
> 
> * What should work / what should not work? Is the documentation clear?

I don't know about the docs, but it _does_ work exactly like the Python 
version. A while back I had this same confusion regarding the `is` operator. 
You can see all about it in my Stack Overflow question: 
http://stackoverflow.com/q/8638880/206349

> * Why is there no 'is not' operator? ie '{% if a is not True %}'

`is not` is probably logical addition, if somebody wants to put in the time to 
make it happen.

-- 
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/E2798027-D059-461B-BCE5-2C43AC48CEC8%40ryanhiebert.com.
For more options, visit https://groups.google.com/d/optout.

Re: Making Django more PaaS-friendly

[Ryan Hiebert]

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 required for the `collectstatic` command. I 
haven't tracked down why it currently _is_ required, but it means that I have 
added this line to my project, solely so that my project can be built on Heroku.

SECRET_KEY = os.environ.get('SECRET_KEY', 'not-so-secret')

SECRET_KEY is effectively optional (though I'm careful to make sure it's set), 
and I don't see a good reason that should be. Note that environment variables 
aren't normally available during slug build, since changing environment 
variables doesn't re-build the project.


I believe that the biggest current impediment to finding a great solution to 
loading Django settings is that the settings are based on a Module. 
Django-Configurations has done an excellent job of making that into a 
class-based API instead, which allows for mixins and inheritance. Having 
built-in support for this would be an excellent way to allow 3rd party 
solutions to build up settings programatically. In the case we are discussing, 
from the environment.

I believe this would make it far easier for projects like Kristian's 
django-12factor and dj-email-url to work well. dj-email-url is a good idea (put 
all the settings in 1 variable, like dj-database-url), except that all the 
settings are split up at the top-level of the module, making what's 
conceptually one multi-facted setting a multi-line pain.

One possibility would be extending `DJANGO_SETTINGS_MODULE` with an optional 
class, separated with a colon, so to get a django-configurations style class 
you'd use `DJANGO_SETTINGS_MODULE=myproject.settings:MySettings`. Or we could 
change the variable name `DJANGO_SETTINGS`, which would allow us to avoid the 
colon: `DJANGO_SETTINGS=myproject.settings.MySettings`. Or paint the bikeshed 
some other color.


I'd love to see some of the support for environment configurations brought into 
Django, but IMO moving away from a module based settings API is a more pressing 
concern that would enable 3rd party libraries to come up with elegant solutions.


> On Apr 11, 2016, at 4:32 AM, Kristian Glass 
>  wrote:
> 
> I wrote django12factor to do something similar. One of the things I like 
> least about it is the process of actually using it from your settings.py - 
> there's things in there I'd love to see in the generated default.

-- 
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/2D66F14E-DD71-41B6-A84D-A0C679FD72F5%40ryanhiebert.com.
For more options, visit https://groups.google.com/d/optout.

Re: My Take on Django Channels

[Ryan Hiebert]

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  wrote:
> 
> [snip]
> 
> The Channel API is built more around a simple queue/list rather than a full 
> messaging layer. [snip] Kombu supports  [snip].

The API was purposefully limited, because channels shouldn't need all those 
capabilities. All this is spelled out in the documentation, which I know you 
already understand because you've mentioned it elsewhere. I think that the 
choice to use a more limited API makes sense, though that doesn't necessarily 
mean that it is the right choice.
> 
> [snip description of architecture]

First off, the concerns you mention make a lot of sense to me, and I've been 
thinking along the same lines.

I've been considering if having an alternative to Daphne that only used 
channels for websockets, but used WSGI for everything else. Or some alternative 
split where some requests would be ASGI and some WSGI. I've tested a bit the 
latency overhead that using channels adds (on my local machine even), and it's 
not insignificant. I agree that finding a solution that doesn't so drastically 
slow down the requests that we've already worked hard to optimize is important. 
I'm not yet sure the right way to do that.

As far as scaling, it is apparent to me that it will be very important to have 
the workers split out, in a similar way to how we have different celery 
instances processing different queues. This allows us to scale those queues 
separately. While it doesn't appear to exist in the current implementation, the 
channel names are obviously suited to such a split, and I'd expect channels to 
grow the feature of selecting which channels a worker should be processing 
(forgive me if I've just missed this capability, Andrew).
> 
> [[ comments on how this makes deployment harder ]]

ASGI is definitely more complex that WSGI. It's this complexity that gives it 
power. However, to the best of my knowledge, there's not a push to be dropping 
WSGI. If you're doing a simple request/response site, then you don't need the 
complexity, and you probably should be using WSGI. However, if you need it, 
having ASGI standardized in Django will help the community build on the power 
that it brings.
> 
> Channels claims to have a better zero-downtime deployment story. However, in 
> practice I’m not convinced that will be true. [snip]

I've been concerned about this as well. On Heroku my web dynos don't go down, 
because the new ones are booted up while the old ones are running, and then a 
switch is flipped to have the router use the new dynos. Worker dynos, however, 
do get shut down. Daphne won't be enough to keep my site functioning. This is 
another reason I was thinking of a hybrid WSGI/ASGI server.
> 
> There is an idea floating around of using Channels for background jobs/Celery 
> replacement. It is not/should not be. [snip reasons]

It's not a Celery replacement. However, this simple interface may be good 
enough for many things. Anything that doesn't use celery's `acks_late` is a 
candidate, because in those cases even Celery doesn't guarantee delivery, and 
ASGI is a simpler interface than the powerful, glorious behemoth that is Celery.

There's an idea that something like Celery could be built on top of it. That 
may or may not be a good idea, since Celery uses native protocol features of 
AMQP to make things work well, and those may not be available or easy to 
replicate accurately with ASGI. I'll be sticking with Celery for all of those 
workloads, personally, at least for the foreseeable future.
> 
> [snip] locks everyone into using Redis.

Thankfully, I know you're wrong about this. Channel layers can be built for 
other things, but Redis is a natural fit, so that's what he's written. I expect 
we'll see other channel layers for queues like AMQP before too long.
> 
> I see literally no advantage to pushing all HTTP requests and responses 
> through Redis.

It seems like a bad idea to push _all_ HTTP requests through Redis given the 
latency it adds, but long-running requests can still be a good idea for this 
case, because it separates the HTTP interface from the long-running code. This 
can be good, if used carefully.

> What this does enable is that you can continue to write synchronous code. To 
> me that’s based around some idea that async code is too hard for the average 
> Django dev to write or understand. Or that nothing can be done to make parts 
> of Django play nicer with existing async frameworks which I also don’t 
> believe is true. Python 3.4 makes writing async Python pretty elegant and 
> async/await in 3.5 makes that even better.

Async code is annoying, at best. It can be done, and it's getting much more 
approachable with async/await, etc. But even when you've done all th

Re: My Take on Django Channels

[Ryan Hiebert]

> On May 6, 2016, at 7:21 AM, Mark Lavin  wrote:
> 
> Ryan,
> 
> Sorry if you felt I was ignoring your reply to focus on the discussion with 
> Andrew. You both made a lot of the same points at about the same time but I 
> did want to touch on a couple 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, and ASGI is a simpler 
> interface than the powerful, glorious behemoth that is Celery.  
> 
> This isn't the place for a long discussion about the inner workings of Celery 
> but I don't believe this is true. [snip]

I just meant them to be _candidates_ for being able to use a less reliable 
channel. I've got lots of non-acks-late stuff that I couldn't use channels for. 
No need for further discussion, I just want to point out that I think we're 
(nearly, at least) on the same page here. You're right that I misspoke when 
saying it doesn't guarantee delivery, but the end result is similar if the 
worker gets lost.
> 
> 
> All of the examples I've seen have pushed all HTTP requests through Redis. I 
> think some of the take-aways from this conversation will be to move away from 
> that and recommend Channels primarily for websockets and not for WSGI 
> requests.

He's talking now about having a inter-process channel, which doesn't cross 
system boundaries, so it alleviates my concerns. For my cases the latency will 
be good enough if we just avoid the machine hopping.

-- 
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/62DF2295-3D2B-4FA3-A274-4087760CE310%40ryanhiebert.com.
For more options, visit https://groups.google.com/d/optout.

Re: Withdrawing Channels from 1.10

[Ryan Hiebert]

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 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/368C3DE9-64F2-4C17-8E17-CF5EF5529664%40ryanhiebert.com.
For more options, visit https://groups.google.com/d/optout.

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

[Ryan Hiebert]

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 the precedence of Python's typing syntax of `name: type`. It meets my 
sensibilities to follow Python's example.

Of course, we've also got the example from Flask to contend with, so it's a 
value judgement.


> On Oct 3, 2016, at 10:55 AM, Aymeric Augustin 
>  wrote:
> 
> +1 Tom’s proposal and Jacob’s comments.
> 
> -- 
> Aymeric.
> 
>> On 03 Oct 2016, at 16:39, Jacob Kaplan-Moss > > wrote:
>> 
>> Hi Tom -
>> 
>> Thanks for putting this together! Overall, +1 from me as well: I've taught 
>> Django to a bunch of beginners, and URLs are one of the major pain points. 
>> I'd love to make them easier, and your proposal looks pretty dang great.
>> 
>> Some specific feedback:
>> 
>> 1. I'm not too thrilled on the "is this a regex or not?" auto-detection: my 
>> experience has been that every time we try to be clever like that, we end up 
>> regretting it down the line. "Explicit is better than implicit", and all 
>> that. It's more awkward, but I'd prefer different calls/constructors for 
>> URLs. I think this also lets us set up a better upgrade/transition path. My 
>> suggestion is that we move towards `url()` giving "new style" patterns, and 
>> have another helper ("url_regex"? "urlr"?) that provides regex resolving. We 
>> could also take this opportunity to simplify import paths, so:
>> 
>> - `from django.urls import url` <--- new-style resolver
>> - `from django.urls import url_regex` <--- old-style resolver
>> - `from django.conf.urls import url` <--- old-style resolver, with 
>> PendingDeprecation/DeprecationWarning, then deleted - as per normal upgrade 
>> path.
>> 
>> 2. Huge +1 on copying Flask's converters and API. Flask nailed the routing 
>> syntax, no need to reinvent the wheel!
>> 
>> 3. Documentation: I suggest introducing the new syntax immediately in all 
>> the documentation. It's better for like 90% of the cases.
>> 
>> Thanks again, I'm stoked to see some motion here.
>> 
>> Jacob
>> 
>> On Mon, Oct 3, 2016 at 3:24 AM, Tom Christie > > wrote:
>> Hi folks,
>> 
>> I wanted to push forward the consideration of introducing a simpler URLs 
>> syntax, plus support for URL parameter type conversion.
>> 
>> A pre-proposal is available here: 
>> https://gist.github.com/tomchristie/cb388f0f6a0dec931c611775f32c5f98 
>> 
>> 
>> At this point I'm seeking feedback, before hopefully iterating on the 
>> proposal, and making a formal submission.
>> 
>> I'm not making any assumptions right now about where this might get too, or 
>> who'd be involved if it does make it to the DEP stage, and would very much 
>> welcome outside involvement. I'm also aware that while there's been some 
>> positive reception, it's not yet clear if we'll reach a consensus on 
>> inclusion in core.
>> 
>> Personally I'm very firmly +1 on this, as I feel that the existing syntax is 
>> a rather glaring and unnecessary pain point.
>> 
>> Thanks to everyone who's started to kick this off, in particular Emil 
>> Stenström for raising the original thread, and Sjoerd Job Postmus for their 
>> work on the Django Simple URL 
>>  package.
>> 
>>   - Tom
>> 
>> -- 
>> 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/1450171a-be2b-41e8-b221-91bfe656d039%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 

Re: Should SECRET_KEY be allowed to be bytes?

[Ryan Hiebert]

> On Dec 22, 2016, at 1:41 PM, Tim Graham  wrote:
> 
> There's debate in #24994 about whether or not settings.SECRET_KEY should or 
> may be a bytestring. Some select quotes to summarize the discussion:
> 
> [snip]
> 
> I hope we can come to a decision and at least clarify the documentation. 
> Perhaps deferring a code change (if any) until Django 2.0 so that only Python 
> 3 is a consideration would help.
> 
> https://code.djangoproject.com/ticket/24994
> https://code.djangoproject.com/ticket/19980

It seems to me that whatever option is chosen, it should support some mechanism 
that all provided bytes be random. In the case of using ascii-only bytes, this 
is not the case. With that goal in mind, I think there are, at least in 
principle, two choices, and the correct one depends on what is a more important 
priority.

If its more important to transparently have the right data type, then we should 
use bytes. This may mean that we prefer to generate bytes that are not fully 
random (top bits are always 0, etc) so that we can avoid escape sequences.

If we'd rather ensure that all of the bits we generate both avoid escape 
sequences and provide all of their own bytes randomly, then we'll need to have 
settings.SECRET_KEY be an encoded bytes, perhaps base64. In that case, it 
likely doesn't matter whether it's a string or a bytes, as base64.b64decode 
permits either.

I suspect making SECRET_KEY encoded with something like base64 is likely a 
non-starter due to backward compatibility, so that means to me that using bytes 
would be preferable.

-- 
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/520E361B-6CC9-4D66-BA51-E0C9A9C77165%40ryanhiebert.com.
For more options, visit https://groups.google.com/d/optout.

Re: Should SECRET_KEY be allowed to be bytes?

[Ryan Hiebert]

> 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 didn't consider it in my response. I think 
it puts even more weight behind it being a bytes. The expressibility argument 
(it should support all bytes being truly random) of my options is still 
reasonable I think, but the readability negative for bytestrings is nullified, 
since you can just make the string longer when you generate it.

+1 for bytes

-- 
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/E473B966-407C-4734-AA41-9386F3A54CEE%40ryanhiebert.com.
For more options, visit https://groups.google.com/d/optout.

Re: Should SECRET_KEY be allowed to be bytes?

[Ryan Hiebert]

> 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. 
> They're also easy to copy/paste and verify when adding them to your config 
> management.

Thanks for this. As someone who writes 12-factor apps all day, this argument 
makes a lot of sense to me.

-- 
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/47C9DF93-3753-48D3-8D09-8ACFA1D9DFF1%40ryanhiebert.com.
For more options, visit https://groups.google.com/d/optout.

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

[Ryan Hiebert]

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.
>
> Secondly, since that space is valuable, perhaps it could also say:
>
> This release of Django has been sponsored by . 
>
> Django is free open-source software. Support Django's development
> 
>
> The more I think about this, the less I think it's a bad idea...
>

Finding funding for open source is notoriously difficult, and if this can
turn out to be a net benefit for the project, I think this is a really neat
way to do it. Good thinking, Daniele.

One comment on the design, though, that might be worth considering. The
admin redesign that happen a few releases back originally chose to use
similar styling to djangoproject.com, but it was decided that it would be
better to keep it a blue theme instead, so that they were visually
distinctive. I think that reasoning also applies here, to keep this initial
page distinctive from the pages that are actually hosted on
djangoproject.com.

Overall, I love the idea, thanks for putting the work in.

-- 
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/CABpHFHSRnbUpQz3Q7E1ivZC%2BfK82gW2%3DcpKQerapSrXddPkveA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Drop CSRF middleware from the settings template

['Ryan Hiebert' via Django developers (Contributions to Django itself)]

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 wouldn't 
need more than that for the session cookie.

It appears that Django has defaulted the session cookie to `Lax` since the 
SESSION_COOKIE_SAMESITE parameter was added in Django 2.1. All current 
browsers seem to have supported it since 2019. Is it time for us to remove 
the CSRF Middleware from the default settings template file?

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/f5c90c5e-a7b1-49f2-84da-0cce32f6f67dn%40googlegroups.com.

Re: Drop CSRF middleware from the settings template

['Ryan Hiebert' via Django developers (Contributions to Django itself)]

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 can't really use cookies unless 
their SameSite attribute is None. This is the case even if you manage the 
cookies entirely inside the iframe and its origin.

In my experience, even SameSite None is not sufficient to use cookies in 
cross-site iframes. Safari doesn't allow those cookies to be sent unless 
you visit the site directly first. I've heard movements for Firefox and/or 
Chrome having similar behavior, but I haven't been working with iframes 
recently enough to know the current state of that.

In such cases, you really do need Django's current CSRF protection. 
Personally I wouldn't mind it being off by default, since SameSite=Lax 
seems to be enough for most cases, but this could be a footgun for some 
people.

There certainly are legitimate use-cases. I like Jacob's following 
suggestion for a check that might help alleviate a misconfiguration 
concern, if they did change SameSite to none without activating CSRF 
protection. If it were possible to identify other places where there might 
be a sharp-edge misconfiguration because of the cross-domain difference of 
meaning between samesite and what CSRF needs, that could be good as well. 
And those checks would, I think, be worthwhile even without changing the 
default, since they are currently possible configurations.

I think what we want to weigh is whether the footgun of *not* having CSRF 
by default is bigger than the significant complexity overhead of managing 
the CSRF projection in a new project. It's marking all views, adding tags 
to all form templates, and I think it can be easy to underestimate the 
attention it requires. If we can eliminate this overhead, especially for 
beginners starting out with Django and web development, that sounds like a 
great benefit. Lowering the barrier to entry is worth a lot.

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/553aea07-90de-41ce-a71c-6529ebc97eb3n%40googlegroups.com.

Re: Drop CSRF middleware from the settings template

['Ryan Hiebert' via Django developers (Contributions to Django itself)]

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 
found this because the development environment I was working in, 
Codespaces, forwards and redirects to a browser via a public address rather 
than localhost, and that difference means that CSRF checks were enforced in 
that environment, though I had no trouble with localhost. There's likely 
some details I'm missing in laying out this scenario, but it felt 
interesting enough to mention in the context of this conversation.

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/72019908-a072-45fc-bd55-3dbf675711cdn%40googlegroups.com.