Re: ticket 5929

['Tobias McNulty' via Django developers (Contributions to Django itself)]

Thank you Barhamou for raising the question here and starting the
discussion.

I agree with Adrian that this feels like a pretty niche use case.
Depending on the needs, other possible implementations might include:

4. A form field mapping to multiple model fields
5. A custom queryset/manager that takes "shorthand filter queries" and
expands them to multiple model fields

As for the example in #5929  ticket
description, that is probably best solved with #2 on Adrian's list, for
example the django-netfields
 project
for Postgres.

On Mon, Jan 9, 2023 at 9:59 AM Barhamou Hama  wrote:

> Hence the interest of my question, if in 15 years it has not been solved,
> there must be a reason.
>
> Le lundi 9 janvier 2023 à 12:57:31 UTC+1, ator...@redhat.com a écrit :
>
>> I feel like this is a very niche use case and probably doesn't warrant
>> implementing field-to-column one-to-many relationships in Django, I don't
>> see why this specific case can't be implemented as:
>>
>> 1. A model that implements the data type
>> 2. A custom field + custom datatype on the database backend
>> 3. ArrayField [1] if using postgres
>>
>> [1]
>> https://docs.djangoproject.com/en/4.1/ref/contrib/postgres/fields/#arrayfield
>> On Monday, January 9, 2023 at 12:16:56 AM UTC+1 cur...@tinbrain.net
>> wrote:
>>
>>> On Sun, 8 Jan 2023, at 23:29, Barhamou Hama wrote:
>>>
>>> Hi all, I came across this ticket here
>>>  opened 15 years ago that
>>> doesn't seem to have been resolved. I decided to work on it. But in 15
>>> years a lot can happen. Is it still relevant? Has there been any progress
>>> on this issue?
>>>
>>>
>>>
>>> IIRC there's no current support for this, the closest being
>>> GenericForeignKeys, which still require their sub-fields defined separately.
>>>
>>> There has been posts about supporting joint using multi-field keys (
>>> https://devblog.kogan.com/blog/custom-relationships-in-django) however,
>>> that's a rather specific case.
>>>
>>> I think it would be a good thing for progress on this issue to happen.
>>>
>>> You might also want to check the ticket history for any work on
>>> multi-value keys.
>>>
>>> --
>>> Curtis
>>>
>>>
>>> --
> 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/9e4ee8c9-aa22-4ac1-bd70-1c87427ca955n%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/CAMGFDKRDeF-VqnYg%2BHmTYo-pT1QyG61dUKKqm3Ai_jSKnb984g%40mail.gmail.com.

Re: #21978 include production-ready web server

['Tobias McNulty' via Django developers (Contributions to Django itself)]

At Florian's suggestion in another thread, I propose that we move further 
discussion of the settings refactor to the forum:  
https://forum.djangoproject.com/t/settings-refactor/17352

On Wednesday, November 2, 2022 at 2:58:29 PM UTC-4 f.apo...@gmail.com wrote:

> The speckenv example highlights the problems when using `literal_eval`: 
> A=[] will parse as list but A=[a] will parse as string again (if I read the 
> code correctly). This ambiguity makes it really hard to explain. When using 
> `literal_eval` one imo has to be consistent and don't fall back to a str 
> and require strings to be written as A='[]' (with quotes). Then again this 
> is rather ugly and hard to get right/explain if you try to pass that in via 
> a shell ala `A='[]' django-admin runserver` and now A is a list again :/
>
> Cheers,
> Florian
>
> On Wednesday, November 2, 2022 at 8:20:00 AM UTC+1 m...@feinheit.ch wrote:
>
>> On Tue, Nov 1, 2022 at 10:34 AM Florian Apolloner  
>> wrote:
>>
>>> Right, that would work. I am wondering though if we want to go all in on 
>>> a typed config object like that or in a first step only have a simple API 
>>> like `config.get('DEBUG', cast=bool)`.
>>>
>>>
>> I found a neat trick in a 12factor library somewhere (I don't remember 
>> where unfortunately) of using ast.literal_eval for config variables:
>> https://docs.python.org/3/library/ast.html#ast.literal_eval
>>
>> https://github.com/matthiask/speckenv/blob/94722bcc95b94a9e6b1a1aada2bd977c43bfb767/speckenv.py#L63
>>
>> This may be too cute or magical for Django. It certainly works well and 
>> avoids having to be overspecific with types. I find it boring to tell the 
>> config loader that True is a bool and "hello" is a string. That being said 
>> I don't really have a strong preference here apart from having a strong 
>> dislike for the "several settings files" pattern. It's much more obvious to 
>> me if e.g. `MIDDLEWARE` is configured in a single location and not modified 
>> in other files. 
>>
>> Thanks,
>> Matthias
>>
>>
>>
>>

-- 
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/3c783c4b-13ec-4e23-9fe1-101b92e4c49bn%40googlegroups.com.

Re: Integrate dj-database-url into Django

['Tobias McNulty' via Django developers (Contributions to Django itself)]

I started a forum thread on the settings refactor here:
https://forum.djangoproject.com/t/settings-refactor/17352

Regarding the original topic of this thread (
https://code.djangoproject.com/ticket/28236), are we ready to close this as
wontfix? I'm okay not proceeding with it (dj-database-url, django-environ,
etc. are more than fine as stop-gaps), but it would be nice to preclude
further effort/work on this issue if we're never going to move forward with
it. While I realize it was never Accepted, that nuance may be lost on new
visitors given the prior work history on the issue...

Cheers,
Tobias

-- 
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/CAMGFDKSHu9mx366iMkrnZseCtTaPXSbvV3dbNTLosL0B2m-L4Q%40mail.gmail.com.

Re: Can we move the activity on this list to the Forum now?

['Tobias McNulty' via Django developers (Contributions to Django itself)]

As someone who only just joined the forum -- I'm +1:

   - The forum has seen great adoption from what I can tell (nearly half
   the number of posts as django-developers during the same time period, not
   bad given the mailing list's head start in subscribers).
   - It seems beneficial to house future conversations in a single place,
   e.g., so members don't need to subscribe to both the mailing list and forum
   to get the full picture of current active development, set up two different
   sets of mail filters to tag things appropriately, etc...

Would the plan be to switch django-users as well? I think similar arguments
could be made for consolidating those...

(On the other hand, I see little value in switching django-announce and
django-updates, but I'm not necessarily opposed to it either, especially if
there's a way to import the subscribers to those lists...)

Cheers,


*Tobias McNulty*Chief Executive Officer

tob...@caktusgroup.com
www.caktusgroup.com


On Mon, Nov 28, 2022 at 9:05 AM Carlton Gibson 
wrote:

> Hey Roger,
>
> Indeed it does. You can set up Email Mode (that may not be the actual
> name) and it’ll work just like a mailing list.
>
> You can also subscribe to just a particular category, so the Internals one
> would map to the discussion on this list.
>
>
>
> On Monday, 28 November 2022, Roger Gammans 
> wrote:
>
>> Hi
>>
>> I can't speak for others, but I personally STRONGLY value the fact that
>> this discussion happens in my inbox, not on yet another website.
>>
>> But perhaps the forum still supports this reading mode?
>>
>> On Mon, 2022-11-28 at 05:38 -0800, Carlton Gibson wrote:
>>
>> Hi all.
>>
>> Given the issues with Tom's access to the mailing list here, and the fact
>> that the Forum has been active for a few years now, and is a great success,
>> I'd like to revisit whether we can move on-mass (all few of us :) over
>> there?
>>
>> We'd enjoy the benefits of a much nicer system. We'd not have issues such
>> as the current, and we'd be one less item in the pocket of a mega-corp.
>> (You can rank those as you will :)
>>
>> Initially when this can up (a long time ago) Andrew and Tom discussed
>> whether we could import the history here into the forum. I think that's
>> unnecessary. We can still access the history here (until such a day as
>> Google takes it away) at worst -- but, rather, if we can get an archive we
>> could import it into read-only Datasette instance[0] — and that would
>> likely be good enough.
>>
>> Can we move now?
>>
>> Thanks.
>>
>> Kind Regards,
>>
>> Carlton
>>
>>
>> [0]: I'd happily do this.
>>
>> --
>> 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/101f4e6d-9b83-47ab-bb1b-b571402e037dn%40googlegroups.com
>> <https://groups.google.com/d/msgid/django-developers/101f4e6d-9b83-47ab-bb1b-b571402e037dn%40googlegroups.com?utm_medium=email&utm_source=footer>
>> .
>>
>> --
>> 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/4a329eadd5606c2f94aa5638e079800f1914d0d7.camel%40gammascience.co.uk
>> <https://groups.google.com/d/msgid/django-developers/4a329eadd5606c2f94aa5638e079800f1914d0d7.camel%40gammascience.co.uk?utm_medium=email&utm_source=footer>
>> .
>>
> --
> 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/CAJwKpyTSfF51C6ejog0xMd_6s-DofOUT4yaTeWmoc5SEiTY8jQ%40mail.gmail.com
> <https://groups.google.com/d/msgid/django-developers/CAJwKpyTSfF51C6ejog0xMd_6s-DofOUT4yaTeWmoc5SEiTY8jQ%40mail.gmail.com?utm_medium=email&utm_source=footer>
> .
>

-- 
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/CAMGFDKSKe7ZDDwiaBpKtsU0z582K482PFsSpNfTLSvb2B-L95A%40mail.gmail.com.

Re: Integrate dj-database-url into Django

['Tobias McNulty' via Django developers (Contributions to Django itself)]

Hi Carlton,

Responses inline below:

On Mon, Nov 28, 2022, 2:40 AM Carlton Gibson 
wrote:

> Hi Raphael, thanks for picking this up.
>
> Looking at the history here, particularly the discussion here
> https://groups.google.com/g/django-developers/c/UQjpzB39JN0/m/XGqdV8nbBwAJ
> but there are others, the reason this hasn't already happened is that if
> we're going to merge this into core it would be nice (required?) to handle
> extra cases than (to paraphrase) "just what Heroku expects".
>
> It doesn't look like anyone has sat down to spec out exactly what that
> means, but there seem to be plenty of thoughts in the discussion.  ... 🤔
>
> JKM's comment on the thread there is representative of the general
> thought:
>
> > I suspect this is a "good enough is good enough" situation. Something
> like what
> Raffaele is talking about, or dsnparse, or whatever would probably be
> ideal. And
> for something to be merged into core, I think it'd need to be a more full
> solution than just dj-database-url.
>

Isn't this already a more full solution insofar as it supports setting
CACHES as well? This may or may not be correct, but I read the history a
little differently, more that "life happens" and no one quite found the
energy to push the current solution over the finish line (I empathize
completely!).

The trouble with merging a suboptimal solution is that once it's in, it's *very
> hard* to change. We have the whole API stability policy to contend with
> (and rightly so).
> We bring in a half-baked solution; likely "recommend" it (for some value
> of that) and then face a long stream of difficult adjustments whilst we try
> and accommodate the necessary adjustments.
>

I agree 100%, and I feel like we can and will take this into consideration
sufficiently as we refine the current solution, if we continue down this
path.

 Given that dj-database-url is stable, a single line install, and (most
> importantly) not being developed to try and accommodate the issues that
> stopped it just being merged into core already, I think it should continue
> to live as a third-party package.
>
> The place for the development to happen is in dj-database-url or a
> successor package. (The first step would be a Roadmap drawn from the
> historical discussion.)
> Once (if) that gets to the point where it clearly addresses the 90% of
> needs, then there's a case for adding it to core. I don't think we can just
> push forward given that nothing changed in the last few years.
>

Could you (or others) provide some examples of the needs this solution
doesn't address (not necessarily complete, just to give an idea)?

Many thanks,
Tobias

-- 
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/CAMGFDKQg8ikr%2BVh9ZXm2UXJidbz%2BpUr-GvZa%2BKoGz%2BBfRyZggg%40mail.gmail.com.

Re: Potential way forward for DATABASE_URL

['Tobias McNulty' via Django developers (Contributions to Django itself)]

Hi Raphael,

Thanks for taking this on.

Starting with a limited scope seems like a good idea to me.

A couple other things I like about this approach:

- It tackles cache URLs at the same time (it makes sense for them to mirror
one another, IMO).
- No implicit usage of DATABASE_URL, but as you said it still supplies an
easily searchable answer for "Django DATABASE_URL."

Cheers,
Tobias

On Sun, Nov 27, 2022, 2:40 PM Raphael G  wrote:

> Some base industry background. It's a pretty common convention to share
> credentials in environment variables. For many PaaS, it's common to use
> connection URLs to do so. So DATABASE_URL will have a URL like
> postgres://my_user:mypassword@somedomain/database stuffed into a single
> environment variable.
>
> Django expects a configuration dictionary for its drivers. So what do
> people do? People install django-database-url, and pass in the string
> into that library (or rather, the library will read a blessed environment
> variable). Absent that they'll need to manually parse out the information
> and build the configuration dictionary. So if you just have Django time
> to futz around with urlparse
>
> There have been some discussions about how to make this better, including:
>
>- adopting dj-database-url as an "official django project" via DEP 7
>
> 
>- instead adopt a behavior where Django will automatically handle a
>string as an alternative to a configuration dictionary
> (this is discussed in
>the first link as PR 10786)
>- Integrate dj-database-url but expand on it a bit to also help with
>cache configuration, and have backends handle URL parsing
>
> 
>
> These haven't seen much movement in the past couple of years. A comment in
> one of these e-mail threads:
>
> > I suspect this is a "good enough is good enough" situation. Something
> like what Raffaele is talking about, or dsnparse, or whatever would
> probably be ideal. And for something to be merged into core, I think it'd
> need to be a more full solution than just dj-database-url.
>
> dj-database-url takes something from an environment variable and provides
> a configuration dictionary. There's this feeling that having Django
> directly accept a string would feel more natural and correct. There are
> also other libraries like dsnparse, and people proposing things like
> adding a DSN name into settings.
>
> I think of all the options, the third option (the proposal by Tom Forbes)
> is a very good option. What it looks like in practice is the addition of
> the following:
>
>- the ability for database backends to register protocol names for
>URLs, so that postgres://localhost:5432 will properly map to the
>django.db.backends.postgresql backend, but people can show up with
>their own mappings.
>- A configure_db(url) function, that will return a configuration
>dictionary meant for DATABASES
>- A similar configure_cache(url) function that will give cache
>configuration dictionaries meant for CACHES
>
> A thing that is notably absent here is any blessing of DATABASE_URL. You
> have to do
>
> DATABASES = {
> 'default': configure_db(os.environ['DATABASE_URL'])
> }
>
> yourself. It's not "ideal" in that you don't magically get behavior from
> your URLs, but that also means you're just doing something in a
> straightforward way that should be easy to debug with some print statements
> when needed. It feels way less likely for this to be a major design miss.
>
> The motivating examples for the two above being supported is that Heroku
> will provide DATABASE_URL and REDIS_URL.
>
> The nice thing about this solution is that it doesn't block future design
> space. We get a configuration dictionary that matches the existing
> functionality, because the added API is simple it's easy for people to
> inspect the results, and of course it doesn't preclude people from keeping
> on with their existing solutions. There isn't even an assumed usage of
> DATABASE_URL like with dj-database-url! Mostly magic free.
>
I tried to rebase the PR
>  
> including
> the above functionality from a couple years ago, and added some basic
> documentation. This doesn't try and convince users to use this, but I
> believe the usage would be sufficient for simple cases.
>
> So my ask here: how do people feel about moving forward with this limited
> scope? Previous discussions talked about wanting a larger scope for it to
> get merged into core. I believe that instead targetting a smaller scope
> means we can at least provide a workable answer to the DATABASE_URL question
> in the near term. And when consensus coalesces around a good overall answer
> to settings, the actual URL parsing logic will already be present and ev

Re: #21978 include production-ready web server

['Tobias McNulty' via Django developers (Contributions to Django itself)]

Hi Pete,

A pluggable backend sounds like a good idea.

Regarding DJANGO_ENV, why not ship the template with two settings files and
use the existing DJANGO_SETTINGS_MODULE, instead of adding a new
environment variable?

Maybe that would be controversial too, I'm not sure, but perhaps less so
than introducing a new paradigm? In any event, perhaps a pluggable backend
would allow everyone to be happy, or very nearly so... 😅

To be clear, I'm fully in support of this, no matter how it ends up.
Providing a decent production-capable server and some sane
settings/configuration defaults for people to work from -- rather than
having to scour the documentation for every mention of a production
environment and figure out how to make those changes by hand -- will be a
big win IMO. As it stands, first time users might reasonably assume they
should use Apache to deploy to production (maybe they should, I'm not
sure...but I haven't seen it done in over a decade):

"We’ve included this with Django so you can develop things rapidly, without
having to deal with configuring a production server – such as Apache –
until you’re ready for production."

https://docs.djangoproject.com/en/4.1/intro/tutorial01/

Cheers,
Tobias

On Sat, Oct 29, 2022, 7:15 PM Peter Baumgartner 
wrote:

>
>
> On Sat, Oct 29, 2022 at 10:06 AM Peter Baumgartner 
> wrote:
>
>> Thanks for the thorough review Florian! Some comments inline...
>>
>> On Wed, Oct 26, 2022 at 1:30 AM Florian Apolloner 
>> wrote:
>>
>>> Hi Pete,
>>>
>>> this does look interesting. And I agree that this is something that
>>> would be nice to have in core in one form or another. That said I think we
>>> have to do it iteratively (ie in smaller parts) and evaluate along the way.
>>>
>>
>> Agreed. I think adding the additional settings with some sort of
>> production switch is the least obtrusive place to start.
>>
>>
>>>
>>> Since you asked for feedback, I'll tell you what I'd do differently (and
>>> this is also a sign that production environment vary widely).
>>>
>>
>> Production environments do vary widely, but I don't think that should
>> stop us from providing defaults that are one-size-fits-most. startproject
>> already does this and users are welcome to adjust it how they see fit.
>>
>>
>>>
>>>  * As soon as health checks check something aside from simply returning
>>> a 200 status code I'd want to be able to limit access to them
>>>
>>
>> Yep, that seems reasonable. Although depending on the level of failure,
>> you may not be able to log in to see them. Starting with just a view that
>> responds with a 200 is reasonable.
>>
>>
>>>  * I like my dev env to be as close as possible to production so I
>>> usually also use whitenoise in dev. I had to many times where dev worked
>>> and whitenoise in prod failed then :D
>>>
>>
>> Also a good point... I'll add that.
>>
>>
>>>  * I do hate `DJANGO_ENV` but I guess there is no way around it.
>>> Currently my projects often piggy-back on DEBUG but that can be rather hard
>>> from time to time
>>>
>>
>> I'm open to other suggestions here, but am kind of in the same boat.
>> There may be times when you briefly want DEBUG=True in a non-public
>> deployed environment or DEBUG=False in a development environment.
>> Overloading that makes those scenarios a challenge.
>>
>>
>>>  * I prefer settings in settings files (ini/yaml/toml) as opposed to env
>>> variables that leak down the whole process-tree. django-environ does
>>> support this; that said there are other options like dynaconf which also
>>> support hashicorp vault which is a massive plus imo. Just being able to
>>> utilize vault for free from every django application out there would be
>>> stellar.
>>>
>>
>> I'm 100% in agreement here. I wrote goodconf [1] for this before I knew
>> about dynaconf which does a lot of the same things. I would love to see
>> Django adopt a split between "settings" (which I see as things that don't
>> change across environments) and "configuration" (things that you set per
>> environment). I did switch to django-environ's FileAwareEnv [2] which
>> allows loading from files, but not in the yaml./toml sense. I didn't go all
>> in here because I felt like it was a more controversial stance and at the
>> end of the day, you probably still need to support environment variables
>> because many (most?) PaaS providers don't have support for files like that.
>>
>> With the goal of getting something merged into Django eventually, I felt
>> like environment variables were the lowest bar. We have precedence for
>> loading from environment variables with DJANGO_SETTINGS_MODULE. Do you
>> think a more full-featured library like dynaconf would make it harder to
>> push some of this upstream? Users that want to use dynaconf or goodconf or
>> whatever can still edit their settings and use those like they do today.
>>
>> [1] https://github.com/lincolnloop/goodconf
>> [2]
>> https://django-environ.readthedocs.io/en/latest/tips.html#docker-style-file-based-variables
>>
>

Re: Proposal: Add An in-memory data storage backend in Django

['Tobias McNulty' via Django developers (Contributions to Django itself)]

Hi,

I also may be missing some context, but is this the mentioned package?
https://github.com/waveaccounting/dj-inmemorystorage

I have not used it, but it looks like a useful tool to have!

Tobias


On Thu, Oct 20, 2022 at 7:50 PM David Sanders 
wrote:

> Hi,
>
> I may be missing some context here but is this something distinctly
> different from setting SQLite to use in-memory storage [1]? 🤔
>
> [1] https://www.sqlite.org/inmemorydb.html
>
> David
>
> On Fri, 21 Oct 2022, 04:30 Paolo Melchiorre (paulox), <
> pa...@melchiorre.org> wrote:
>
>> Hi all,
>>
>> there is a package that provide in-memory data storage backend, but it's
>> now abandoned.
>>
>> Having support for in-memory data storage could be very useful for Django
>> itself and furthermore it would involve adding a small code with tests that
>> do not justify the creation of a fork of that old package.
>>
>> We are talking about this during the sprints at DjangoCon US 2023 in San
>> Diego with Josh Thomas and Mariusz Felisiak proposed to us to ask here on
>> this list.
>>
>> What do you think about adding an in-memory data storage backend directly
>> in the Django core?
>>
>> Ciao,
>> Paolo
>>
>> --
>> 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/e0f6d509-20d7-4eef-b570-cc53611dca01n%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/CADyZw-64SU%2BdwjKDGmzCZpz06VZ-QUxjb3%2B9RGFp8vqbJSd58Q%40mail.gmail.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/CAMGFDKRiEsi7BqaNUJGFWNYqpfP3Cq8TVx3fQYuuYp9ii-injw%40mail.gmail.com.

Re: Blocking disposable or temporary email addresses

['Tobias McNulty' via Django developers (Contributions to Django itself)]

Hi Yonas,

Thanks for sharing this list. Even so, in my opinion, this feature lives
best outside of Django where it can be appropriately customized as needed
for a given project.

I hope this helps.

Best,
Tobias


On Wed, May 11, 2022, 6:46 PM Yonas 
wrote:

>
> Would syncing the block list from repos like
> https://github.com/disposable-email-domains/disposable-email-domains
> (actively maintained since 2014) ease the burden of updating the list?
> On Thursday, May 12, 2022 at 12:44:28 AM UTC+3 James Bennett wrote:
>
>> On Wed, May 11, 2022 at 2:21 PM Yonas 
>> wrote:
>>
>>> What does the community think about adding a feature to Django where
>>> disposable or temporary emails are not accepted during account registration?
>>
>>
>> I used to try to do this in my django-registration package, but
>> eventually gave up on it because maintaining an up-to-date list of all
>> possible domains and other patterns was not feasible. I expect the same
>> would be true with Django — it would require frequent updates to the list
>> of domains/patterns to block, and people would complain that the updates
>> weren’t fast enough, because Django only releases once a month (and that’s
>> assuming updates to the blocked email list would be considered for
>> inclusion in the monthly bugfix releases, rather than only at feature
>> release updates).
>>
>> So I expect this isn’t something Django could or should 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 view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/b669801b-f695-49c2-9d04-2ff7db74dc58n%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/CAMGFDKRONKrsAw35VBN8%3DYiNWkEzQWd5kUcYH1G8CjqG2eo%3DbQ%40mail.gmail.com.

Re: Improvements to the startproject template

['Tobias McNulty' via Django developers (Contributions to Django itself)]

Tim,

Thanks for taking this on!

Needless to say, I'm all in favor of including a default 'users' app.
Adding one (as has long been recommended by the docs) is a task best
automated.

I've definitely had the "no the other folder" conversation more than enough
times myself. Personally I think I prefer the orderliness of nesting
everything under a single Python package that is the project name, but I'm
not sure how to do that and solve the "two folders with the same name"
problem. In any event, I support whatever the consensus is.

Cheers,
Tobias



On Mon, Apr 18, 2022, 1:17 PM Tim Allen  wrote:

> Greetings, friends!
>
> I've issued a PR that makes two changes to the `startproject` template:
>
>- instead of putting configuration files such
>as `settings.py`, `wsgi.py`, and the
>root `urls.py` in `my_project/my_project`, they are created
>in `my_project/config`
>- start the project with a custom User model app, `users`
>
> Over the years, I've taught or tutored over 100 Djangonauts starting their
> first project. Having to distinguish between two directories with the same
> name is a constant pain point in the teaching process - "cd into my_project
> ... no, the other one!"
>
>
>- The `config` option seemed to be the consensus from this thread in
>the forum: Django New Project Structure/Name - Using Django - Django
>Forum (djangoproject.com)
>
>- Ticket: https://github.com/django/django/pull/15609
>
> It is sometimes better to show rather than tell, so following our own
> documentation and including a custom User model with the initial project
> template reinforces the best practice that we explicitly point out in the
> documentation.
>
>
>- Ticket:  #27909 (Use AUTH_USER_MODEL in startproject template) –
>Django (djangoproject.com)
>
>- Avoids ever having this come up again:
>
> https://www.caktusgroup.com/blog/2019/04/26/how-switch-custom-django-user-model-mid-project/
>
> Here's a link to the PR: https://github.com/django/django/pull/15609
>
> My apologies for not starting with a discussion first. I'm an infrequent
> contributor to the Django codebase!
>
> Regards,
>
> Tim
>
> --
> 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/33cb49d0-2469-47c0-920e-9501245c5a27n%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/CAMGFDKSKKs08Z3rts4Xeewh1fxNkbmt8LyqqHfofAUF0xs0oAg%40mail.gmail.com.

Re: Django website Down

[Tobias McNulty]

Here's the incident report from Fastly:
https://status.fastly.com/incidents/vpk0ssybt3bj


*Tobias McNulty*Chief Executive Officer

tob...@caktusgroup.com
www.caktusgroup.com


On Tue, Jun 8, 2021 at 9:58 AM danushka padrushka 
wrote:

> Hi Wadinga Leonard,
>
> I checked from different networks, it wasn’t working in the morning at
> least where I live (Montréal). After like 30 min I noticed it was working
> fine ☺️
>
> Dan
>
> Sent from my iPhone
>
> > On Jun 8, 2021, at 9:39 AM, Roger Gammans 
> wrote:
> >
> > It may have had something to do with this? I seem to remember fastly
> > did offer some OSS projects some CDN services.
> >
> > https://www.bbc.co.uk/news/technology-57399628
> >
> >
> >> On Tue, 2021-06-08 at 14:17 +0100, Wadinga Leonard Ngonga wrote:
> >> It’s up, I can access it from my location(Buea, Cameroon). Try with a
> >> VPN it could be your ISP.
> >>
> >>
> >>
> >> Sincerely,
> >> Wadinga Leonard.
> >>
> >>> On 8 Jun 2021, at 14:13, danushka padrushka <
> >>> danupadrus...@gmail.com> wrote:
> >>>
> >>> Hi,
> >>>
> >>> Not sure if this is the right email to report it but Django website
> >>> is down,
> >>>
> >>> --
> >>> 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/6EAF8BA5-DD5A-4CF6-85D6-B4216EA5A07E%40gmail.com
> >>> .
> >>> 
> >>>
> >>>
> >>>
> >>> Dan
> >>>
> >>> Sent from my iPhone
> >>>
> >>> --
> >>> 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/6EAF8BA5-DD5A-4CF6-85D6-B4216EA5A07E%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/71749f2f705b9c72827117d3defab2a7f1b35074.camel%40gammascience.co.uk
> .
>
> --
> 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/4411DC00-38AF-4FE2-8073-C550D5486E74%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/CAMGFDKSYMb3boJn6U672vB6bwX5f_ES1aDPwTBjPjA47VRQqpQ%40mail.gmail.com.

Re: #28560 - distinct() on ordered queryset with restricted list of columns returns incorrect result

[Tobias McNulty]

I tend to agree, though I'll note that was also a bug at one point:
https://code.djangoproject.com/ticket/5321

On Wed, Oct 28, 2020 at 5:38 PM Fran Hrženjak 
wrote:

> Personally I would prefer to get a ProgrammingError, so option 3.
>
> Explicit is better then implicit 😁
>
> Here is a great explanation of this exact issue, cleared it up for me:
> https://blog.jooq.org/2018/07/13/how-sql-distinct-and-order-by-are-related/
>
>
>
> On 28.10.2020., at 20:04, Tobias McNulty  wrote:
>
> 
> Hi all,
>
> Starting a thread on ticket #28560
> <https://code.djangoproject.com/ticket/28560>, "distinct() on ordered
> queryset with restricted list of columns returns incorrect result." In a
> nutshell:
>
> $ cat testapp/models.py
>
> from django.db import models
>
>
>
> class School(models.Model):
>
> name = models.CharField(max_length=255)
>
> county = models.CharField(max_length=255)
>
>
> class Meta:
>
> ordering = ("name",)
>
> $ python manage.py shell
>
> ...
>
> >>> from testapp.models import School
>
> >>> str(School.objects.values("county").distinct().query)
>
> 'SELECT DISTINCT "testapp_school"."county", *"testapp_school"."name"*
> FROM "testapp_school" ORDER BY "testapp_school"."name" ASC'
>
> Note the "name" column is added implicitly to the SELECT clause due to the
> default ordering on the model (I believe with good reason, since #7070
> <https://code.djangoproject.com/ticket/7070>). This is not specific to a
> default ordering; it's also possible to generate unintended results with a
> mismatching list of columns between an explicit order_by() and values().
>
> It's possible to fix with an empty order_by():
>
> >>> str(School.objects.values("county").order_by().distinct().query)
>
> 'SELECT DISTINCT "testapp_school"."county" FROM "testapp_school"'
>
>
> But, this still feels like a case where we could do better. Some potential
> options:
>
>1. It looks like there was an initial attempt to fix the issue with a
>subquery, but from what I can tell it was not possible to preserve
>ordering
><https://github.com/django/django/pull/9055#issuecomment-338276279> in
>the outer query.
>2. My colleague Dmitriy pointed out that there may be a precedent for 
> excluding
>the default ordering <https://github.com/django/django/pull/10005> for
>    queries like this.
>3. An option I suggested on the ticket
><https://code.djangoproject.com/ticket/28560#comment:13> is to raise
>an error if the list of columns in values() is insufficient to run the
>requested query (i.e., never add a column implicitly if the user specified
>a list of columns via values() or values_list()).
>
> What do others think? What are other potential fixes I'm not thinking of?
>
> Cheers,
>
>
> *Tobias McNulty*Chief Executive Officer
>
> tob...@caktusgroup.com
> www.caktusgroup.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/CAMGFDKRQsbUz%3DeYKxX2U%2B892AgQbXr%3DMA9AiWw9vfiPcM%2BnAXw%40mail.gmail.com
> <https://groups.google.com/d/msgid/django-developers/CAMGFDKRQsbUz%3DeYKxX2U%2B892AgQbXr%3DMA9AiWw9vfiPcM%2BnAXw%40mail.gmail.com?utm_medium=email&utm_source=footer>
> .
>
> --
> 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/942B7E2C-7B44-4ECF-9105-6EAB90874E98%40gmail.com
> <https://groups.google.com/d/msgid/django-developers/942B7E2C-7B44-4ECF-9105-6EAB90874E98%40gmail.com?utm_medium=email&utm_source=footer>
> .
>

-- 
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/CAMGFDKQ_p-ktnxqC6G%3DE%2BDdbBjmmFedr6wTzX3MGS_oH6JwQag%40mail.gmail.com.

Re: #28560 - distinct() on ordered queryset with restricted list of columns returns incorrect result

[Tobias McNulty]

On Wed, Oct 28, 2020 at 3:38 PM Adam Johnson  wrote:

> I’d vote for option 2. I don’t think it can be expected the ordering will
> be obeyed when not selecting the columns it includes.
>

Thanks! To make sure I understand, are you suggesting we should leave the
behavior with an explicit order_by() as-is, or not add "name" to the SELECT
in this case either?

>>> str(School.objects.values("county").order_by("name").distinct().query)
'SELECT DISTINCT "testapp_school"."county", "testapp_school"."name" FROM
"testapp_school" ORDER BY "testapp_school"."name" ASC'


*Tobias McNulty*Chief Executive Officer

tob...@caktusgroup.com
www.caktusgroup.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/CAMGFDKQTNE%3D%2B%2B%2B0HPqZAndPzkAO4sWxKbqxhG9%2BLJpFOJiL5Ag%40mail.gmail.com.

#28560 - distinct() on ordered queryset with restricted list of columns returns incorrect result

[Tobias McNulty]

Hi all,

Starting a thread on ticket #28560
<https://code.djangoproject.com/ticket/28560>, "distinct() on ordered
queryset with restricted list of columns returns incorrect result." In a
nutshell:

$ cat testapp/models.py

from django.db import models



class School(models.Model):

name = models.CharField(max_length=255)

county = models.CharField(max_length=255)


class Meta:

ordering = ("name",)

$ python manage.py shell

...

>>> from testapp.models import School

>>> str(School.objects.values("county").distinct().query)

'SELECT DISTINCT "testapp_school"."county", *"testapp_school"."name"* FROM
"testapp_school" ORDER BY "testapp_school"."name" ASC'

Note the "name" column is added implicitly to the SELECT clause due to the
default ordering on the model (I believe with good reason, since #7070
<https://code.djangoproject.com/ticket/7070>). This is not specific to a
default ordering; it's also possible to generate unintended results with a
mismatching list of columns between an explicit order_by() and values().

It's possible to fix with an empty order_by():

>>> str(School.objects.values("county").order_by().distinct().query)

'SELECT DISTINCT "testapp_school"."county" FROM "testapp_school"'


But, this still feels like a case where we could do better. Some potential
options:

   1. It looks like there was an initial attempt to fix the issue with a
   subquery, but from what I can tell it was not possible to preserve
   ordering
   <https://github.com/django/django/pull/9055#issuecomment-338276279> in
   the outer query.
   2. My colleague Dmitriy pointed out that there may be a precedent
for excluding
   the default ordering <https://github.com/django/django/pull/10005> for
   queries like this.
   3. An option I suggested on the ticket
   <https://code.djangoproject.com/ticket/28560#comment:13> is to raise an
   error if the list of columns in values() is insufficient to run the
   requested query (i.e., never add a column implicitly if the user specified
   a list of columns via values() or values_list()).

What do others think? What are other potential fixes I'm not thinking of?

Cheers,


*Tobias McNulty*Chief Executive Officer

tob...@caktusgroup.com
www.caktusgroup.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/CAMGFDKRQsbUz%3DeYKxX2U%2B892AgQbXr%3DMA9AiWw9vfiPcM%2BnAXw%40mail.gmail.com.

Re: Ticket update ending up in gmail spam

[Tobias McNulty]

Thanks for the report. The SPF record was updated today around 1:30pm EDT.
Please let us know if you continue to see issues.


On Thu, Oct 22, 2020 at 12:10 PM Adam Johnson  wrote:

> Perhaps there's a task for the ops team to check the SPF/DKIM/DMARC
> records for djangoproject.com ?
>
> ‪On Thu, 22 Oct 2020 at 16:56, ‫אורי‬‎  wrote:‬
>
>> Hi,
>>
>> Mail I received from djangoproject.com in 2019 had SPF pass (by best
>> guess record). Mail I received from djangoproject.com in 2020 had
>> SPF neutral. Maybe you should update the SPF records for
>> djangoproject.com.
>>
>> Uri.
>> אורי
>> u...@speedy.net
>>
>>
>> On Thu, Oct 22, 2020 at 6:21 PM Peter Inglesby 
>> wrote:
>>
>>> Hi folks,
>>>
>>> An email with an update on ticket that I'm subscribed to has ended up in
>>> my gmail spam folder:
>>>
>>> [image: image.png]
>>>
>>> I'm not sure what to suggest!
>>>
>>> Peter.
>>>
>>> --
>>> 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/CAENJrP%3DkH29Yq%3D3AsMpmyYSavD884pZ%3D%2B_MCVxnn7DLv4MhnVw%40mail.gmail.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/CABD5YeFg9-MNhpgDhE%2BBtheGLe9%3DNAL7CaUZfzTAj_00W%2BPR%3DA%40mail.gmail.com
>> 
>> .
>>
>
>
> --
> Adam
>
> --
> 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/CAMyDDM3WEtY1f58%3DsJm8nd9ZdRCpnpZznBL25-KbGhDhPpOyJw%40mail.gmail.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/CAMGFDKToaJTZN4sbR7H%3DbDVU3dh%3Duz96_Ses6J%3DR8qUYQ3GJSg%40mail.gmail.com.

Re: Cache framework

[Tobias McNulty]

On Tue, Aug 18, 2020 at 9:34 AM Carlton Gibson 
wrote:

> I think we SHOULD bring a redis cache backend into core.
>
> The recent survey showed 70% of our users using redis for caching, with
> 20%+ using memcached.
>
> Nick is working on
> https://github.com/django/django/pull/13310 now.
>
> This’ll give us three memcached backends and zero for redis.
> That doesn’t seem right.
>
> The cache backend API is small and redis is stable. I think we can offer
> that, freeing third party packages some work, to do the more interesting
> things.
>

+1, even as someone who does not self-identify as a Redis enthusiast.


*Tobias McNulty*Chief Executive Officer

tob...@caktusgroup.com
www.caktusgroup.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/CAMGFDKT%2B_x%3D2Yb-d1SuzcTpzuzhDmT%2Bh1FqpuV_5i2%2BY%3D%2B32OA%40mail.gmail.com.

Re: Proposal - Warn user when creating or applying a delete migration?

[Tobias McNulty]

I'm +1 to doing *something.* Absent a louder reminder, I think it's
unrealistic to expect everyone to read the output of makemigrations all the
time.

As others have said, I'm not sure `manage.py migrate` is the right time. I
think it's too late. The code may have already been committed, who knows
what machine the migrations are being run on, etc.

During makemigrations, on the other hand, I don't see anything wrong with
formatted text or +/-, but I might go a step further. We already prompt for
things like renames and merges. Why not forcibly gain user acceptance
before creating a migration that deletes something? We could repeat the
reminder to double check it or allow the user to cancel the migration
altogether, for example:

"You are creating a migration that DELETES one or more columns or database
tables. As with any migration, if you continue, you should inspect the
created migration BEFORE running `manage.py migrate` to ensure it does what
you expect. Press Y to continue or N to cancel." (needs copyediting of
course)

It would be easy enough to bypass with --no-input if someone doesn't want
the interruption.

Cheers,


*Tobias McNulty*Chief Executive Officer

tob...@caktusgroup.com
www.caktusgroup.com


On Tue, Jun 16, 2020 at 2:30 AM Carlton Gibson 
wrote:

> Looking at the proposed ticket here #31700
> <https://code.djangoproject.com/ticket/31700>, I'm *Meh* at best:
>
> * - + ~
> * Green, yellow, red
>
> I'm not sure I want to look at either of those. Visual noise for X
> benefit, where I think X is likely very small.
> Not sure it's worth the complication.
>
> I'll close as needsinfo. If there's a lot of +1s here then we can reopen
> and accept.
>
> Thanks.
> C.
>
> On Friday, 12 June 2020 13:57:06 UTC+2, Tom Forbes wrote:
>>
>> However we could make the `makemigrations` output more noticeable if it
>> contains destructive operations? We could make the this line[1] output red
>> text on destructive operations, yellow on maybe destructive (like altering
>> a type), and green on safe operations?
>>
>> 1.
>> https://github.com/django/django/blob/master/django/core/management/commands/makemigrations.py#L216
>>
>> --
> 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/91028857-8ef6-42cc-991c-3c092370341co%40googlegroups.com
> <https://groups.google.com/d/msgid/django-developers/91028857-8ef6-42cc-991c-3c092370341co%40googlegroups.com?utm_medium=email&utm_source=footer>
> .
>

-- 
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/CAMGFDKQ8chsk0OVq9OVvx0BqspR7Phs8qePkSNW7V2oSXboZPQ%40mail.gmail.com.

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

[Tobias McNulty]

Tim your point is well made. I'm left  with the feeling that an imperfect
convention is really not so bad, and possibly not worth the huge number of
global developer hours it would cost to effect such a change.

Plus (I make this argument mostly in jest), the new names, because they are
more Pythonic, probably would not stick out so well / not be as easy to
search for. :D

Tobias


On Sat, May 9, 2020, 12:41 PM Tim Allen  wrote:

> I'm tentatively +1 on this change... but...
>
> While it may be a straightforward operation to do a case sensitive search
> and replace in most code bases, it is not trivial to do so on the rest of
> the web. If we're going to do this, we must realize that this will
> invalidate thousands of examples, tutorials, and answers in communities
> such as Stack Overflow, the Django Forum, the Django Girls Tutorial, and
> the archive of this Google Group. It has been a few years now since Django
> 2.0, and I still find myself frequently helping junior developers amend
> their PRs to move to `path` and `re_path` instead of `url`, which they
> copypasta'd from somewhere. I was also for that change, but as a community,
> we need to be cognizant of the fact that as its ambassadors, we are going
> to have a fair amount of work to do to properly spread the word about a
> change like this.
>
> There are many possible responses to why that shouldn't be happening in a
> perfect world, unfortunately, we have to exist in this reality! (I'm hard
> at work at the unreality PR for Django 5.0.)
>
> So let's make sure we consider the full impact of this change before we do
> it. I have some pet peeves about Django naming choices, but where do we
> stop? Two examples:
>
> * createsuperuser -> create_super_user, queryset -> query_set,  for
> readability and to be more Pythonic
> * HttpResponse should be HTTPResponse, like DjangoJSONEncoder, for
> example. (From PEP-8: "Note: When using acronyms in CapWords, capitalize
> all the letters of the acronym. Thus HTTPServerError is better than
> HttpServerError.")
>
> Something to consider for the future about when the churn is worth it, and
> when it isn't. Thanks, y'all.
>
>> --
> 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/5022af59-4280-4dca-a33e-d7ec79bc131b%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/CAMGFDKQwPiaS2UtCnaTQ-Q0HL7ZAP1iQyWDraECEiDKgj1gnsA%40mail.gmail.com.

Re: ngettext_lazy and ngettext

[Tobias McNulty]

st .po file loaded will not influence the rest of
>> the files.
>>
>> If you can revert such a change which was made, maybe even by mistake, in
>> Django 2.2 and then fix the problem in Django 3.0 it may help not only
>> Speedy Net but possibly anyone using Django with the Hebrew locale. You
>> might not have made a deliberate decision to change Hebrew translation in
>> Django 2.2, but it was changed from the change in the .po file from
>> Transifex. But you (the Django developers) can make a deliberate decision
>> to fix it. Or alternatively, if you fix the problem in Django 3.0 (or even
>> 3.1 or 3.2) I might upgrade Speedy Net directly from 2.1 to 3.0 etc.
>> without using 2.2 at all. But since 2.2 is an LTS version, I think you
>> should make an effort to make it work, and therefore revert the
>> plural-forms definition to the one used by Django 2.1. At least in Hebrew,
>> but maybe in any language where it has changed.
>>
>> You might not have noticed this issue before because there are not many
>> websites using these languages with Django, however for these websites this
>> is a serious bug. I'm waiting for any solution to this problem before I
>> upgrade to any Django version beyond 2.1. I even thought about forking
>> Django and reverting this definition myself, but I prefer if Django itself
>> will do it then for me forking Django. If I work Django I might not be able
>> to apply all the changes you make in future releases, including security
>> issues which might arise.
>>
>> Have you found any .po file of Django, in Hebrew, where the third and
>> fourth strings are not identical to the second one? I'm currently not
>> familiar with such a .po translation.
>>
>> אורי
>> u...@speedy.net
>>
>>
>> On Sun, Nov 24, 2019 at 2:50 AM Tobias McNulty 
>> wrote:
>>
>>> ‪On Sat, Nov 23, 2019 at 9:17 AM ‫אורי‬‎  wrote:‬
>>>
>>>> By the way, I read here that this bug it the fault of Transifex (not
>>>> Django). I'm not sure what that means, it worked in Django 2.1. Someone
>>>> made a decision to change something in Django 2.2, how can it be Transifex?
>>>> It must be a decision of the Django developers. If Transifex has bugs, why
>>>> not use a previous version which worked? As far as I would suggest, I would
>>>> postpone using the 4-strings translation (or up to 6 strings in some
>>>> languages) to Django 5.0 or 10.0. Is it really that important to break all
>>>> the 2-strings translations which worked?
>>>>
>>>
>>> As far as I understand, the issue is the translations that are pulled in
>>> from Transifex (it's not a version of Transifex that we can control). I
>>> would hazard a guess that the same issue would occur with Django 2.1 if the
>>> translations were updated; i.e., it's simply a matter of timing that it
>>> happened to break with Django 2.2.
>>>
>>> There is some sample code in the ticket which might be good to try, to
>>> see if it fixes the issue for you:
>>> https://code.djangoproject.com/ticket/30439#comment:7
>>>
>>> Cheers,
>>>
>>>
>>> *Tobias McNulty*Chief Executive Officer
>>>
>>> tob...@caktusgroup.com
>>> www.caktusgroup.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/CAMGFDKTM_uhYYC7R7oaADfK%3D_4kaMNjH5U8FQ1q%3DYVdutzpwEg%40mail.gmail.com
>>> <https://groups.google.com/d/msgid/django-developers/CAMGFDKTM_uhYYC7R7oaADfK%3D_4kaMNjH5U8FQ1q%3DYVdutzpwEg%40mail.gmail.com?utm_medium=email&utm_source=footer>
>>> .
>>>
>> --
> 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/CABD5YeFrEqL-ksknPfyKggASH1WKwNX1i3AeKxVOzP38TuPS_w%40mail.gmail.com
> <https://groups.google.com/d/msgid/django-developers/CABD5YeFrEqL-ksknPfyKggASH1WKwNX1i3AeKxVOzP38TuPS_w%40mail.gmail.com?utm_medium=email&utm_source=footer>
> .
>

-- 
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/CAMGFDKTdj4KL_P3kaft1e5hwA%3DYWGDs%3DojWNUJKb05GBw%3D2M5g%40mail.gmail.com.

Re: ngettext_lazy and ngettext

[Tobias McNulty]

‪On Sat, Nov 23, 2019 at 9:17 AM ‫אורי‬‎  wrote:‬

> By the way, I read here that this bug it the fault of Transifex (not
> Django). I'm not sure what that means, it worked in Django 2.1. Someone
> made a decision to change something in Django 2.2, how can it be Transifex?
> It must be a decision of the Django developers. If Transifex has bugs, why
> not use a previous version which worked? As far as I would suggest, I would
> postpone using the 4-strings translation (or up to 6 strings in some
> languages) to Django 5.0 or 10.0. Is it really that important to break all
> the 2-strings translations which worked?
>

As far as I understand, the issue is the translations that are pulled in
from Transifex (it's not a version of Transifex that we can control). I
would hazard a guess that the same issue would occur with Django 2.1 if the
translations were updated; i.e., it's simply a matter of timing that it
happened to break with Django 2.2.

There is some sample code in the ticket which might be good to try, to see
if it fixes the issue for you:
https://code.djangoproject.com/ticket/30439#comment:7

Cheers,


*Tobias McNulty*Chief Executive Officer

tob...@caktusgroup.com
www.caktusgroup.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/CAMGFDKTM_uhYYC7R7oaADfK%3D_4kaMNjH5U8FQ1q%3DYVdutzpwEg%40mail.gmail.com.

Re: Python version support for LTS Django (in particular v2.2)

[Tobias McNulty]

On Wed, Oct 30, 2019 at 12:29 PM Carlton Gibson 
wrote:

> That _highly recommend_ sentence could go:
>
> > We highly recommend and only officially support the latest point release
> of each support Python series.
>

 👏 Love it! (though perhaps drop or edit the second "support")

Tobias

-- 
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/CAMGFDKQipHMR5VyM-VvCx0uPB1E9DPeTOX08fL%3DwYR%2B%3D%2B7GTgw%40mail.gmail.com.

Re: Python version support for LTS Django (in particular v2.2)

[Tobias McNulty]

tl;dr: I'm in favor of officially supporting 3.8, if it looks like it won't
be so hard to do (and especially if doing so will result in a net decrease
in the support burden).

Long answer:

I'm not sure if this was prompted in part by my question in #django-dev...
but consider me one of the people who was confused about this. (And thanks
Mariusz for reminding me of this page which more clearly lays out the
supported Django/Python version combos:
https://docs.djangoproject.com/en/dev/faq/install/#what-python-version-can-i-use-with-django)
:)

At least, we may wish to clarify the 2.2 release notes to say that versions
before and after those explicitly listed are NOT supported (and/or link
people to the above page from the release notes). Depending on how closely
one is paying attention (I wasn't), it's possible to read this sentence and
think that Django actually *wants *me to use Python 3.8 with Django 2.2:

"We highly recommend and only officially support the latest release of each
series." (https://docs.djangoproject.com/en/2.2/releases/2.2/)

(I think) I see now that that's referring to the latest release of *Django*
rather than *Python*, but I'm still not entirely sure about that. (The
other possibility being that that language is a holdover from the time when
we were supporting both Python 2 and 3.)

Cheers,


*Tobias McNulty*Chief Executive Officer

tob...@caktusgroup.com
www.caktusgroup.com


On Wed, Oct 30, 2019 at 10:56 AM Carlton Gibson 
wrote:

> Sorry typo there. Should say:
>
> > Django 2.2 officially only supports up to Python 3.7.
>
> Otherwise the issue doesn't make sense.
>
> --
> 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/6a01c30f-3a41-4d66-b40d-c8de221a62fb%40googlegroups.com
> <https://groups.google.com/d/msgid/django-developers/6a01c30f-3a41-4d66-b40d-c8de221a62fb%40googlegroups.com?utm_medium=email&utm_source=footer>
> .
>

-- 
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/CAMGFDKR8EdXd_9ZwbPK2rk1BSecFQ3bRypTOXOKZb3ajYkRB6g%40mail.gmail.com.

Re: Pre-proposal: adopt dj-database-url as a DEP 7 official project

[Tobias McNulty]

I think it's a great idea.

On Thu, Jul 18, 2019, 12:46 PM Jacob Kaplan-Moss  wrote:

> Hi folks -
>
> I’d like to gauge interest in adopting dj-database-url
> (http://github.com/jacobian/dj-database-url) as an official project
> (
> https://github.com/django/deps/blob/master/final/0007-official-projects.rst
> ).
> This is my pre-proposal. I think dj-database-url is very widely-used, and
> scratches a specific but annoying itch. Maintenance burden is minimal, but
> important.
>
> What do other folks think? DEP 7 asks us to
>
> > solicit feedback from the community and work out if there is rough
> agreement
> > that the project is a good thing for Django to adopt, particularly
> focusing on
> > any alternative approaches to the same problem and the relative merits
> of them,
> > including code design, scalability, alignment with existing Django
> design and
> > philosophy, and having an available development and maintenance team.
>
> So - thoughts?
>
> I'm volunteering to be the shepherd, but do intend to form a larger team.
>
> I've also opened https://github.com/jacobian/dj-database-url/issues/120
> as another place for this discussion. Please feel free to comment either
> place.
>
> [Backstory, and why this is living on my github right now. @kennethreitz
> was
> looking for a new maintainer, and reached out to me to see if Django might
> be
> interested. I thought perhaps so, and offered to take over maintainership
> in the
> meantime while we work through the DEP 7 process. If it turns out that an
> Official Project is the wrong home for this, I'll either maintain it
> long-term
> or transfer it again.]
>
> Jacob
>
> --
> 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/c4044098-d97f-44be-8859-b05cb594a7be%40Spark
> 
> .
> 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/CAMGFDKRakWoQYehp_ccnhTvbQWY3a2CN2k_iob2fsL7bwv%2BRcQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Deferring "Sign the CLA"

[Tobias McNulty]

On Wed, May 1, 2019 at 8:56 AM Florian Apolloner 
wrote:

> On Saturday, April 27, 2019 at 7:26:58 PM UTC+2, Carlton Gibson wrote:
>>
>> Right now I just wanted to move it down the page.
>>
>
> By all means do so…
>

+1


> I vaguely remember talking to Jacob when I saw him last and his stance on
> it was that we either do not need the CLA at all anymore or something like
> docusign would be enough. For instance Ansible has this
> https://docs.ansible.com/ansible/latest/community/contributor_license_agreement.html
> and I am pretty sure Redhat had lawyers go over that…
>

This is great. Is there someone from the DSF on this list who would be
willing to consult with a DSF attorney to see if language like this (and no
signature requirement) would work?

Tobias

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

Re: Deferring "Sign the CLA"

[Tobias McNulty]

I'd be happy to try setting something up, but a quick search didn't turn up
any obvious choices.

In the absence of information to the contrary, I'd hazard a guess that we
still need the CLAs...

Tobias

On Sat, Apr 27, 2019, 1:26 PM Carlton Gibson 
wrote:

>
> On 27 Apr 2019, at 18:51, Florian Apolloner  wrote:
>
> I think the question is if we need those at all. This is something the DSF
> should be able to answer.
>
>
> Ah, you’ve preempted a later question. 🙂
>
> Right now I just wanted to move it down the page.
>
> Maybe some online signing service would be good. (?)
> (Anyone think they could get us setup quickly?)
>
> I mentioned tying it into the Github workflow a while back, but that’s
> probably overkill.
> (We don’t have so many signings that an online service we link to wouldn’t
> be enough, is the thought.)
>
> I’ve asked Frank (DSF president) if the board can discuss whether we still
> need the CLA.
>
> C.
>
> --
> 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/F70B1E18-7FF7-4985-9906-46D5A4677C11%40gmail.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/CAMGFDKQh4Dtk43KWsYNgWP%3DespMw3X0%3Dod5he8%3D%3Ds9oPvP8X-g%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Proposal to format Django using black

[Tobias McNulty]

FWIW, I like that we have high standards for concise and readable comments
with proper grammar, especially because I myself often need a little extra
push in that department. And I'm not easily convinced by the arguments that
sound a whole lot like "I've written the code and don't have time to clean
this up." In the thick of the moment it's easy to assume a solution will be
obvious to others reading the code, when in reality taking a few extra
minutes to clearly write down *why *something is the way it is (not to
mention making the code itself readable in the first place) will save
potentially hours of someone else's time later on. This is precisely what
code reviews are for; to make sure we're handing down well-written,
described, and documented code for those who come after us (including
perhaps ourselves, a year or two down the road). The benefit to us as
contributors is that it makes us stronger developers, and I think that
might get forgotten sometimes.

I've continued to follow along in this thread and remain fairly ambivalent
about Black. I see how it will simplify many things; on the other hand, I
like my multi-line lists formatted my way. (Not poking fun, I really do.)
That said, if Black will truly remove some significant hurdles, let's do
it, but we should remain clear-headed about the fact that it's not going to
remove from the equation what some may feel is nitpicking and others would
argue is a necessary part of maintaining our high standards.

Herman, if you haven't been scared away from this just yet, I might suggest
trying to summarize the discussion and your recommendation/proposal given
the reactions so far (could be a DEP <https://github.com/django/deps> but
doesn't have to be, IMO). I do feel there's a pragmatic solution in here
somewhere.

Best to all,
Tobias



*Tobias McNulty*Chief Executive Officer

tob...@caktusgroup.com
www.caktusgroup.com

On Fri, Apr 19, 2019 at 8:52 AM Tim Graham  wrote:

> I'm sorry for establishing some (foolish?) guidelines that discouraged
> some people from contributing. I didn't establish those guidelines merely
> to be pedantic, but perhaps I'm too much of a perfectionist at times.
>
> After GitHub allowed mergers to amend pull requests, I often made cosmetic
> adjustments myself to eliminate the trivial back and forth that some have
> lamented. I never blocked a merge merely for trivial cosmetic reasons.
>
> On Friday, April 19, 2019 at 3:25:24 AM UTC-4, Luke Plant wrote:
>>
>> Hi all,
>>
>> An alternative solution to the problem of nit-picky, formatting related
>> PR reviews is simple: *let's not do that*.
>>
>> We already have an automated code formatting enforcer, flake8. Let's
>> simply drop the requirement on fixing anything that flake8 doesn't pick up.
>> A committer can fix up style issues if they want to, but shouldn't make
>> anyone else do it. This would mean most of the stuff on our coding style
>> page
>> <https://docs.djangoproject.com/en/2.2/internals/contributing/writing-code/coding-style/>
>> should just be delete, or at least not enforced - by which I mean almost
>> anything that can't be enforced by a tool (such as isort, flake8, editors
>> via .editorconfig etc.), and has no non-local effects. (So consistent
>> naming of classes/functions *should* be enforced, because that affects
>> other people's ability to use the code).  Large parts of that page are just
>> duplicating of flake8/isort rules anyway. Honestly, does it kill us if
>> someone writes "we" in a code comment? And black couldn't help with some of
>> these things anyway. Let's just stop being code review jerks.
>>
>> I'm kind of ambivalent on black itself. Certainly there are cases where
>> it makes code less readable (a significant sin in my book) e.g. lists that
>> are better displayed vertically, as mentioned already, and there are cases
>> where it makes your diff larger than it needs to be (e.g. when it decides a
>> list is now too long and needs to be re-formatted vertically). If we adopt
>> black we'd have to live with those annoyances. Alternatively, we can live
>> with the annoyance that code formatting is not perfectly consistent and we
>> accept less than 'perfect' PR. But we should just live with those things:
>>
>>
>> *A* *foolish* *consistency* *is* *the* *hobgoblin** of little minds*
>>
>>
>> And if our consistency requirements are causing problems for people
>> attempting to contribute, they are foolish and should be dropped.
>>
>> My 2 ¢.
>>
>> Luke
>>
>>
>> On 18/04/2019 16:03, Jani Tiainen wrote:
>>

Re: Force "required" fields to be included in a ModelForm

[Tobias McNulty]

There are plenty of use cases when this behavior wouldn't be desired, such
as editing the same model object with 2+ different model forms. Such a
pattern might be more common when editing an existing object, but isn't out
of the question for creating new objects, either (think of a multi-step
form wizard).

Cheers,
Tobias

On Tue, Apr 16, 2019, 8:34 PM Will Gordon  wrote:

> In the same way that editable fields are forced to not be included in a
> ModelForm (
> https://github.com/django/django/blob/master/django/forms/models.py#L146),
> I would like to propose that "required" fields (`blank=False`) be forced to
> be included in a ModelForm.
>
> While I understand that a developer can force this inclusion themselves,
> but on a large project, it should not be necessary to always ensure that a
> Model and ModelForm are in sync.
>
> Since this is probably a non-trivial patch (
> https://docs.djangoproject.com/en/dev/internals/contributing/writing-code/submitting-patches/#non-trivial-patches)
> I need to provide evidence that this has been discussed. As such, I'm open
> to any and all opinions!
>
> --
> 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/980d8112-d51c-4e88-a17f-5e9a4a3577d2%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/CAMGFDKQ4Pk172H-Mo38cnYsaY%2BNC255qkLo8Q5ZTMm8bkVeGnQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Proposal to format Django using black

[Tobias McNulty]

On Sun, Apr 14, 2019 at 3:11 AM Nick Sarbicki 
wrote:

> Just going to say that one of the main frustration points I've had when
> making a contribution is having to fix small formatting errors (often minor
> things in docstrings which aren't _always_ consistent).
>

I constantly need to be reminded to shorten docstrings and comments (and
sometimes remove "We" from the beginning of such strings). Unfortunately
(though understandably), Black won't help with any of these issues, and
we'll still be left with the same back and forth about grammar, wrapping,
etc. in comments and docstrings. (Again, as of mid-2018 there is
the max-doc-length option for flake8 that could help with this somewhat,
but that change can be made independently.)

I'm not arguing against Black adoption, but I don't think it's going to
eliminate from the review process what may sometimes feel like inertia...

Tobias

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

Re: Proposal to format Django using black

[Tobias McNulty]

On Sat, Apr 13, 2019 at 11:35 AM Herman S  wrote:

> I've set up how this _could_ look depending on some configurables in Black:
>
> * Default config: https://github.com/hermansc/django/pull/1
> * Line length kept at 119: https://github.com/hermansc/django/pull/3
> * Line length kept at 119, no string normalization:
> https://github.com/hermansc/django/pull/2


Apologies, somehow I missed these links on the first read. Go here for an
overview of lines changed, don't use my numbers. :-)

Tobias

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

Re: Proposal to format Django using black

[Tobias McNulty]

On Sat, Apr 13, 2019 at 12:07 PM Florian Apolloner 
wrote:

> As expressed at Djangocon Europe, I am hugely in favor for adopting black.
>

A quick glance suggests this would result in ~20k lines changed (~27% of
non-whitespace, non-comment code lines) in django/ and ~58k lines changed
(~41%) in tests/ (with `--line-length=119`). After the initial pass to fix
everything `black -l 119 tests/ django/` takes only 2.3 seconds to run (!),
though I'm sure my OS had all the files cached at that point.

Without normalizing strings, the number of changed lines comes down to ~14k
(~19%) for django/ and ~23k (~16%) for tests/ (with
`--skip-string-normalization --line-length=119`).

I'm sure some people will see this as "a ton" and others "only that much?"
:-)

(My line counts are imperfect and approximate, and you'll likely get
somewhat different numbers if you try this yourself.)

If we choose to do this there are a few things to consider:
>
>  * Line-length, we probably want to stay at 119 I guess
>

Perhaps we could compromise and choose something in the middle, for the
reasons noted in the docs:
https://black.readthedocs.io/en/stable/the_black_code_style.html#line-length

We should also consider adding max-doc-length for flake8 to our setup.cfg,
and/or forego the shorter requirement for comments/docstrings *if* we
shorten the maximum line length for code.

This section
<https://docs.djangoproject.com/en/dev/internals/contributing/writing-code/coding-style/>
in the docs will need updating if we hand this off to a 3rd-party formatter
(in particular the sentence, "Don’t limit lines of code to 79 characters if
it means the code looks significantly uglier or is harder to read." since
we'll no longer have the option of shortening lines to 79 characters
arbitrarily).

 * String normalization, I'd be in favor of following black defaults here,
> but I am open to be convinced otherwise
>

It'd be nice to minimize the diff, but I'd be fine either way. If we're
going to do it eventually, better to do so all at once.


>  * We will need to adjust the isort configuration (
> https://github.com/ambv/black/blob/master/README.md#how-black-wraps-lines
> )
>

+1

Overall, the main downside I see is the large, fairly useless changeset
this would create and the impact it would have, such as reduced utility of
`git blame` for some portion of the code for the foreseeable future and
interruption to all in-progress PRs. Problems that can be worked around,
sure, but it would be an interruption to ongoing work nonetheless.

One question: Would we want to update some/all code samples in the docs
with the same code style? I imagine that could be a fairly time-intensive
endeavor, unless someone's already found a way to automate the process. In
particular, Black's format for chaining method calls
<https://black.readthedocs.io/en/stable/the_black_code_style.html#call-chains>
differs from Django's preferred style
<https://docs.djangoproject.com/en/2.2/topics/db/queries/#chaining-filters>.
Applying this standard to the docs without discretion may lead to less
readable docs, IMO...on the other hand, it's odd to have code samples that
don't pass our own tests...

In any case, while this sounds like a non-trivial project with some
questions to work through yet, I too like not having to worry about code
formatting and don't have any real objections to this.

Cheers,



*Tobias McNulty*Chief Executive Officer

tob...@caktusgroup.com
www.caktusgroup.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 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/CAMGFDKQo_7aru%3DGJWQGj8g1Fv69iq2H3Wp6%3D0%2Bdp2NKTaHh4OA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Use CDN for djangoproject.com

[Tobias McNulty]

Last week we had an average hit ratio of around 63%, including ~10 purges
that dropped the rate down temporarily before the cache rebuilt:
[image: Screenshot 2019-04-11 09.37.57.png]
In terms of bandwidth, we're averaging around 5 GB/day for docs and 10
GB/day for static. Giving static its own domain may actually be saving us a
good bit of bandwidth (previously each subdomain had its own /s/ prefix
from which an identical set of static files was served).

Cheers,


*Tobias McNulty*Chief Executive Officer

tob...@caktusgroup.com
www.caktusgroup.com


On Sun, Mar 31, 2019 at 3:08 PM Tobias McNulty 
wrote:

> On Sat, Mar 30, 2019 at 7:32 PM Tom Forbes  wrote:
>
>> I’m a stats nerd, and I think I’m not alone on this list in that respect,
>> would it be possible to share some more numbers after a week of usage? I
>> would be interested in the total bandwidth used/saved, the global
>> distribution of requests and the average requests per second. If I remember
>> correctly fastly has a fantastic live dashboard with all of this info.
>>
>
> For static, I think we'll end up using just under 300 GB a month, or about
> a quarter of the total bandwidth served by this particular server (which
> also handles most other djangoproject.com subdomains). I'll see if I can
> collect some slightly more interesting numbers after a week or two.
>
> I’m not entirely clear on the HTTP/2 issue, does Fastly not terminate
>> these and forward on http 1.1 requests? Could you elaborate a bit?
>>
>
> HTTP/2 supports connection coalescing
> <https://daniel.haxx.se/blog/2016/08/18/http2-connection-coalescing/>,
> where the browser (with varying degrees of aggressiveness, depending on the
> manufacturer) may reuse existing connections for different subdomains. In
> our case, Fastly originally provisioned a wildcard SSL cert ('*.
> djangoproject.com'), so *we think* that some versions of Firefox were
> reusing HTTP/2 connections originally established for
> static.djangoproject.com for requests to www.djangoproject.com, *even
> though* there was no overlap in IPs for the two domains. In the browser
> (courtesy of Mariusz) it looked like this:
>
> [image: Screenshot_20190320_113825.png]
> Clicking on the cert icon showed the wildcard cert from Fastly, not our
> Let's Encrypt cert, as well. In other words, it appeared Firefox was
> ignoring DNS for www.djangoproject.com and assumed that it could send
> those requests to static.djangoproject.com instead, simply because the
> server responded with an SSL certificate that matched
> www.djangoproject.com. I.e., it appeared to be *even more aggressive* than
> described under "The Firefox way" in the link above.
>
> I find this explanation entirely dissatisfying (if not altogether
> frightening), so part of me hopes I've got it wrong. :-\
>
> In any case, after requesting that Fastly de-provision the wildcard cert
> and include only the specific domains we needed, the issue went away. There
> is an HTTP status code (421) that can be used to tell the browser it's made
> such an error, so I believe we also could have solved this by setting up a
> catchall service in Fastly to return HTTP 421 for any requests received on
> subdomains we weren't expecting. But avoiding the spurious requests to
> begin with seemed like a better solution, and provisioning certs only for
> the domains we need is cleaner to begin with and seems to have fixed the
> problem.
>
> I was never able to reproduce this in Firefox myself, but I did see
> evidence of it occurring insofar as we *also* started getting a very
> small number of requests to the '*docs*.djangoproject.com' service in
> Fastly after changing the DNS for '*static*.djangoproject.com.' Of
> course, no one would have noticed these because the requests returned
> successfully, but they should not have been going through Fastly (until the
> DNS was changed for 'docs', of course). Mariusz may be able to add
> something about the when/how he saw this; I do think it was fairly
> intermittent. Anyways, I'm pretty sure this would have gone undiagnosed for
> weeks if not months if he had not noticed and alerted us to the issue
> (causing all sorts of frustration and confusion in the meantime), so thank
> you again, Mariusz!
>
> Cheers,
> Tobias
>

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

Re: translation.E005 / Should LANGUAGES_BIDI be a strict subset of LANGUAGES?

[Tobias McNulty]

Having thought about this a little more, I may have found in answer to my
own question. :-)

The reasoning would seem to be that, by overriding LANGUAGES but not
LANGUAGES_BIDI, you risk introducing an inconsistency between the language
code *format* in these two settings (a la LANGUAGE_CODE and the original
ticket that got this started). If that's correct, that seems fair to me
(and worth keeping this check), along with an update to the docs to clarify
this dependency and why it exists.

Tobias

On Tue, Apr 9, 2019, 8:06 AM Adam Johnson  wrote:

> Other ideas:
>
>- Bypass the check in the case that LANGAUGES_BIDI is the same as the
>one in global_settings - probably not the best idea, but would stop all
>projects having to set LANGUAGES_BIDI = [] to avoid the check
>- Change startproject so that LANGUAGES_BIDI is set up as the empty
>list - removes some "included batteries" but helps users make a more
>informed choice?
>
>
> On Tue, 9 Apr 2019 at 12:27, Adam Johnson  wrote:
>
>> Hi Matthias,
>>
>> I can see why this is annoying. At least the resolution is easy by
>> setting LANGUAGES_BIDI = []. I do agree that it should be in the release
>> notes, although it's quite hard to miss a new system check's output when
>> upgrading.
>>
>> I see it was only at the last review of the PR (
>> https://github.com/django/django/pull/11060 ) that the check in question
>> was upgraded from warning W005 to E005. I can see why a warning would make
>> sense, but at the same time a warning is still a message to the user and
>> resolved the same way, either by setting LANGUAGES_BIDI or adding it to
>> SILENCED_SYSTEM_CHECKS.
>>
>> I think I'm against removing the check, but pro anything that can make it
>> easier for users such as yourself - perhaps something as simple as a
>> suggestion in the error message to set LANGUAGES_BIDI = [] if you're not
>> using RTL languages?
>>
>> Thanks,
>>
>> Adam
>>
>> On Tue, 9 Apr 2019 at 11:22, Matthias Kestenholz  wrote:
>>
>>> Hello everyone,
>>>
>>> The resolution of https://code.djangoproject.com/ticket/30241 in
>>> https://github.com/django/django/commit/4400d8296d268f5a8523cd02ddc33b12219b2535
>>> introduced a new and in my opinion backwards incompatible requirement
>>> through the system checks framework.
>>>
>>> Previously*, overriding LANGUAGES to restrict the list of available
>>> languages on a Django site worked. Now it's also necessary to override
>>> LANGUAGES_BIDI because there is a new system check (translation.E005) which
>>> verifies that there are no language codes in LANGUAGES_BIDI not in
>>> LANGUAGES as well.
>>>
>>> It is my strong opinion that enforcing this does not provide any
>>> benefits and has the downside of forcing almost everyone who overrides
>>> LANGUAGES to now add a new setting to their project to override
>>> LANGUAGES_BIDI as well with unclear benefits.
>>>
>>> Strictness is a good thing, but since LANGUAGES_BIDI is only ever used
>>> for membership checking (and never iterated over) I don't see the problem
>>> in keeping the default language codes from django/conf/global_settings.py
>>> in there even though some of those languages may not be available on a
>>> given installation anyway.
>>>
>>> The report in https://code.djangoproject.com/ticket/30342 was closed as
>>> wontfix that's why I'm writing to the list. Also, since system checks
>>> generally aren't mentioned in the release notes users will not be informed
>>> ahead of time about this change when reading the release notes.
>>>
>>> Anyone has any opinions to offer on this?
>>>
>>> Thanks,
>>> Matthias
>>>
>>> * At least as long as I'm using Django, probably for 11 years or
>>> something.
>>>
>>> --
>>> 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/CANvPqgAy_HytsvmnOpPtrCP_969QhoncJaPUe%3D6pN-VYWMVcjA%40mail.gmail.com
>>> 
>>> .
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>>
>>
>> --
>> Adam
>>
>
>
> --
> Adam
>
> --
> 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/dja

Re: translation.E005 / Should LANGUAGES_BIDI be a strict subset of LANGUAGES?

[Tobias McNulty]

I am curious, what is the reasoning behind disallowing LANGUAGES_BIDI from
containing languages not in LANGUAGES in the first place?

If as Matthias says it is never iterated over, I'm unclear what problems
this might cause, though I agree the fix is simple enough...

At least perhaps the last paragraph in the description for the
LANGUAGES_BIDI setting (that is currently identical to a paragraph in the
LANGUAGES description, "Generally, the default value should suffice. Only
set this setting if you want to restrict language selection to a subset of
the Django-provided languages.") could be modified to clarify this
reasoning and its relationship to LANGUAGES? (What exactly this would say
is not obvious to me at the moment...)

Tobias


On Tue, Apr 9, 2019, 7:28 AM Adam Johnson  wrote:

> Hi Matthias,
>
> I can see why this is annoying. At least the resolution is easy by setting
> LANGUAGES_BIDI = []. I do agree that it should be in the release notes,
> although it's quite hard to miss a new system check's output when upgrading.
>
> I see it was only at the last review of the PR (
> https://github.com/django/django/pull/11060 ) that the check in question
> was upgraded from warning W005 to E005. I can see why a warning would make
> sense, but at the same time a warning is still a message to the user and
> resolved the same way, either by setting LANGUAGES_BIDI or adding it to
> SILENCED_SYSTEM_CHECKS.
>
> I think I'm against removing the check, but pro anything that can make it
> easier for users such as yourself - perhaps something as simple as a
> suggestion in the error message to set LANGUAGES_BIDI = [] if you're not
> using RTL languages?
>
> Thanks,
>
> Adam
>
> On Tue, 9 Apr 2019 at 11:22, Matthias Kestenholz  wrote:
>
>> Hello everyone,
>>
>> The resolution of https://code.djangoproject.com/ticket/30241 in
>> https://github.com/django/django/commit/4400d8296d268f5a8523cd02ddc33b12219b2535
>> introduced a new and in my opinion backwards incompatible requirement
>> through the system checks framework.
>>
>> Previously*, overriding LANGUAGES to restrict the list of available
>> languages on a Django site worked. Now it's also necessary to override
>> LANGUAGES_BIDI because there is a new system check (translation.E005) which
>> verifies that there are no language codes in LANGUAGES_BIDI not in
>> LANGUAGES as well.
>>
>> It is my strong opinion that enforcing this does not provide any benefits
>> and has the downside of forcing almost everyone who overrides LANGUAGES to
>> now add a new setting to their project to override LANGUAGES_BIDI as well
>> with unclear benefits.
>>
>> Strictness is a good thing, but since LANGUAGES_BIDI is only ever used
>> for membership checking (and never iterated over) I don't see the problem
>> in keeping the default language codes from django/conf/global_settings.py
>> in there even though some of those languages may not be available on a
>> given installation anyway.
>>
>> The report in https://code.djangoproject.com/ticket/30342 was closed as
>> wontfix that's why I'm writing to the list. Also, since system checks
>> generally aren't mentioned in the release notes users will not be informed
>> ahead of time about this change when reading the release notes.
>>
>> Anyone has any opinions to offer on this?
>>
>> Thanks,
>> Matthias
>>
>> * At least as long as I'm using Django, probably for 11 years or
>> something.
>>
>> --
>> 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/CANvPqgAy_HytsvmnOpPtrCP_969QhoncJaPUe%3D6pN-VYWMVcjA%40mail.gmail.com
>> 
>> .
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>
> --
> Adam
>
> --
> 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/CAMyDDM25B-y3D6iHuROz0rfDPzHp8qnHYhDw2inHNOawEDerGA%40mail.gmail.com
> 

Re: Use CDN for djangoproject.com

[Tobias McNulty]

On Sat, Mar 30, 2019 at 7:32 PM Tom Forbes  wrote:

> I’m a stats nerd, and I think I’m not alone on this list in that respect,
> would it be possible to share some more numbers after a week of usage? I
> would be interested in the total bandwidth used/saved, the global
> distribution of requests and the average requests per second. If I remember
> correctly fastly has a fantastic live dashboard with all of this info.
>

For static, I think we'll end up using just under 300 GB a month, or about
a quarter of the total bandwidth served by this particular server (which
also handles most other djangoproject.com subdomains). I'll see if I can
collect some slightly more interesting numbers after a week or two.

I’m not entirely clear on the HTTP/2 issue, does Fastly not terminate these
> and forward on http 1.1 requests? Could you elaborate a bit?
>

HTTP/2 supports connection coalescing
,
where the browser (with varying degrees of aggressiveness, depending on the
manufacturer) may reuse existing connections for different subdomains. In
our case, Fastly originally provisioned a wildcard SSL cert ('*.
djangoproject.com'), so *we think* that some versions of Firefox were
reusing HTTP/2 connections originally established for
static.djangoproject.com for requests to www.djangoproject.com, *even
though* there was no overlap in IPs for the two domains. In the browser
(courtesy of Mariusz) it looked like this:

[image: Screenshot_20190320_113825.png]
Clicking on the cert icon showed the wildcard cert from Fastly, not our
Let's Encrypt cert, as well. In other words, it appeared Firefox was
ignoring DNS for www.djangoproject.com and assumed that it could send those
requests to static.djangoproject.com instead, simply because the server
responded with an SSL certificate that matched www.djangoproject.com. I.e.,
it appeared to be *even more aggressive* than described under "The Firefox
way" in the link above.

I find this explanation entirely dissatisfying (if not altogether
frightening), so part of me hopes I've got it wrong. :-\

In any case, after requesting that Fastly de-provision the wildcard cert
and include only the specific domains we needed, the issue went away. There
is an HTTP status code (421) that can be used to tell the browser it's made
such an error, so I believe we also could have solved this by setting up a
catchall service in Fastly to return HTTP 421 for any requests received on
subdomains we weren't expecting. But avoiding the spurious requests to
begin with seemed like a better solution, and provisioning certs only for
the domains we need is cleaner to begin with and seems to have fixed the
problem.

I was never able to reproduce this in Firefox myself, but I did see
evidence of it occurring insofar as we *also* started getting a very small
number of requests to the '*docs*.djangoproject.com' service in Fastly
after changing the DNS for '*static*.djangoproject.com.' Of course, no one
would have noticed these because the requests returned successfully, but
they should not have been going through Fastly (until the DNS was changed
for 'docs', of course). Mariusz may be able to add something about the
when/how he saw this; I do think it was fairly intermittent. Anyways, I'm
pretty sure this would have gone undiagnosed for weeks if not months if he
had not noticed and alerted us to the issue (causing all sorts of
frustration and confusion in the meantime), so thank you again, Mariusz!

Cheers,
Tobias

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

Re: Proposal to re-open #27017 (updating only dirty fields in save())

[Tobias McNulty]

I want to qualify this by saying that personally I've always thought of
(and likely will continue to think of) model objects as a snapshot of
what's in the database, and use the more explicit queryset.update() when
that snapshot is NOT what I want to save back to the database. So I may be
somewhat biased against this idea to start with. :)

That said, as Simon mentioned, don't we already effectively support this?

>>> from django.db import connection
>>> from food.models import Food
>>> f = Food.objects.only('pk').first()
>>> f.name = 'foo'
>>> f.save()
>>> connection.queries
[{'sql': 'SELECT "food_food"."id" FROM "food_food" ORDER BY
"food_food"."food_code" ASC LIMIT 1', 'time': '0.003'}, {'sql': 'UPDATE
"food_food" SET "name" = \'foo\' WHERE "food_food"."id" = 5542', 'time':
'0.010'}]

(For the record, this model has many more fields.)

Of course, if you need other fields to calculate whatever needs to be saved
back to the DB, you should add them to .only(). But in any case it protects
you from silently losing data by forgetting to include them in
update_fields (at the risk of generating extra queries if you forget to
include them in .only(), but at least you can see those and optimize them
away).

Consider me relatively ambivalent about the idea...perhaps +0 on a Meta- or
save()-level implementation and -0 on a settings-based approach (given the
red flags already raised).

Cheers,


*Tobias McNulty*Chief Executive Officer

tob...@caktusgroup.com
www.caktusgroup.com


On Thu, Mar 14, 2019 at 11:20 AM charettes  wrote:

> +1 to what Adam said. Turning this feature on by default would be
> certainly cause a lot of bugs in application
> expecting a "coherent state" to be persisted on .save().
>
> That would effectively make most of the Form.clean(), Model.clean() and
> DRF serializer logic in charge of
> validating a field value based on another field value useless as another
> process could race to update the
> row to another state unless you've defined database level constraints as
> well.
>
> > ... performance *benefits* of executing smaller UPDATE statements that
> write fewer columns.
>
> FWIW the current .save() logic ignores deferred fields so it's currently
> possible to work around the
> rare cases where updating a large column causes a slow UPDATE query.
>
> > I'm not sure if a global setting is a good idea. Code in third-party
> apps would need to work with both configurations?
>
> Agreed, it feels like a Meta or .save() option would be more appropriate,
> we already have a select_on_save
> option for example which is even more specific than this use case.
>
> At this point I'm not convinced that it's something Django should
> implement internally as it is possible to implement
> an abstract model in charge of tracking "dirty" fields and overriding
> `.save` to make `update_fields` default to it
> as demonstrated by the few existing third-party solutions.
>
> Simon
>
> Le jeudi 14 mars 2019 09:49:59 UTC-4, Tim Graham a écrit :
>>
>> I'm not sure if a global setting is a good idea. Code in third-party apps
>> would need to work with both configurations?
>>
>> On Thursday, March 14, 2019 at 8:39:05 AM UTC-4, Daniel Tao wrote:
>>>
>>> I agree with this:
>>>
>>> > Therefore it seems like it would be a breaking change which is hard to
>>> communicate to users, a complicated situation.
>>>
>>> This is why I'm recommending that this behavior be opt-in via a Django
>>> setting such as SAVE_UPDATE_DIRTY_FIELDS_ONLY. Application developers
>>> would then need to make a determination for themselves whether or not to
>>> enable it.
>>>
>>> Adam is right to point out an edge case where this behavior could lead
>>> to subtle bugs. Not surprisingly, it's related to concurrency (which is
>>> where subtle bugs tend to live)! In response, I would point out that the
>>> whole point of this proposal is to address a *different* edge case,
>>> also related to concurrency, which I personally believe is more common,
>>> though it's admittedly hard to know without a lot of empirical data.
>>> (Actually it's also present in the scenario Adam describes, and he
>>> addresses this: "Sure there's a race condition and the results of either
>>> process 1 or 2 can be lost.")
>>>
>>> From the perspective of an application developer, if this func

Re: Support for unittest -k option

[Tobias McNulty]

Agreed it's probably better to make the switch now, and I'd be fine without
a replacement shorthand alternative for --keepdb.

Cheers,


*Tobias McNulty*Chief Executive Officer

tob...@caktusgroup.com
www.caktusgroup.com


On Mon, Mar 11, 2019 at 8:19 AM Carlton Gibson 
wrote:

> Thanks François,
>
> Just on this, my thought is that if we don't follow `unittest` in changing
> `-k` for this, we have a steady trickle of confusion forever-more.
> I'd rather avoid that.
>
> C.
>
> On Monday, 11 March 2019 13:14:01 UTC+1, François Freitag wrote:
>>
>> Hi Django Devs,
>>
>> https://code.djangoproject.com/ticket/30245 suggests supporting Python
>> unittest `-k` option, to selectively run tests matching a keyword.
>>
>> Currently, `-k` is the shorthand for `--keepdb` in Django.
>> A `--filter` flag was suggested to preserve backward compatibility.
>> Carlton suggested removing the `-k` option from `--keepdb` and reusing
>> it for unittest `-k`. That would follow unittest more closely, reduce
>> user confusion and ease maintenance.
>>
>> What do you think is best? Do you see other options?
>>
>> If re-taking the `-k` option for unittest `-k`, should a new shorthand
>> be introduced for `--keepdb`?
>>
>> Thanks for your time,
>> François
>>
> --
> 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/c54e52d2-012a-4852-9375-be37add55945%40googlegroups.com
> <https://groups.google.com/d/msgid/django-developers/c54e52d2-012a-4852-9375-be37add55945%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  (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/CAMGFDKS1GCE3U824FZxMnzJTdZrq_9uuT60jiVHv%2BM4JR1%3D5%3DA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Use CDN for djangoproject.com

[Tobias McNulty]

Hi all,

These changes have been deployed (though we're not yet using a CDN for the
primary domain, docs.djangoproject.com, so you shouldn't notice a change).

The alternate URL (https://django-docs.global.ssl.fastly.net/en/2.1/) will
now cache docs pages for up to a week, and the hourly docs rebuilds will
trigger a cache purge of (a) nothing if there have been no changes in the
last hour, (b) just the dev docs if that's all that's changed or (c) the
entire docs site if a release branch has changed. I've tested this a few
times and everything seems to be working as it should, but please let me
know if you see anything out of order.

Currently we're waiting on the DSF/Fastly contract to be executed. Once
that's done I think we'll be ready to move static.djangoproject.com and
docs.djangoproject.com to Fastly.

I did set up a CloudFront distribution for these domains as well, but given
Fastly will give us the bandwidth for free we're having a hard time
justifying using CloudFront instead. Of course, if anyone has a connection
to $2000+ a year or so in AWS credits for the foreseeable future, let me
know. :-)

Finally, in preparation for the switch, I set up a status page (
https://docs-status.djangoproject.com) that, at the time I wrote this
email, at least, shows the following average response times to the docs
site from around the world:

   - Mumbai: 1968 ms
   - Singapore: 1895 ms
   - Sydney: 2015 ms
   - Tokyo: 1490 ms
   - Canada (Central): 224 ms
   - Ireland: 705 ms
   - London: 525 ms
   - Sao Paulo: 911 ms
   - US East (N. Virginia): 149 ms
   - US West (Oregon): 721 ms

You can click on an individual region to see the variability over time. I'm
on the east coast in the US so I don't have a good way to confirm or deny
most of these. They are HTTPS checks, and I believe the numbers represent
the time to connect and retrieve the page content (for
https://docs.djangoproject.com/en/2.1/).

Cheers,


*Tobias McNulty*Chief Executive Officer

tob...@caktusgroup.com
www.caktusgroup.com


On Mon, Feb 25, 2019 at 10:56 AM Florian Apolloner 
wrote:

> Hi Tobias,
>
> I think a cache of something like a day will most certainly not hurt
> anyone. If the need arises we can still manually purge the cache as needed.
>
> Cheers,
> Florian
>
> On Sunday, February 24, 2019 at 1:00:50 AM UTC+1, Tobias McNulty wrote:
>>
>> Hi all,
>>
>> An implementation question has come up regarding cache lifetime (see this
>> PR <https://github.com/django/djangoproject.com/pull/870>). Right now,
>> the whole site (including docs) has the site-wide Django cache enabled
>> <https://github.com/django/djangoproject.com/blob/master/djangoproject/settings/prod.py#L43-L45>,
>> with a timeout of 5 minutes
>> <https://github.com/django/djangoproject.com/blob/master/djangoproject/settings/common.py#L27>.
>> A couple docs views (search_suggestions
>> <https://github.com/django/djangoproject.com/blob/master/docs/views.py#L248-L250>
>> and search_description
>> <https://github.com/django/djangoproject.com/blob/master/docs/views.py#L272-L274>)
>> views have longer timeouts set (to 1 hour and 1 week, respectively).
>>
>> Once released, the vast majority of Django docs won't change much, except
>> for the release notes section and any (likely minor) related updates to the
>> docs themselves. To get the most benefit out of a CDN, it would obviously
>> be desirable to set the timeout to something greater than 5 minutes.
>>
>> At the same time, there are moments when a quick update to the docs *is*
>> desired, and waiting an hour or more for any cached pages to expire may
>> cause significant confusion, for example, in conjunction with a security
>> release for which stubbed (non-final) release notes may have already been
>> pushed out and cached.
>>
>> I see two main options at this point (which could even be combined):
>>
>> 1) Invalidate the whole cache (or at least some key release notes URLs)
>> any time there's a docs build that has changes. It would be pretty easy to
>> piggyback off of the existing business logic for avoiding a rebuild
>> <https://github.com/django/djangoproject.com/blob/master/docs/management/commands/update_docs.py#L86-L93>
>> if the git checkout hasn't changed (in the update_docs management command).
>> 2) Pick subsections of the docs (e.g., for anything matching
>> '///releases/*' and perhaps the development docs) that would
>> keep a shorter cache timeout of 5-10 minutes. All URLs not specifically
>> requiring this special treatment would get a longer timeout, perhaps
>> somewhere between 1 and 24 hours.
>>
>> So, some questions for the list:
>

Re: GSoC 2019 Update

[Tobias McNulty]

On Thu, Mar 7, 2019 at 6:22 AM Carlton Gibson 
wrote:

> For the *ORM*, I think the cross-DB JSONField would be a great project.
> Florian worried it was too small in scope, but if it existed by the end of
> the summer, I would call that a success.
>
+1 -- and I'd rather a project be too small than too large (and go
unfinished). If it goes that quickly I'm sure we/they can always find more
to do, as your open tickets graph suggests. :) Perhaps a good proposal
would be to start with the cross-DB JSONField and then move to ORM tickets
X, Y, Z *if* the first is merged in time?

Cheers,



*Tobias McNulty*Chief Executive Officer

tob...@caktusgroup.com
www.caktusgroup.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 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/CAMGFDKR5K1xEGssk99bGpqWicvjnYidQDpeb%3Dt%3D4aWoA4jJknA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: De-assigning "Easy pickings" tickets

[Tobias McNulty]

Also generally in favor. Is there a bot for such a thing? It would be nice
to get a reminder a week or two *before* the unassign happens, either to
prompt an update OR an early self-unassign (if the person is not in fact
working on the ticket anymore and just didn't remember it was still
assigned to them).

Tobias

On Fri, Mar 8, 2019, 3:22 PM Markus Holtermann 
wrote:

> Hi Carlton,
>
> my only question would be why you picked 2 months over 1 or 3. Generally
> in favor. I think de-assigning somebody after $time of inactivity on a
> ticket is fair, regardless of the complexity of the ticket.
>
> /Markus
>
> On Fri, Mar 8, 2019, at 8:30 PM, Carlton Gibson wrote:
> > Hi all.
> >
> > We don't have many Easy Pickings tickets, they're all assigned, and get
> > assigned quickly, but don't often get closed.
> >
> > Looking at the current batch...
> >
> >
> https://code.djangoproject.com/query?status=assigned&status=new&easy=1&col=id&col=status&col=changetime&desc=1&order=changetime
> >
> > ... I'd like to suggest that after 2 months we de-assign them, so they
> > can get picked up by people looking, who are likely not
> > willing/able/whatever to take over an assigned ticket themselves.
> >
> > Any thoughts/objections to that as a policy?
> >
> > Thanks.
> >
> > Kind Regards,
> >
> > 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/7bb67aa2-c898-4b97-a43a-eba38c00e00e%40googlegroups.com
> <
> https://groups.google.com/d/msgid/django-developers/7bb67aa2-c898-4b97-a43a-eba38c00e00e%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  (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/8c599482-9c8e-4335-a5ff-7ffac96e94f8%40www.fastmail.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/CAMGFDKQbnRa_gaNjEdGyHyjXpAe0%2BA1qFo_JNfWpjARh6X%2BPrQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Use CDN for djangoproject.com

[Tobias McNulty]

Tom,

That's great! Thanks for the feedback.

I've updated the PR <https://github.com/django/djangoproject.com/pull/870>
with something along the lines of what you suggested (along with the
corresponding configuration in Fastly).

Take a look and let me know what you think.

Cheers,
Tobias



On Sun, Feb 24, 2019 at 10:40 AM Tom Forbes  wrote:

> Awesome work! For my location (Lisbon, Portugal) it takes about 130ms to
> retrieve the HTML for a docs page (
> https://django-docs.global.ssl.fastly.net/en/2.1/intro/reusable-apps/ to
> be specific). The same page on docs.djangoproject.com responds in
> 800–900ms.
>
>
>
>
> On 24 February 2019 at 14:35:55, Tobias McNulty (tob...@caktusgroup.com)
> wrote:
>
> Hi Tom,
>
> Thanks for your message. I think we'll end up with Fastly since it would
> be free, but I'm waiting to see their sponsorship contract. CloudFront
> would work too but I don't know of any such open source sponsorship options
> with AWS.
>
> I will say wildcard purging looks a bit simpler in CloudFront, but your
> idea purging the whole cache only for non-dev builds could work (provided
> we have a lower cache timeout or a single wildcard purge condition set up
> for the dev builds, I guess).
>
> Feel free to test and post any feedback about Fastly prior to the
> potential transition here:
> https://django-docs.global.ssl.fastly.net/en/2.1/ (this is set up on a
> free dev account, so no custom SSL)
>
> For the sake of comparison I'm working on getting a distribution set up
> for CloudFront too, but it won't be so simple to test (without a DNS or
> server configuration change) since I don't think CloudFront supports
> passing a custom Host header to the origin like Fastly does (i.e., you'll
> probably need to edit /etc/hosts).
>
> Cheers,
> Tobias
>
>
> On Sat, Feb 23, 2019, 7:15 PM Tom Forbes  wrote:
>
>> Sorry, I did not completely grok your message. I would be in favour of
>> just invalidating the whole cache if needed, it seems the simplest
>> solution. Invalidating most of the cache on every non-dev deploy would also
>> be OK I think.
>>
>> On Sun, 24 Feb 2019, 00:10 Tom Forbes,  wrote:
>>
>>> Which CDN are we going to use? Fastly has awesome sub 100ms global
>>> invalidation which we can trigger on every deploy, and cloudflare has
>>> something similar.
>>>
>>> On Sun, 24 Feb 2019, 00:00 Tobias McNulty, 
>>> wrote:
>>>
>>>> Hi all,
>>>>
>>>> An implementation question has come up regarding cache lifetime (see this
>>>> PR <https://github.com/django/djangoproject.com/pull/870>). Right now,
>>>> the whole site (including docs) has the site-wide Django cache enabled
>>>> <https://github.com/django/djangoproject.com/blob/master/djangoproject/settings/prod.py#L43-L45>,
>>>> with a timeout of 5 minutes
>>>> <https://github.com/django/djangoproject.com/blob/master/djangoproject/settings/common.py#L27>.
>>>> A couple docs views (search_suggestions
>>>> <https://github.com/django/djangoproject.com/blob/master/docs/views.py#L248-L250>
>>>> and search_description
>>>> <https://github.com/django/djangoproject.com/blob/master/docs/views.py#L272-L274>)
>>>> views have longer timeouts set (to 1 hour and 1 week, respectively).
>>>>
>>>> Once released, the vast majority of Django docs won't change much,
>>>> except for the release notes section and any (likely minor) related updates
>>>> to the docs themselves. To get the most benefit out of a CDN, it would
>>>> obviously be desirable to set the timeout to something greater than 5
>>>> minutes.
>>>>
>>>> At the same time, there are moments when a quick update to the docs
>>>> *is* desired, and waiting an hour or more for any cached pages to
>>>> expire may cause significant confusion, for example, in conjunction with a
>>>> security release for which stubbed (non-final) release notes may have
>>>> already been pushed out and cached.
>>>>
>>>> I see two main options at this point (which could even be combined):
>>>>
>>>> 1) Invalidate the whole cache (or at least some key release notes URLs)
>>>> any time there's a docs build that has changes. It would be pretty easy to
>>>> piggyback off of the existing business logic for avoiding a rebuild
>>>> <https://github.com/django/djangoproject.com/blob/master/docs/management/commands/update_docs.py#L86-L93>
>>>&g

Re: Use CDN for djangoproject.com

[Tobias McNulty]

Hi Tom,

Thanks for your message. I think we'll end up with Fastly since it would be
free, but I'm waiting to see their sponsorship contract. CloudFront would
work too but I don't know of any such open source sponsorship options with
AWS.

I will say wildcard purging looks a bit simpler in CloudFront, but your
idea purging the whole cache only for non-dev builds could work (provided
we have a lower cache timeout or a single wildcard purge condition set up
for the dev builds, I guess).

Feel free to test and post any feedback about Fastly prior to the potential
transition here: https://django-docs.global.ssl.fastly.net/en/2.1/ (this is
set up on a free dev account, so no custom SSL)

For the sake of comparison I'm working on getting a distribution set up for
CloudFront too, but it won't be so simple to test (without a DNS or server
configuration change) since I don't think CloudFront supports passing a
custom Host header to the origin like Fastly does (i.e., you'll probably
need to edit /etc/hosts).

Cheers,
Tobias


On Sat, Feb 23, 2019, 7:15 PM Tom Forbes  wrote:

> Sorry, I did not completely grok your message. I would be in favour of
> just invalidating the whole cache if needed, it seems the simplest
> solution. Invalidating most of the cache on every non-dev deploy would also
> be OK I think.
>
> On Sun, 24 Feb 2019, 00:10 Tom Forbes,  wrote:
>
>> Which CDN are we going to use? Fastly has awesome sub 100ms global
>> invalidation which we can trigger on every deploy, and cloudflare has
>> something similar.
>>
>> On Sun, 24 Feb 2019, 00:00 Tobias McNulty, 
>> wrote:
>>
>>> Hi all,
>>>
>>> An implementation question has come up regarding cache lifetime (see this
>>> PR <https://github.com/django/djangoproject.com/pull/870>). Right now,
>>> the whole site (including docs) has the site-wide Django cache enabled
>>> <https://github.com/django/djangoproject.com/blob/master/djangoproject/settings/prod.py#L43-L45>,
>>> with a timeout of 5 minutes
>>> <https://github.com/django/djangoproject.com/blob/master/djangoproject/settings/common.py#L27>.
>>> A couple docs views (search_suggestions
>>> <https://github.com/django/djangoproject.com/blob/master/docs/views.py#L248-L250>
>>> and search_description
>>> <https://github.com/django/djangoproject.com/blob/master/docs/views.py#L272-L274>)
>>> views have longer timeouts set (to 1 hour and 1 week, respectively).
>>>
>>> Once released, the vast majority of Django docs won't change much,
>>> except for the release notes section and any (likely minor) related updates
>>> to the docs themselves. To get the most benefit out of a CDN, it would
>>> obviously be desirable to set the timeout to something greater than 5
>>> minutes.
>>>
>>> At the same time, there are moments when a quick update to the docs *is*
>>> desired, and waiting an hour or more for any cached pages to expire may
>>> cause significant confusion, for example, in conjunction with a security
>>> release for which stubbed (non-final) release notes may have already been
>>> pushed out and cached.
>>>
>>> I see two main options at this point (which could even be combined):
>>>
>>> 1) Invalidate the whole cache (or at least some key release notes URLs)
>>> any time there's a docs build that has changes. It would be pretty easy to
>>> piggyback off of the existing business logic for avoiding a rebuild
>>> <https://github.com/django/djangoproject.com/blob/master/docs/management/commands/update_docs.py#L86-L93>
>>> if the git checkout hasn't changed (in the update_docs management command).
>>> 2) Pick subsections of the docs (e.g., for anything matching
>>> '///releases/*' and perhaps the development docs) that would
>>> keep a shorter cache timeout of 5-10 minutes. All URLs not specifically
>>> requiring this special treatment would get a longer timeout, perhaps
>>> somewhere between 1 and 24 hours.
>>>
>>> So, some questions for the list:
>>>
>>> * Are there sections of the docs besides '///releases/'
>>> and '//dev/' that might update frequently and merit some combination
>>> of invalidation and/or a shorter cache time? And what's a good cache
>>> timeout for such pages?
>>> * How long are we comfortable waiting for *other* (not frequently
>>> updated) pages to timeout, in the event they do change?
>>>
>>> Tobias
>>>
>>> On Fri, Feb 15, 2019 at 7:13 AM Tobias McNulty 
>>

Re: Use CDN for djangoproject.com

[Tobias McNulty]

Hi all,

An implementation question has come up regarding cache lifetime (see this PR
<https://github.com/django/djangoproject.com/pull/870>). Right now, the
whole site (including docs) has the site-wide Django cache enabled
<https://github.com/django/djangoproject.com/blob/master/djangoproject/settings/prod.py#L43-L45>,
with a timeout of 5 minutes
<https://github.com/django/djangoproject.com/blob/master/djangoproject/settings/common.py#L27>.
A couple docs views (search_suggestions
<https://github.com/django/djangoproject.com/blob/master/docs/views.py#L248-L250>
and search_description
<https://github.com/django/djangoproject.com/blob/master/docs/views.py#L272-L274>)
views have longer timeouts set (to 1 hour and 1 week, respectively).

Once released, the vast majority of Django docs won't change much, except
for the release notes section and any (likely minor) related updates to the
docs themselves. To get the most benefit out of a CDN, it would obviously
be desirable to set the timeout to something greater than 5 minutes.

At the same time, there are moments when a quick update to the docs *is*
desired, and waiting an hour or more for any cached pages to expire may
cause significant confusion, for example, in conjunction with a security
release for which stubbed (non-final) release notes may have already been
pushed out and cached.

I see two main options at this point (which could even be combined):

1) Invalidate the whole cache (or at least some key release notes URLs) any
time there's a docs build that has changes. It would be pretty easy to
piggyback off of the existing business logic for avoiding a rebuild
<https://github.com/django/djangoproject.com/blob/master/docs/management/commands/update_docs.py#L86-L93>
if the git checkout hasn't changed (in the update_docs management command).
2) Pick subsections of the docs (e.g., for anything matching
'///releases/*' and perhaps the development docs) that would
keep a shorter cache timeout of 5-10 minutes. All URLs not specifically
requiring this special treatment would get a longer timeout, perhaps
somewhere between 1 and 24 hours.

So, some questions for the list:

* Are there sections of the docs besides '///releases/' and
'//dev/' that might update frequently and merit some combination of
invalidation and/or a shorter cache time? And what's a good cache timeout
for such pages?
* How long are we comfortable waiting for *other* (not frequently updated)
pages to timeout, in the event they do change?

Tobias

On Fri, Feb 15, 2019 at 7:13 AM Tobias McNulty 
wrote:

> Thanks for sharing the results.
>
> I did manage to get a domain set up with working SSL, in case you want to
> use it: https://django-docs.global.ssl.fastly.net/en/2.1/
>
> Tobias
>
> On Thu, Feb 14, 2019, 11:49 PM Cheng C 
>> Thanks for the test site, Tobias.
>>
>> Tested from Melbourne, Australia:
>>
>> https://docs.djangoproject.com/en/2.1/
>> Average Ping: 268ms
>>  Browser: 22 requests, 238KB transferred, Finish: 2.72s,
>> DOMContentLoaded: 1.37s, Load: 1.68s
>>
>> https://docs.djangoproject.com.global.prod.fastly.net/en/2.1/
>> Average Ping: 28ms
>>  Browser: 22 requests, 240KB transferred, Finish: 947ms,
>> DOMContentLoaded: 627ms, Load: 910ms
>>
>> Tested on Chrome with "Disable cache" checked, and no render issue was
>> found.
>>
>> On Friday, February 15, 2019 at 2:09:09 PM UTC+11, Tobias McNulty wrote:
>>>
>>> Adam, is there another provider you would recommend instead, that does
>>> not require changing DNS providers? FWIW, python.org does in fact use
>>> Fastly:
>>>
>>> $ host www.python.org
>>> www.python.org is an alias for dualstack.python.map.fastly.net.
>>> dualstack.python.map.fastly.net has address 151.101.248.223
>>> dualstack.python.map.fastly.net has IPv6 address 2a04:4e42:2f::223
>>>
>>> Fastly did write back to say they're happy to help, though there's a
>>> contract which I guess the DSF would need to review and sign, if it's
>>> acceptable.
>>>
>>> In the meantime, feel free to give this a try and let me know if you see
>>> any issues:
>>> https://docs.djangoproject.com.global.prod.fastly.net/en/2.1/ (Not for
>>> permanent use, obviously; you'll get a cert warning, and some pages will
>>> redirect you back to https://docs.djangoproject.com.)
>>>
>>> To keep this thread from getting too noisy, you can find me (tobias1) in
>>> #django-dev on FreeNode.
>>>
>>> Cheers,
>>> Tobias
>>>
>>> On Thu, Feb 14, 2019 at 8:26 AM Adam Johnson  wrote:
>>>
>>>> I have not had g

Re: Use CDN for djangoproject.com

[Tobias McNulty]

Thanks for sharing the results.

I did manage to get a domain set up with working SSL, in case you want to
use it: https://django-docs.global.ssl.fastly.net/en/2.1/

Tobias

On Thu, Feb 14, 2019, 11:49 PM Cheng C  Thanks for the test site, Tobias.
>
> Tested from Melbourne, Australia:
>
> https://docs.djangoproject.com/en/2.1/
> Average Ping: 268ms
>  Browser: 22 requests, 238KB transferred, Finish: 2.72s, DOMContentLoaded:
> 1.37s, Load: 1.68s
>
> https://docs.djangoproject.com.global.prod.fastly.net/en/2.1/
> Average Ping: 28ms
>  Browser: 22 requests, 240KB transferred, Finish: 947ms, DOMContentLoaded:
> 627ms, Load: 910ms
>
> Tested on Chrome with "Disable cache" checked, and no render issue was
> found.
>
> On Friday, February 15, 2019 at 2:09:09 PM UTC+11, Tobias McNulty wrote:
>>
>> Adam, is there another provider you would recommend instead, that does
>> not require changing DNS providers? FWIW, python.org does in fact use
>> Fastly:
>>
>> $ host www.python.org
>> www.python.org is an alias for dualstack.python.map.fastly.net.
>> dualstack.python.map.fastly.net has address 151.101.248.223
>> dualstack.python.map.fastly.net has IPv6 address 2a04:4e42:2f::223
>>
>> Fastly did write back to say they're happy to help, though there's a
>> contract which I guess the DSF would need to review and sign, if it's
>> acceptable.
>>
>> In the meantime, feel free to give this a try and let me know if you see
>> any issues: https://docs.djangoproject.com.global.prod.fastly.net/en/2.1/
>> (Not for permanent use, obviously; you'll get a cert warning, and some
>> pages will redirect you back to https://docs.djangoproject.com.)
>>
>> To keep this thread from getting too noisy, you can find me (tobias1) in
>> #django-dev on FreeNode.
>>
>> Cheers,
>> Tobias
>>
>> On Thu, Feb 14, 2019 at 8:26 AM Adam Johnson  wrote:
>>
>>> I have not had great experience with Fastly in the past and would avoid
>>> them. They run an old fork of Varnish which is not fun to configure.
>>>
>>> On Thu, 14 Feb 2019 at 11:16, Josh Smeaton  wrote:
>>>
>>>> Cloudflare have many SSL options, including fully encrypted and
>>>> authenticated comms all the way through (terminate and reconnect).
>>>> Typically done by having a “hidden” origin domain that also hosts a
>>>> certificate. I’m unsure if it’s possible to have both origin and front
>>>> hosting the same name so that DNS alone can decide to hit cdn or origin.
>>>>
>>>> Anyway, it seems weird to me to dismiss a CDN offhand “because
>>>> security”. Especially considering the size of the providers and the
>>>> expertise their teams have.
>>>>
>>>> Cloudflare (fastly, cloudfront, whatever) aren’t some “random TLS”
>>>> providers. I would probably go as far to say that putting a CDN in front of
>>>> both the docs and the release packages would likely be a net improvement in
>>>> security for users.
>>>>
>>>> On Thu, 14 Feb 2019 at 21:58, Tom Forbes  wrote:
>>>>
>>>>> That makes sense, but in this case we are only talking about
>>>>> potentially yielding control of the docs subdomain which is not used to
>>>>> serve sensitive build artefacts?
>>>>>
>>>>> Another option is fastly.com, who support other large open source
>>>>> projects for free. They essentially give you geographically distributed
>>>>> HAProxy instances and you have a lot more control over them. I believe
>>>>> several large Linux distributions use them to serve cached apt packages.
>>>>>
>>>>> Regarding TLS termination, unfortunately any CDN we use will likely
>>>>> need to do this for the whole domain to get any benefit. The Django docs
>>>>> are text/html heavy with very few, if any, images. So the real speed
>>>>> benefit will have to come from serving that, which requires TLS 
>>>>> termination
>>>>> (and therefore interception) at their end.
>>>>>
>>>>> On Thu, 14 Feb 2019, 06:32 Markus Holtermann, <
>>>>> in...@markusholtermann.eu> wrote:
>>>>>
>>>>>> Hi all
>>>>>>
>>>>>> to elaborate on what Tobias said: we deliberately have the
>>>>>> infrastructure spread across multiple service providers: DNS registry,
>>>>>> nameservers, hosting, TLS certificate authority, … N

Re: Use CDN for djangoproject.com

[Tobias McNulty]

Adam, is there another provider you would recommend instead, that does not
require changing DNS providers? FWIW, python.org does in fact use Fastly:

$ host www.python.org
www.python.org is an alias for dualstack.python.map.fastly.net.
dualstack.python.map.fastly.net has address 151.101.248.223
dualstack.python.map.fastly.net has IPv6 address 2a04:4e42:2f::223

Fastly did write back to say they're happy to help, though there's a
contract which I guess the DSF would need to review and sign, if it's
acceptable.

In the meantime, feel free to give this a try and let me know if you see
any issues: https://docs.djangoproject.com.global.prod.fastly.net/en/2.1/
(Not for permanent use, obviously; you'll get a cert warning, and some
pages will redirect you back to https://docs.djangoproject.com.)

To keep this thread from getting too noisy, you can find me (tobias1) in
#django-dev on FreeNode.

Cheers,
Tobias

On Thu, Feb 14, 2019 at 8:26 AM Adam Johnson  wrote:

> I have not had great experience with Fastly in the past and would avoid
> them. They run an old fork of Varnish which is not fun to configure.
>
> On Thu, 14 Feb 2019 at 11:16, Josh Smeaton  wrote:
>
>> Cloudflare have many SSL options, including fully encrypted and
>> authenticated comms all the way through (terminate and reconnect).
>> Typically done by having a “hidden” origin domain that also hosts a
>> certificate. I’m unsure if it’s possible to have both origin and front
>> hosting the same name so that DNS alone can decide to hit cdn or origin.
>>
>> Anyway, it seems weird to me to dismiss a CDN offhand “because security”.
>> Especially considering the size of the providers and the expertise their
>> teams have.
>>
>> Cloudflare (fastly, cloudfront, whatever) aren’t some “random TLS”
>> providers. I would probably go as far to say that putting a CDN in front of
>> both the docs and the release packages would likely be a net improvement in
>> security for users.
>>
>> On Thu, 14 Feb 2019 at 21:58, Tom Forbes  wrote:
>>
>>> That makes sense, but in this case we are only talking about potentially
>>> yielding control of the docs subdomain which is not used to serve sensitive
>>> build artefacts?
>>>
>>> Another option is fastly.com, who support other large open source
>>> projects for free. They essentially give you geographically distributed
>>> HAProxy instances and you have a lot more control over them. I believe
>>> several large Linux distributions use them to serve cached apt packages.
>>>
>>> Regarding TLS termination, unfortunately any CDN we use will likely need
>>> to do this for the whole domain to get any benefit. The Django docs are
>>> text/html heavy with very few, if any, images. So the real speed benefit
>>> will have to come from serving that, which requires TLS termination (and
>>> therefore interception) at their end.
>>>
>>> On Thu, 14 Feb 2019, 06:32 Markus Holtermann, 
>>> wrote:
>>>
>>>> Hi all
>>>>
>>>> to elaborate on what Tobias said: we deliberately have the
>>>> infrastructure spread across multiple service providers: DNS registry,
>>>> nameservers, hosting, TLS certificate authority, … None of them have access
>>>> to everything. The reason is that we offer the download of the release
>>>> artifacts from the djangoproject.com website. And we would like to
>>>> ensure that the TLS termination happens by us and not some random service
>>>> provider. After all, Django is used by enterprises that do have some
>>>> restrictions on where you're allowed to download software from.
>>>>
>>>> By handing over DNS to some CDN provider, we loose the ability to
>>>> ensure that happens.
>>>>
>>>> That said, if there's a CDN that works as a reverse proxy and doesn't
>>>> require us to hand over control of DNS, I guess we could be interested in
>>>> moving the docs behind that.
>>>>
>>>> /Markus
>>>>
>>>> On Thu, Feb 14, 2019, at 2:22 AM, Tobias McNulty wrote:
>>>> > For me it's the trust factor (allowing someone else to decrypt and
>>>> > re-encrypt all our data). This may be less of an issue for the docs
>>>> > site, *if* we don't have to assign DNS authority for the whole domain
>>>> > to the CDN provider.
>>>> >
>>>> > Tobias
>>>> >
>>>> >
>>>> > On Wed, Feb 13, 2019, 7:47 PM Kye Russell >>> > > I’ve been hearing that 

Re: Use CDN for djangoproject.com

[Tobias McNulty]

Fastly could be a good fit. I've reached out to see if they'd be willing to
provide a free account. If anyone on this list works at Fastly or knows
someone who does, feel free to email/introduce me off list, too.

Tobias

On Thu, Feb 14, 2019, 5:58 AM Tom Forbes  That makes sense, but in this case we are only talking about potentially
> yielding control of the docs subdomain which is not used to serve sensitive
> build artefacts?
>
> Another option is fastly.com, who support other large open source
> projects for free. They essentially give you geographically distributed
> HAProxy instances and you have a lot more control over them. I believe
> several large Linux distributions use them to serve cached apt packages.
>
> Regarding TLS termination, unfortunately any CDN we use will likely need
> to do this for the whole domain to get any benefit. The Django docs are
> text/html heavy with very few, if any, images. So the real speed benefit
> will have to come from serving that, which requires TLS termination (and
> therefore interception) at their end.
>
> On Thu, 14 Feb 2019, 06:32 Markus Holtermann, 
> wrote:
>
>> Hi all
>>
>> to elaborate on what Tobias said: we deliberately have the infrastructure
>> spread across multiple service providers: DNS registry, nameservers,
>> hosting, TLS certificate authority, … None of them have access to
>> everything. The reason is that we offer the download of the release
>> artifacts from the djangoproject.com website. And we would like to
>> ensure that the TLS termination happens by us and not some random service
>> provider. After all, Django is used by enterprises that do have some
>> restrictions on where you're allowed to download software from.
>>
>> By handing over DNS to some CDN provider, we loose the ability to ensure
>> that happens.
>>
>> That said, if there's a CDN that works as a reverse proxy and doesn't
>> require us to hand over control of DNS, I guess we could be interested in
>> moving the docs behind that.
>>
>> /Markus
>>
>> On Thu, Feb 14, 2019, at 2:22 AM, Tobias McNulty wrote:
>> > For me it's the trust factor (allowing someone else to decrypt and
>> > re-encrypt all our data). This may be less of an issue for the docs
>> > site, *if* we don't have to assign DNS authority for the whole domain
>> > to the CDN provider.
>> >
>> > Tobias
>> >
>> >
>> > On Wed, Feb 13, 2019, 7:47 PM Kye Russell > > > I’ve been hearing that there are other CDN providers that offer a
>> very comparable service for a fraction of the cost of CloudFront.
>> > >
>> > > Anyways, at this stage let’s not get bogged down on provider
>> decisions. I’m curious if anyone has any general objections to a CDN of any
>> kind.
>> > >
>> > > It shouldn’t be that big a deal to automatically invalidate when the
>> docs are updated. But I’m sure there’s something I’m missing.
>> > >
>> > > On Thu, 14 Feb 2019 at 8:36 am, Cristiano Coelho <
>> cristianocc...@gmail.com> wrote:
>> > >> Consider AWS's cloudfront then :)
>> > >>
>> > >> El martes, 12 de febrero de 2019, 2:34:09 (UTC-5), Florian Apolloner
>> escribió:
>> > >>> Especially cloudflare is a service we do not want to use. as for
>> the docs only, does the mirror on rtd work better for you? They are
>> probably behind a CDN.
>> > >>>
>> > >>> Cheers,
>> > >>> Florian
>> > >>>
>> > >>> On Tuesday, February 12, 2019 at 6:43:41 AM UTC+1, Cheng C wrote:
>> > >>>> Hi,
>> > >>>>
>> > >>>> Is it possible to utilize a CDN service for djangoproject.com, or
>> at least on docs.djangoproject.com? The site is actually quite fast for
>> me but I think there is still room for improvement. Cloudflare sponsored
>> dozens of open source projects <
>> https://developers.cloudflare.com/sponsorships/>, probably they can
>> provide free service for django as well.
>> > >>>>
>> > >>>> Tested from Melbourne, Australia:
>> > >>>>
>> > >>>> https://www.djangoproject.com/
>> > >>>>  Average Ping: 245ms
>> > >>>>  Browser: 21 requests, 211KB transferred, Finish: 2.52s,
>> DOMContentLoaded: 1.16s, Load: 1.48s
>> > >>>>
>> > >>>> https://git-scm.com/
>> > >>>>  Average Ping: 5ms
>> > >

Re: Use CDN for djangoproject.com

[Tobias McNulty]

For me it's the trust factor (allowing someone else to decrypt and
re-encrypt all our data). This may be less of an issue for the docs site,
*if* we don't have to assign DNS authority for the whole domain to the CDN
provider.

Tobias


On Wed, Feb 13, 2019, 7:47 PM Kye Russell  I’ve been hearing that there are other CDN providers that offer a very
> comparable service for a fraction of the cost of CloudFront.
>
> Anyways, at this stage let’s not get bogged down on provider decisions.
> I’m curious if anyone has any general objections to a CDN of any kind.
>
> It shouldn’t be that big a deal to automatically invalidate when the docs
> are updated. But I’m sure there’s something I’m missing.
>
> On Thu, 14 Feb 2019 at 8:36 am, Cristiano Coelho 
> wrote:
>
>> Consider AWS's cloudfront then :)
>>
>> El martes, 12 de febrero de 2019, 2:34:09 (UTC-5), Florian Apolloner
>> escribió:
>>>
>>> Especially cloudflare is a service we do not want to use. as for the
>>> docs only, does the mirror on rtd work better for you? They are probably
>>> behind a CDN.
>>>
>>> Cheers,
>>> Florian
>>>
>>> On Tuesday, February 12, 2019 at 6:43:41 AM UTC+1, Cheng C wrote:

 Hi,

 Is it possible to utilize a CDN service for djangoproject.com, or at
 least on docs.djangoproject.com? The site is actually quite fast for
 me but I think there is still room for improvement. Cloudflare
 sponsored dozens of open source projects
 , probably they can
 provide free service for django as well.

 Tested from Melbourne, Australia:

 https://www.djangoproject.com/
  Average Ping: 245ms
  Browser: 21 requests, 211KB transferred, Finish: 2.52s,
 DOMContentLoaded: 1.16s, Load: 1.48s

 https://git-scm.com/
  Average Ping: 5ms
  Browser: 42 requests, 351KB transferred, Finish: 717ms,
 DOMContentLoaded: 564ms, Load: 699ms

 Tested on Chrome with "Disable cache" checked (but not the first time
 visit, so DNS query time might not be included).

 Best regards and thanks for all your great work.

>>> --
>> 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/548db807-647f-4d0b-99c2-f9f229f7175e%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/CANK-yknQ1Auf6CFD-%2B94qoATQ2K%2By0poLw%3DaxyJYjO3PaHOQWA%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/msgid/django-developers/CAMGFDKTAVv_3HJCTHqd-vSOFt9-WUvUDEGR8sYuawyVT7MAotQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: TestCase.setUpTestData in-memory data isolation.

[Tobias McNulty]

On Fri, Nov 30, 2018, 1:03 PM Adam Johnson  Tobias - using database updates isn't always viable. Also the system under
> test might need to take in the model instance, mutate it and execute its
> own save(), and then there's no way of rolling that back if the object
> wasn't deepcopy'd
>

Fair enough, but for those cases, one could just as easily deepcopy the
object in the test itself. Again, it's more explicit, gives the developer
control over exactly what they want to happen, and makes failures more
obvious.

I suppose if the API allowed one to mix and match approaches for different
tests and model objects (like Simon's testdata app does right now), that
would work, too.

Tobias

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

Re: TestCase.setUpTestData in-memory data isolation.

[Tobias McNulty]

Hi Simon,

Intriguing proposal! Thanks for bringing it up. This is certainly something
I've struggled with on older projects we've continued to maintain.

My first impression (and it may be only that) is that this seems a big
magical and potentially confusing, especially in the event the copy
operation fails. I would want some way to disable the behavior, or even
have "disabled" as the default, at least for a couple releases (e.g., by
keeping it as a decorator the way you have it now). Alternatively, is there
a reason this couldn't continue to live as an external package?

I'm also not sure I understand the argument about how the current
implementation doesn't help reduce round trips to the database. Is this
just a case of the docs offering a less-than-optimal recommendation? When
tests do need to modify a record in the database that was created in
setUpTestData(), it's easy enough to replace self.obj.foo = bar;
self.obj.save() with Model.objects.filter(pk=self.obj.pk).update(foo=bar),
which will avoid modifying the Python object and be *at least* as efficient
as the original code, without the need for any additional overhead. I'll
admit tracking down the offending code can be a pain, but it can be done.

Could we, for example, include something along these lines as the preferred
approach in the docs
,
and/or even find a way to raise an error or warning when a test does modify
an object that it shouldn't?

Tobias

On Wed, Nov 28, 2018 at 11:42 PM charettes  wrote:

> Hey Josh, glad the package can help in the mean time!
>
> > Is there anyway to determine the pickle-ability of something without
> just trying to pickle it? I wouldn't be keen on that overhead.
>
> Not that I'm aware off but unfortunately. There really shouldn't be much
> overhead though because the deepcopy is only performed on instance
> attribute access. That means that tests that are only creating test data
> without accessing attributes assigned during setUpTestData() are not going
> to be affected by this change at all. In other words, I suggest only doing
> the deep copy if required for the requested attributes so if you define a
> complex data set in setUpTestData() then only the few attributes and their
> related objects would get deepcopied on instance attribute accesses.
>
> > Could you just capture any copy exceptions, raise a deprecation warning,
> and abandon the copy for that attribute?
>
> Yeah that's the exact plan for the deprecation phase; warn and return the
> actual attribute. From Django 3.1 this would result in an AttributeError.
>
> I've updated the branch with the deprecation warnings[0] approach.
>
> I'll give it one or two more weeks to gather a bit more feedback but it
> looks like this could be a viable option so far.
>
> Cheers,
> Simon
>
> [0]
> https://github.com/django/django/compare/master...charettes:testdata#diff-5d7d8ead1a907fe91ffc121f830f2a49R1032
>
> Le mercredi 28 novembre 2018 21:40:53 UTC-5, Josh Smeaton a écrit :
>>
>> Our project also suffers extensively with mutating objects assigned from
>> setUp, preventing us from moving most of our tests to setUpTestData. I'll
>> likely begin using your pypi package right away, thanks Simon!
>>
>> Backward compat issues are probably likely - but they'd be in test cases
>> exclusively, making them extremely easy to find during an upgrade. That
>> said, a deprecation warning is probably the most sensible path forward to
>> prevent the need for immediate action.
>>
>> Is there anyway to determine the pickle-ability of something without just
>> trying to pickle it? I wouldn't be keen on that overhead. Could you just
>> capture any copy exceptions, raise a deprecation warning, and abandon the
>> copy for that attribute?
>>
>> On Saturday, 24 November 2018 14:29:33 UTC+11, charettes wrote:
>>>
>>> Dear developers,
>>>
>>> Django 1.8 introduced the `TestCase.setUpTestData()` class method as a
>>> mean to
>>> speed up test fixtures initialization as compared to using `setUp()`[0].
>>>
>>> As I've come to use this feature and review changes from peers using it
>>> in
>>> different projects the fact that test data assigned during its execution
>>> couldn't be safely altered by test methods without compromising test
>>> isolation
>>> has often be the source of confusion and frustration.
>>>
>>> While the `setUpTestData` documentation mentions this limitation[1] and
>>> ways to
>>> work around it by using `refresh_from_db()` in `setUp()` I believe it
>>> defeats
>>> the whole purpose of the feature; avoiding unnecessary roundtrips to the
>>> database to speed up execution. Given `TestCase` goes through great
>>> lengths to
>>> ensure database level data isolation I believe it should do the same
>>> with class
>>> level in-memory data assigned during `setUpTestData`.
>>>
>>> In order to get rid of this caveat of the feature I'd like to propose an
>>> adjustment to ensure such in-

Re: Pluggable secret key backend

[Tobias McNulty]

Personally, I like the simplicity and elegance of a single SECRET_KEYS
setting. It's also a good way to raise awareness that rotation is A Good
Thing to be doing anyways.

In any case, I second all of those who've already endorsed this idea. If I
can help, let me know.

Tobias

On Sun, Nov 18, 2018, 6:25 PM Adam Johnson  Very good point. I'd prefer a second setting though, named like
> OLD_SECRET_KEYS or VERIFICATION_SECRET_KEYS. If we're going to add a new
> setting, we might as well not force users who aren't rotating their keys to
> the new one, especially if they are semantically different.
>
> On Sun, 11 Nov 2018 at 18:32, Aymeric Augustin <
> aymeric.augus...@polytechnique.org> wrote:
>
>> Good point, I can think of at least two apps of mine that would break.
>> Transitioning to a new setting makes more sense.
>>
>> --
>> Aymeric.
>>
>>
>>
>> > On 11 Nov 2018, at 18:58, Tom Forbes  wrote:
>> >
>> > Is it going to be easy to adjust the semantics of SECRET_KEY to support
>> sequences like that? I’d imagine a lot of third party packages that expect
>> SECRET_KEY to be a string would break in weird ways (thanks to both strings
>> and tuples of strings being iterables that yield strings).
>> >
>> > Here’s a quick search on GitHub:
>> https://github.com/search?q=%22settings.SECRET_KEY%22&type=Code
>> >
>> > To ease the backward compatibility concerns we could use SECRET_KEYS,
>> then make SECRET_KEY (if it is not explicitly defined) map to
>> SECRET_KEYS[0]? Third party packages using would not necessarily work with
>> the backwards verification but they would at least not break and continue
>> to work as expected.
>> >
>> > Tom
>> >
>> >
>> >
>> >
>> >
>> > On 11 November 2018 at 07:38:15, Aymeric Augustin (
>> aymeric.augus...@polytechnique.org) wrote:
>> >
>> >> Hello,
>> >>
>> >> I think this is a great idea.
>> >>
>> >> As suggested by others, an even better default implementation would be:
>> >>
>> >> class SecretKeysBackend:
>> >>
>> >> def get_signing_key(self):
>> >> if isinstance(settings.SECRET_KEY, (list, tuple)):
>> >> return settings.SECRET_KEY[0]
>> >> else:
>> >> return settings.SECRET_KEY
>> >>
>> >> def get_verification_keys(self):
>> >> if isinstance(settings.SECRET_KEY, (list, tuple)):
>> >> return settings.SECRET_KEY
>> >> else:
>> >> return [settings.SECRET_KEY]
>> >>
>> >> Once Django is updated to take advantage of this feature, hat would
>> make key rotation practical for every Django user!
>> >>
>> >> (And it seems easier to adjust the semantics of SECRET_KEY than to
>> introduce a SECRET_KEYS settings.)
>> >>
>> >> Best regards,
>> >>
>> >> --
>> >> Aymeric.
>> >>
>> >>
>> >>
>> >>> On 10 Nov 2018, at 11:12, Andreas Pelme  wrote:
>> >>>
>> >>> Hi,
>> >>>
>> >>> settings.SECRET_KEY can be used for sessions, password resets, form
>> wizards and
>> >>> other cryptographic signatures via the signing APIs. Changing
>> SECRET_KEY means
>> >>> that all of those will be invalidated and the users will be affected
>> in weird
>> >>> ways without really knowing what happened. (Why am I logged out?
>> Where did my
>> >>> form submission go? Why does not this password reset link work?).
>> This is
>> >>> desirable in case the key is compromised and swift action must be
>> taken.
>> >>>
>> >>> There are other situations when it would be nice to change the
>> SECRET_KEY when
>> >>> this sudden invalidation is not desirable:
>> >>>
>> >>> - When someone leaves a project/company that had access to the
>> production
>> >>>  system. After SSH keys/login credentials is revoked the developer
>> could
>> >>>  potentially have a copy of the secret key. It is essentially a
>> backdoor with
>> >>>  full remote access. It would be wise to rotate the key in those
>> cases.
>> >>>
>> >>> - Periodic and automatic rotations of keys to make it less useful in
>> the
>> >>>  future.
>> >>>
>> >>> The current situation of a single SECRET_KEY makes key rotation
>> impractical. If
>> >>> you run a busy site with active users 24/7, there is never a nice
>> time to
>> >>> change the SECRET_KEY.
>> >>>
>> >>> A solution for this problem would be sign new secrets with a new key
>> while
>> >>> still allow signatures made with the old key to be considered valid
>> at the same
>> >>> time. Changing keys and having a couple of hours of overlap where
>> signatures
>> >>> from both keys are accepted would mitigate most of the user facing
>> problems
>> >>> with invalidating sessions, password reset links and form wizard
>> progress.
>> >>>
>> >>> You could do this today by implementing your own session backend,
>> message
>> >>> storage backend and password reset token generator but that is
>> cumbersome and
>> >>> does not work across reusable apps that directly use low level Django
>> signing
>> >>> APIs unless they too provide hooks to provide your own secret.
>> >>>
>> >>> I propose a pluggable project wide secret key backend
>> >>> 

Re: Question (potential feature request) on dropping database column in migration

[Tobias McNulty]

Hello,

I don't think this is something Django can or should handle. You need to
make your change in smaller increments so it doesn't break.

The proper forum for discussing this is the Django users list (or IRC or
Google...).

Good luck!

Tobias


On Mon, Oct 1, 2018, 8:47 PM martin_x  wrote:

> Hi there,
>
> Thanks for making Django a great framework for starters :D
>
> Recently my team have run into problems when trying to remove a database
> column from the model without stopping our Django server, below is the
> timeline:
>
> 1. Before migration happens, we have column_A we want to remove, and
> running on old release_1
> 2. Now we run migration to remove column_A, our webserver is still running
> on old release_1 and serving requests
> 3. After migration, we ship the new release_2
>
> However, between step 2 and 3, there are requests coming and referencing
> column_A we want to remove, and throws a exception of course.
>
> So is there anyway I can mark a database column a special state
> (deprecated, purged in memory, etc), so it has the following affect:
> 1. Won’t generate migration file, which means database wise, nothing has
> changed
> 2. However, when Django loads the model into memory, it will ignore
> column_A completely. So query, create, update, etc won’t try to access
> column_A.
>
> The reason we want to do it that way is so we can achieve no downtime,
> seamless migration for our application. I believe more people will benefit
> from this.
>
> Please let me know if more information is needed. Looking forward to
> hearing from you.
>
> Martin
>
> --
> 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/50dbe737-0b6c-42d2-9f76-99c188c916e7%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/CAMGFDKSXwhZ0Rhs1qH6FttP7rcgHoRoS5dLoHT7JFxn7iMdCzQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Sealing or locking QuerySets -- a suggestion to prevent surprise N+1 queries.

[Tobias McNulty]

1. I also could not find anything other than #26481 and a brief discussion
<https://groups.google.com/d/msg/django-developers/xQCGx6MOZ8M/l42MypOCBAAJ> of
it on the list.

2. I've often wished for something like this, but ended up resorting to
assertNumQueries() for lack of a better solution. So yes, it'd certainly be
useful to me/us, and I'd be curious to see how one might go about
implementing it.

3. My gut says that an API, in Django core, that builds off of #26481
(e.g., .only(strict=True) and .defer(strict=True)) is the right direction
(even for related fields), and my preference would be for a loud failure
(i.e., an exception rather than a log message) when this "strict" mode is
enabled. One can easily downgrade that to a log message when needed, less
so the other way around.



*Tobias McNulty*Chief Executive Officer

tob...@caktusgroup.com
www.caktusgroup.com

On Wed, Jan 3, 2018 at 12:33 PM, 'Bryan Helmig' via Django developers
(Contributions to Django itself)  wrote:

> At Zapier we're working with some rather complex and performance sensitive
> QuerySet building (most currently around experimenting with GraphQL) and I
> am constantly worried that the laziness of the ORM will surprise us in
> production (after a few levels of related nesting, the math of a mistake
> starts to really, really hurt). While not difficult to prevent, it does get
> a bit tedious maintaining constant vigilance :tm:. I was curious if sealing
> or locking a QuerySet has ever been seriously discussed before.
>
> For example, you might do something like:
>
> class Tag(models.Model):
> name = models.CharField()
> slug = models.SlugField()
> # etc...
>
> def get_url(self):
> return reverse('tag_index', args=[self.slug])
>
> class Post(models.Model):
> title = models.CharField()
> tags = models.ManyToManyField(Tag)
> # etc...
>
> posts = Post.objects.only(
> 'id', 'title',
> ).prefetch_related(
> Prefetch('tags', queryset=Tag.objects.only('id', 'name')),
> )
>
> # we'd .seal() or .strict() and evaluate the queryset here:
> for post in posts.seal():
> # get_url() would normally execute the classic N+1 queries
> # but after qs.seal() would instead raise some exception
> print ', '.join(tag.get_url() for tag in post.tags.all())
>
> Traceback (most recent call last):
>   File "", line 1, in 
> SealedQuerySetException: Cannot load sealed deferred attribute 'slug' on
> prefetched Tag model.
>
> Of course the obvious solution is to just add 'slug' to only(), but in a
> sufficiently complex application with many engineers working across various
> app boundaries it is both difficult to predict and test against. It
> requires lots of explicit self.assertNumQueries() and in the worse case can
> cause "production surprise" as deeply nested QuerySets can potentially
> explode in queries.
>
> This doesn't apply only to deferred attributes, but also related
> OneToOne, ManyToOne, ManyToMany, etc. lazy resolution. FWIW, I would image
> the FK/M2M N+1 pattern is a much more common surprise than opting into
> .only() or .defer() as my example above outlines.
>
> I had a go at implementing it outside of Django core, but ended up having
> to go down a monkey patching rabbit hole so I thought I'd reach out to the
> mailing list. I'd imagine setting a flag when evaluating a QuerySet to
> disable the laziness of a Model's fields and relations would be sufficient
> (IE: if it isn't in cache, raise SealedQuerySetException). It also seems
> backwards compatible, if you don't use .seal() you are still lazy like
> before.
>
> So, I guess my questions are:
>
> 1. Are there any other past discussions around this topic I can look at? I
> did find https://code.djangoproject.com/ticket/26481 which seems similar,
> but doesn't mention relationships.
> 2. Does this seem useful to anyone else? Specifically opting to raise
> explicit exceptions instead of automatic (and sometimes surprising) queries.
> 3. Anyone have tips on implementing this as a library external to Django
> with lots of monkey patching?
>
> I'd be happy to take a swing at it if there was a >50% chance that it
> would be at least considered.
>
> -bryan, cto & cofounder @ zapier
>
> --
> 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, s

Re: Automatic prefetching in querysets

[Tobias McNulty]

On Sat, Aug 19, 2017 at 1:10 PM, Luke Plant  wrote:

> This could work something like the way that ForeignKey `on_delete` works -
> you have options that are enumerated as constants, but in reality they are
> classes that embody the strategy to be used. We could have something
> similar - `on_missing_relation=FETCH | WARN | ERROR | IGNORE ... `
>
I like this a lot. It (1) caters (I think) to many if not all of the
behavior preferences expressed in this thread, (2) mimics an existing API
we support, (3) allows projects to gradually add/try the feature, and (4)
permits but does not require a deprecation path for changing the default
behavior in the future. I'm assuming `FETCH` represents the current
behavior and not auto-detection of a missing relation and modification of
the associated QuerySet.

One alternative thought: Could we define two `ForeignKey` options (again
using the `on_delete` analogy) which support adding the relation to
select_related()/prefetch_related() all the time (e.g.,
`ForeignKey(prefetch_related=ALWAYS | MANUALLY | WARN | ERROR)` and/or
`ForeignKey(select_related=ALWAYS | MANUALLY | WARN | ERROR)`, where
MANUALLY represents the current behavior)? One could then use `.only()` or
`.values*()` to avoid fetching the related model, if needed.


*Tobias McNulty*Chief Executive Officer

tob...@caktusgroup.com
www.caktusgroup.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 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/CAMGFDKQTEO%3DZug%3DCbrugX-mYV2wFAa3t7YHEKSUgtkAsJ_yX9Q%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Make bool(AnonymousUser) evaluate to false

[Tobias McNulty]

I second the objections; my assumption when reading the line 'if
request.user:' is that it's shorthand for 'if request.user is None', which
is not the case.

Grepping a project's code for incorrect usage of 'request.user' is simple
enough, so hopefully that will suffice. I don't recommend this because I
think existing Django developers would find it confusing, but technically
it would be possible to change or swap out instances of AnonymousUser via
middleware, too.

Lastly, this related ticket might be of interest:
https://code.djangoproject.com/ticket/20313

Tobias


*Tobias McNulty*Chief Executive Officer

tob...@caktusgroup.com
www.caktusgroup.com

On Wed, May 31, 2017 at 12:56 PM, Tim Graham  wrote:

> My thoughts from the ticket, "The Django test suite passes with the change
> but I feel like that could have some backwards compatibility concerns. Also
> "explicit is better than implicit"?
>
> On Wednesday, May 31, 2017 at 12:44:51 PM UTC-4, Linus Lewandowski wrote:
>>
>> I suggest adding __bool__() method returning False to the AnonymousUser
>> class.
>>
>> This way it'll be possible to check if the user is authenticated by
>> simply writing "if request.user:"
>>
>> It's a frequent source of bugs (at least for me, but probably I'm not
>> alone) that right now this code returns True for anonymous users. If
>> unnoticed, such bugs can also lead to security issues.
>>
>> Related ticket: https://code.djangoproject.com/ticket/28259
>>
> --
> 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/0c20c042-cc34-4707-a3e0-
> eed3ce2cf83d%40googlegroups.com
> <https://groups.google.com/d/msgid/django-developers/0c20c042-cc34-4707-a3e0-eed3ce2cf83d%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  (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/CAMGFDKQCfScbHYA8JfLtb2cDqt9Nz%3DA%3D8Qg9wJRhkz0sGju6GQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Proposal: provide postgresql powered full-text search in djangoproject.com

[Tobias McNulty]

I'm no FTS expert, but based just on the facts raised in this thread, if
using Postgres FTS

   1. would not break existing nor potential search needs (in fact it might
   expand the functionality available) and
   2. would allow eliminating an entire service from the infrastructure

that seems like a net win to me and as such at least worth exploring
further. That is not to say I think we should commit to switching, but if
we have volunteers who are excited to flesh out this proposal with some
code and understand there's no guarantee it will actually get merged, I
don't (yet) see a reason to say no.

Tobias


*Tobias McNulty*Chief Executive Officer

tob...@caktusgroup.com
www.caktusgroup.com

On Mon, May 8, 2017 at 10:07 AM, Marc Tamlyn  wrote:

> Yes, don't need that sorry.
>
> On 8 May 2017 at 14:40, Adam Johnson  wrote:
>
>>  I'm pretty sure our search requirements on dp.com need that,
>>
>>
>> s/need/don't need/ ? 😉
>>
>> On 8 May 2017 at 13:59, Marc Tamlyn  wrote:
>>
>>> I'm not sure I see the benefit here. The strength and purpose of
>>> postgres FTS is that you can combine some FTS behaviour with some
>>> relational queries easily at the same time. I'm pretty sure our search
>>> requirements on dp.com need that, so using a dedicated search provider
>>> is a better option.
>>>
>>> On 7 May 2017 at 13:22, Florian Apolloner  wrote:
>>>
>>>> On Sunday, May 7, 2017 at 12:45:27 PM UTC+2, Adam Johnson wrote:
>>>>>
>>>>> I guess we'd also have the benefit of not having to keep elasticsearch
>>>>> running.
>>>>>
>>>>
>>>> On the contrary, putting it into postgres means we have to care about
>>>> it. Putting it into Elasticsearch means we can let our hoster take care
>>>> about that.
>>>>
>>>>
>>>>> But I'm afraid I'm not familiar with Postgres. Is the FTS in Postgres
>>>>> mostly equivalent to ES, or will some kinds of search queries be affected?
>>>>>
>>>>
>>>> For the queries we use I think we can get pretty much equivalent
>>>> results.
>>>>
>>>> --
>>>> 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
>>>> gid/django-developers/ecd3a1ea-63d9-430c-af79-951022fec138%4
>>>> 0googlegroups.com
>>>> <https://groups.google.com/d/msgid/django-developers/ecd3a1ea-63d9-430c-af79-951022fec138%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 (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
>>> gid/django-developers/CAMwjO1GFKbXyebkqmok_RYv3Hywq%3DfwXrfz
>>> XcgFxtZU7-Ez5%3DA%40mail.gmail.com
>>> <https://groups.google.com/d/msgid/django-developers/CAMwjO1GFKbXyebkqmok_RYv3Hywq%3DfwXrfzXcgFxtZU7-Ez5%3DA%40mail.gmail.com?utm_medium=email&utm_source=footer>
>>> .
>>>
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>>
>>
>>
>> --
>> Adam
>>
>> --
>> 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:/

Re: Ticket 2273: django.contrib.auth.models.User: username is case-sensitive

[Tobias McNulty]

I'm surprised that (as far as I can see) this idea hasn't been discussed in
the ~11 year (!) history of this ticket. It was alluded to ~3 years go by
mkhalil28 <https://code.djangoproject.com/ticket/2273#comment:12>, but was
missing the backwards-compatible 'except' bit and didn't get any follow-up
discussion. To me this seems like an appropriate corresponding change to
#25617 <https://code.djangoproject.com/ticket/25617>.

If I'm thinking through this correctly, this would provide, for all intents
and purposes:

   - case-insensitive usernames for all new sites (and new users on
   existing sites)
   - indefinite backwards compatibility for sites that already have
   "duplicate" usernames in the database, when case is ignored
   - no feature flag that needs to be maintained
   - the added benefit of allowing sites that really want case-sensitive
   usernames to disable this behavior, if needed (by never adding unique=True
   to the username field)

If a change like this has been considered already, I am curious to know why
it was rejected.

I am not suggesting (yet) that we re-open #2273, but I think this would at
least be worth exploring further: What would a minimum-impact change for
case-insensitive usernames look like, both in terms of code and
documentation changes? #25617 + this change seem like a good start, but
more work will certainly be required to get this into a state that's ready
for formal review. I probably won't have time to do that myself in the near
future, but I would be happy to serve as a reviewer.

Tobias



*Tobias McNulty*Chief Executive Officer

tob...@caktusgroup.com
www.caktusgroup.com

On Sun, Apr 16, 2017 at 5:47 PM, Info-Screen 
wrote:

> Wouldn't it be possible to implement case-insensitive usernames without
> loosing backwards compatibility, by checking the username iexact and only
> if there are multiple possibilities fall back to the old case-sensitive
> variant?
>
> So something like this:
>
> diff --git a/django/contrib/auth/base_user.py b/django/contrib/auth/base_
> user.py
> index 34dd6ac2f2..748db8bf89 100644
> --- a/django/contrib/auth/base_user.py
> +++ b/django/contrib/auth/base_user.py
> @@ -4,6 +4,7 @@ not in INSTALLED_APPS.
>  """
>  import unicodedata
>
> +from django.core.exceptions import MultipleObjectsReturned
>  from django.contrib.auth import password_validation
>  from django.contrib.auth.hashers import (
>  check_password, is_password_usable, make_password,
> @@ -41,7 +42,14 @@ class BaseUserManager(models.Manager):
>  return get_random_string(length, allowed_chars)
>
>  def get_by_natural_key(self, username):
> -return self.get(**{self.model.USERNAME_FIELD: username})
> +username_field = self.model.USERNAME_FIELD
> +
> +# Try case-insensitive match of username.
> +# If there are multiple possiblities fallback to case-sensitive
> lookup
> +try:
> +return self.get(**{username_field + '__iexac': username})
> +except MultipleObjectsReturned:
> +return self.get(**{username_field: username})
>
>
>  class AbstractBaseUser(models.Model):
>
> --
> 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/cc07fa69-06b3-4d24-aa2c-
> e5201ebe936a%40googlegroups.com
> <https://groups.google.com/d/msgid/django-developers/cc07fa69-06b3-4d24-aa2c-e5201ebe936a%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  (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/CAMGFDKQaa4RX31yJqOapRvehH8GBPObybJmLCJ44JqT0OZpqFA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: DJANGO_SETTINGS_FILE

[Tobias McNulty]

I don't see Django making a change like this. If it's really impossible to
get your production settings file on an already-importable Python path, you
*could* modify your PYTHONPATH
<https://docs.python.org/3/using/cmdline.html#envvar-PYTHONPATH>
environment variable to add the directory containing your Django settings
file. That being said, I think you're better off keeping all your settings
files in version control where they belong, and changing the things you
need to change via environment variables.

On Thu, Apr 6, 2017 at 9:20 AM, James Pic  wrote:

> Hi all!
>
> Life with DJANGO_SETTINGS_MODULE has been great. However, it requires the
> settings to be an importable module. In most cases, this is a straight
> forward "simple" python script.
>
> Sometimes it looks like it could make sense to add an environment variable
> that could use a file that is not importable as a python module, ie.:
>
> DJANGO_SETTINGS_FILE=/etc/yourapp/production.py
> DJANGO_SETTINGS_FILE=~/yourapp_production.py
> DJANGO_SETTINGS_FILE=settings.py  # relative to pwd
>
> Then, in this file, we could override the default project settings there
> without having to put the new file in an importable module, ie. in
> /etc/yourapp/production.py:
>
> from yourapp.settings import *
> DATABASES=...
> CACHES=...
> SECRET_KEY=...
>
> I'm sure this has been discussed before but didn't find anything by
> searching DJANGO_SETTINGS_FILE in the ML.
>
> What's your opinion on this ? Is it time to upgrade this ?
>
> Best,
>
> --
> 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/CAC6Op19-0JeL8Jdcq70-pvwz%
> 2Bi2hfKtopEvihca_rGfH1DrPww%40mail.gmail.com
> <https://groups.google.com/d/msgid/django-developers/CAC6Op19-0JeL8Jdcq70-pvwz%2Bi2hfKtopEvihca_rGfH1DrPww%40mail.gmail.com?utm_medium=email&utm_source=footer>
> .
> For more options, visit https://groups.google.com/d/optout.
>



-- 


*Tobias McNulty*Chief Executive Officer

tob...@caktusgroup.com
www.caktusgroup.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 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/CAMGFDKThapJkEykuhxFEuTF%2BZNjHNr7t6p%3Dssenb0qM85DVXyQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Django versioning and breaking changes policy

[Tobias McNulty]

Hello Bernhard,

In my experience, Django strikes a good balance between adding new features
without moving so quickly that it's impossible to keep up. That being said,
third-party packages *can* vary widely in the speed with which they add
support for new Django versions after a new major release.

What are some changes in Django over the past few releases that you felt
were too significant or costly to address?

Tobias

On Tue, Apr 4, 2017 at 3:15 PM, Bernhard Posselt 
wrote:

> Hi guys :)
>
> I'm maintaining a Django project that uses 6 apps:
>
> * djangorestframework,
>
> * django-parler (database translations),
>
> * django-allauth (openid & richer account settings)
>
> * django-recaptcha2 (simple recaptcha widget)
>
> * django-csp
>
> * django-cors-middleware
>
> Each time a new Django version is published it takes me at least a few
> weeks to upgrade. The reason is that each release breaks something in
> the apps that I use. Code that I wrote myself can usually be fixed
> pretty quickly.
>
> Personally I don't think that the number of dependencies is excessive.
> Furthermore I think that Django developers want to offload as much
> functionality as possible to thirdparty apps to improve maintainability
> so I doubt that I'm the only one with these issues.
>
> I know that deprecating and cleaning up things is *very* important to
> keep the framework alive however was it ever considered to tune down the
> frequency of breaking changes (like only remove features in a new LTS
> release)?
>
> Apart from that would it be possible to adopt semver? If you had
> followed semver closely, each 1.x release would have actually been a
> major release (e.g. 1.1 -> 2.0.0, 1.2 -> 3.0.0) and your point releases
> would need to contain three version numbers (e.g. 1.11.0 and not 1.11).
>
> I know that this versioning approach leads to very high version number
> in a short amount of time but that's essentially what Django does:
> breaking compat with each release :)
>
>
>
> --
> 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
> gid/django-developers/7fde82bd-352d-9946-2cbc-699f04bd8773%40gmail.com.
> For more options, visit https://groups.google.com/d/optout.
>



-- 


*Tobias McNulty*Chief Executive Officer

tob...@caktusgroup.com
www.caktusgroup.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 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/CAMGFDKRDPBk9CSMe%3DOE-xN1zBTkya6rxWzabvnEQWPe4-GhOBA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: RedirectView failing silently on NoReverseMatch is confusing

[Tobias McNulty]

On Thu, Jan 19, 2017 at 4:07 PM, Adam Johnson  wrote:
>
> I'm +1 on removing the try/except because I think broken things should
> fail obviously.
>

Another +1. I have little patience for except statements that hide errors I
might care about, and this seems like one of those cases.

Tobias
-- 


*Tobias McNulty*Chief Executive Officer

tob...@caktusgroup.com
www.caktusgroup.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 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/CAMGFDKT3SEaAMEryw5GTXiEbaxeoiU%3D08HX69OaWf2etLJTFUg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Switching the default password hasher to Argon2 (was: Methodology for increasing the number of PBKDF2 iterations)

[Tobias McNulty]

On Thu, Jan 5, 2017 at 10:58 AM, Martin Koistinen 
wrote:

> Slightly off-topic, this presents a really nice case for switching to
> Argon2 via argon2_cffi (supported in Django 1.10+). Its super fast (C-lib)
> and resistant to GPU/ASIC brute-forcing. So, where as an attacker's 8-GPU
> hashing machine would probably have something on the order of 24,000X more
> hashing capability for SHA256 than a typical Django server, I estimate that
> the same hardware (8 GPUs) would only have about 20-30X more hashing
> capability than a typical server. (Note, the anecdotal evidence across the
> internet supporting this is pretty thin).
>

This is an interesting point. Argon2 is recommended over PBKDF2 by OWASP
<https://www.owasp.org/index.php/Password_Storage_Cheat_Sheet#Leverage_an_adaptive_one-way_function>
and
even Django itself
<https://docs.djangoproject.com/en/1.10/releases/1.10/#django-contrib-auth>.
From
what I understand, the only reason it's *not* the default now is the 3rd
party dependency, which does require a C compiler and the libffi library to
build, if a wheel isn't available for your OS. In a minimal Python
3.5-alpine Docker image, I needed the following packages before I could
`pip install argon2_cffi` (which themselves had a collective ~12 additional
dependencies):

   - gcc
   - musl-dev (libc headers)
   - libffi
   - libffi-dev

Could anyone familiar with the draft DEP 7: Dependency Policy
<https://github.com/django/deps/blob/master/draft/0007-dependency-policy.rst>
and/or the addition of the Argon2 hasher
<https://github.com/django/django/commit/b4250ea04a88f6c4fdf84dc8624baa1cf3e0f568>
comment on the suitability of argon2_cffi (or not) for consideration under
DEP 7? I think it meets most if not all of the "maturity" guidelines in the
policy, with the one exception being that it presents an interesting test
case for the footnote
<https://github.com/django/deps/blob/master/draft/0007-dependency-policy.rst#id2>
on the "dependencies that require C extensions are *probably* not
acceptable" statement. There are wheels available for argon2_cffi on a
large number of platforms, but I still had to compile it manually on Alpine
Linux (a popular OS for minimal Docker images) and for Python 3.6 on my Mac
(there is a wheel available when using Python 3.5 on a Mac).

I have trouble imagining that there are many production Django apps out
there that don't compile *something* in their requirements file (e.g.,
psycopg2 or Pillow), in which case argon2_cffi essentially requires no
extra lift. That said, it is pretty incredible that beginners can (still)
install Django just about anywhere they have Python without compiling
anything at all.

I wonder if there's an alternative to forcibly requiring it, where most
users would eventually do so for production use, but had greater
flexibility when running locally? Only the security-minded will go through
the trouble of changing the default password hasher currently, so ideally
users would get a stronger nudge than they do now when it comes time to
deploy to production. Making a switch here also has the added benefit of
circumventing some of the concerns around increasing PBKDF2 iterations
<https://groups.google.com/forum/#!topic/django-developers/Qab-hRG-SKs>
over time.

Tobias
-- 


*Tobias McNulty*Chief Executive Officer

tob...@caktusgroup.com
www.caktusgroup.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 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/CAMGFDKQxnBmMhpXFPj1QEvkocb%3D8CXsddMYP%2BjTu%2B%2BB0ce9enQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Methodology for increasing the number of PBKDF2 iterations

[Tobias McNulty]

I'm not sure the DoS concern is really something that can be addressed
here. Regardless of the number of iterations we choose, POSTing to the
login form will always be a target, unless it's appropriately protected
(i.e., with some combination of rate limiting, recaptcha, and/or something
at the network level). A run-of-the-mill cloud server that doesn't limit
access to the Python app in some way is simply never going to be a match
for a malicious person with a laptop, let alone a more sophisticated attack.

I created a tox.ini
<https://github.com/tobiasmcnulty/hash_benchmark-ubuntu-12.04/blob/master/tox.ini>
to
run Martin's benchmark with multiple Django & Python versions. A couple
notes:

   - I ran this several times on Circle CI using Ubuntu 12.04
   <https://circleci.com/gh/tobiasmcnulty/hash_benchmark-ubuntu-12.04/13>
   with Python 2.7.7, 3.3.3, 3.4.3, and 3.5.0, and Ubuntu 14.04
   <https://circleci.com/gh/tobiasmcnulty/hash_benchmark-ubuntu-14.04/1>
   with 2.7.12, 3.3.6, 3.4.4, and 3.5.2. To view the results, expand the "tox"
   section under the "Test" header.
   - All results are what one would expect: Python 2.7.7 and Python 3.3.x
   are ~3-4x slower than Python 2.7.8+ and Python 3.4+, and there are no
   inexplicably slow outliers, like the official Python 3.5.2 installer for OS
   X.

My local results are as follows:

   - Ubuntu 16.04 w/a Core i5 @ 3.50GHz:
  - 62-65ms for 100,000 iterations
  - 100-106ms for 165,000 iterations
   - Mac OS 10.12, Core i5 @ 2.7GHz:
  - 117-120ms for 100,000 iterations
  - 195-203ms for 165,000 iterations

I really don't know how we can pick a number that'll work for everyone, but
I'm all for setting it high and allowing people to decrease the number of
iterations or, better yet, switch to the hasher that the docs recommend
everyone use anyway
<https://docs.djangoproject.com/en/1.10/topics/auth/passwords/#using-argon2-with-django>
(Argon2). If we define 100-120ms as acceptable performance, 100k would seem
reasonable based on the results above and posted elsewhere in this thread.

Martin, FWIW, I can confirm that the Python 3.5.2 installer from python.org
demonstrates the same 3x slower behavior on my Mac that you saw. The Python
3.5.2 I installed from Homebrew does not, nor does the official python.org
installer for Python 3.6. Based on the absence of any similar outliers in
the above tests, however, I still think the conclusion here should be to
fix the underlying Python build (if it's really creating a performance
issue for you or anyone else), not hold back Django from bumping its
default number of PBKDF2 iterations. Dropping Python 2.7 support still
means we lose a large swath of definitely-slow PBKDF2 implementations:
24.4% of installs where the Python version was known were using 2.7.5
or 2.7.6 in the chart Alex posted.

The point about switching Django's default to Argon2 is an intriguing one.
In the event there are still a bunch of slow PBKDF2 implementations out
there with Python 3.5+, one benefit of dramatically increasing PBKDF2
iterations is that it might push more people to Argon2. :-D On a more
serious note, I'll reply separately to that thread to save this one for the
original topic.

Tobias

On Wed, Jan 11, 2017 at 10:39 AM, Tim Graham  wrote:

> I agree. The question in my mind is how to pick an appropriate number of
> iterations that we don't risk causing a DoS on (at least most) existing
> sites due to increased CPU usage. Or at least, can we offer some
> suggestions about how to tell if your site receives sufficient traffic that
> you might be impacted? Did anyone notice increased CPU usage in past
> upgrades?
>
> On Tuesday, January 10, 2017 at 1:27:19 PM UTC-5, Tobias McNulty wrote:
>>
>> IMO this doesn't change the argument that it would be best to default to
>> the higher number of iterations (i.e., 100k or higher, given some time as
>> passed since 2013), while noting in the documentation that individual
>> projects have the ability to reduce it if need be (though perhaps
>> recommending that they try first to find a faster Python). Other thoughts?
>>
>> On Mon, Jan 9, 2017 at 10:44 PM, Martin Koistinen 
>> wrote:
>>
>>> The Python3.5 on my system was installed by the official Python
>>> installer, and is almost 3X slower than the Apple-built 2.7 install. I use
>>> pip all day long.
>>>
>>> True, my MacBook is not a server, but it still serves to demonstrate the
>>> point that it is not a reasonable assumption that all 3.5 installs use
>>> OpenSSL libraries.
>>>
>>> On Monday, January 9, 2017 at 7:39:18 PM UTC-5, Tim Graham wrote:
>>>>
>>>> About "we cannot just assume that all Python 3 installs have a "fast"
>

Re: Methodology for increasing the number of PBKDF2 iterations

[Tobias McNulty]

IMO this doesn't change the argument that it would be best to default to
the higher number of iterations (i.e., 100k or higher, given some time as
passed since 2013), while noting in the documentation that individual
projects have the ability to reduce it if need be (though perhaps
recommending that they try first to find a faster Python). Other thoughts?

On Mon, Jan 9, 2017 at 10:44 PM, Martin Koistinen 
wrote:

> The Python3.5 on my system was installed by the official Python installer,
> and is almost 3X slower than the Apple-built 2.7 install. I use pip all day
> long.
>
> True, my MacBook is not a server, but it still serves to demonstrate the
> point that it is not a reasonable assumption that all 3.5 installs use
> OpenSSL libraries.
>
> On Monday, January 9, 2017 at 7:39:18 PM UTC-5, Tim Graham wrote:
>>
>> About "we cannot just assume that all Python 3 installs have a "fast"
>> PBKDF2 implementation" -- I'd expect very few if any Django users to be
>> compiling their own Python and doing so without OpenSSL. I'm guessing that
>> any operating system Python will have the OpenSSL bindings. Or is that a
>> bad assumption?
>>
>> On Wednesday, January 4, 2017 at 2:13:09 PM UTC-5, Martin Koistinen wrote:
>>>
>>> I think this is a pretty solid guess. Bear in mind this was a direct
>>> install from Python.org.
>>>
>>> The important thing here is, this demonstrates that we cannot just
>>> assume that all Python 3 installs have a "fast" PBKDF2 implementation =/
>>>
>>> On Wednesday, January 4, 2017 at 11:33:17 AM UTC-5, Tobias McNulty wrote:
>>>
>>>> ...
>>>>
>>> Martin, is it possible your version of Python 3 is not linked against
>>>> OpenSSL and hence is missing the fast version of pbkdf2_hmac? I haven't had
>>>> a chance to try your benchmark yet, but in a quick test I don't see any
>>>> difference between Python 3.5.2 and Python 2.7.12 on a Mac.
>>>>
>>>> Tobias
>>>>
>>>
>>>
>>>
>> --
> 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/9261dcdc-f3b2-458c-a6e1-
> bde49642c56b%40googlegroups.com
> <https://groups.google.com/d/msgid/django-developers/9261dcdc-f3b2-458c-a6e1-bde49642c56b%40googlegroups.com?utm_medium=email&utm_source=footer>
> .
>
> For more options, visit https://groups.google.com/d/optout.
>



-- 


*Tobias McNulty*Chief Executive Officer

tob...@caktusgroup.com
www.caktusgroup.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 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/CAMGFDKRz1%2BBQXs%2BpQTSf%2BNds%3DjLx4QoPtfT1%3DywL0Gy%2Bzsk72w%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Adding a middleware to match cookies

[Tobias McNulty]

On Jan 7, 2017 11:41 PM, "Jeff Willette"  wrote:

the specific case I am talking about deals with google analytics cookies,
which are different for every user and sent with the request. When
accessing request.user, I really only care about sessionid and csrftoken,
if present. So sending a vary by cookie header back will cause all the
unauthed/unsessioned users to miss the cache because of the GA cookies.

Since I have no use for these cookies in my code, and they are only used
for external requests to GA, eliminating them somewhere (earlier the
better) should improve cache hits, right?


Perhaps, but the place to do that is in your edge cache servers, not Django:

* http://www.varnish-cache.org/docs/3.0/tutorial/cookies.html
* https://web.archive.org/web/20151031024029/https://www.fastl
y.com/blog/how-to-cache-with-tracking-cookies

I'm unclear how feasible this is (I've never tried it). It's with noting
the last page isn't even on Fastly's public site anymore.

In any event, I'm not seeing the case for a change to Django proper here.
If Django's cache middleware is the only cache you're using, you might be
able to accomplish something like the above via middleware, as Carl
suggested.

If you're looking for assistance with the middleware implementation, I
recommend the django-users list. If you're using a another cache in front
of Django, you'll need to figure how to implement this there, or find a
simpler route such as never setting the tracking cookies in the first
place, or splitting the request in two.

Good luck!

Tobias

-- 
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/CAMGFDKQSHNzAKfQj7CEnxKWn7S%2B%2Bq3%2B5v%2BeiQOjJ-nPPA76CgA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Methodology for increasing the number of PBKDF2 iterations

[Tobias McNulty]

=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 (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/15FEAB83-A9A4-4BC6-ABCB-
> D7BC04603E89%40polytechnique.org
> <https://groups.google.com/d/msgid/django-developers/15FEAB83-A9A4-4BC6-ABCB-D7BC04603E89%40polytechnique.org?utm_medium=email&utm_source=footer>
> .
>
> For more options, visit https://groups.google.com/d/optout.
>



-- 


*Tobias McNulty*Chief Executive Officer

tob...@caktusgroup.com
www.caktusgroup.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 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/CAMGFDKQYT_NsjBmOBPieKJnpK8z5TzQd4yvD5dYmubmfSNK6tw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Methodology for increasing the number of PBKDF2 iterations

[Tobias McNulty]

On Tue, Jan 3, 2017 at 1:14 PM, Adam Johnson  wrote:

> But, to be consistent with Django 1.x going forward, let's define 36,000
>> iterations as "acceptable performance" for a Python2 with Django 1.11
>> install on a typical piece of server hardware today (beginning of 2017). A
>> useful benchmark would be to determine how many iterations would yield the
>> same delay on a Py3 + Django 1.11 install on the same server.
>>
>
> That sounds like a sensible benchmark to see where we are at current. I
> think Django should be aiming for 100k+ as default at least to match the
> Python docs though. Let's not forget that users can tweak it down as well
> as up if they do have problems with the execution time.
>

I agree; this seems like a strong argument for setting it appropriately
high and documenting that it can be decreased if required, rather than
setting low enough that it won't cause an issue on any hardware and
documenting that developers should increase it (which seems less likely to
happen, IMO).

If the Python docs
<https://docs.python.org/3/library/hashlib.html#hashlib.pbkdf2_hmac> are
correct and the Python 3 pbkdf2_hmac implementation is 3x faster than the
version in Python 2, 100,000 would seem to be a fairly unobjectionable
(perhaps even a bare minimum) starting point, given we're starting with
around 30,000-36,000 in current Django. That said, that recommendation is
also ~4 years old at this point, so some benchmarks or at least further
research may be in order...

Tobias
-- 


*Tobias McNulty*Chief Executive Officer

tob...@caktusgroup.com
www.caktusgroup.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 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/CAMGFDKSR9UL4MikuzB-b%3D_1%2BDr5d2x5OK7maatV4ifwdUjkVyQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: #27485 new New feature Allow ALLOWED_HOSTS to accept an IP-range / wildcard

[Tobias McNulty]

There is a non-development use case here, which is being able to accept the
IP range for a subnet used in an EC2 VPC (used by load balancers for health
checks). Sure, I could iterate through all the potential IPs and add
them, divine
a way
<http://stackoverflow.com/questions/166506/finding-local-ip-addresses-using-pythons-stdlib>
to (maybe) discover it via the socket module, or make an HTTP request to
retrieve it from the EC2 meta data API, but this seems like another time
when being concise and explicit about the allowed IPs/subnets (without
requiring a network call from settings.py) would be helpful. Using the
established convention of subnets rather than wildcards would be preferred,
IMHO.

Tobias

On Wed, Nov 23, 2016 at 11:40 AM, 'Tom Evans' via Django developers
(Contributions to Django itself)  wrote:

> On Sat, Nov 19, 2016 at 1:01 AM, Florian Apolloner
>  wrote:
> > On Thursday, November 17, 2016 at 5:07:07 PM UTC+1, Tom Evans wrote:
> >>
> >> Or:
> >>   from socket import gethostname, gethostbyname
> >>   ALLOWED_HOSTS = [ gethostname(), gethostbyname(gethostname()), ]
> >
> >
> > That a) adds your hostname and b) (assuming you properly configured your
> > system) 127.0.0.1  -- so as long as they are using 192.* to access the
> site,
> > this does not help.
>
> Our servers are configured such that "localhost" resolves to
> 127.0.0.1, and the hostname resolves to the local IP of the server.
>
> I don't think our servers are in any way misconfigured, or configured
> in a "special" manner - my laptop is configured in precisely the same
> manner out of the box.
>
> The offered solution works correctly on all of our development and
> production servers, and also on our developers local machines running
> various versions of Linux.
>
> Cheers
>
> 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/CAFHbX1K_1dCLrMQm4cy0u1i1cnEzLJV%2Bb_1-
> p9n58ERV7%3Dghvg%40mail.gmail.com.
> For more options, visit https://groups.google.com/d/optout.
>



-- 


*Tobias McNulty*Chief Executive Officer

tob...@caktusgroup.com
www.caktusgroup.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 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/CAMGFDKRa3AkU18jCTtyO-XFmm%2BeQBWjTHuOQXegC%2ByNMPB%3D0Xg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: should blank POST data fallback to use model field defaults?

[Tobias McNulty]

On Fri, Aug 12, 2016 at 9:58 AM, Tim Graham  wrote:

> A change in Django 1.10 inadvertently caused the following behavior change:
>
> class M(models.Model):
> f = models.CharField(max_length=255, default='default_value')
>
> class MF(forms.ModelForm):
> f = forms.CharField(required=False)
>
> class Meta:
> model = M
> fields = ['f']
>
> >>> mf = MF({})
> >>> m = mf.save()
> >>> m.f
> '' (Django 1.10+)
> 'default_value' (Django < 1.10)
>
>
> On Django < 1.10, {'f': ''} as the form data (rather than empty form
> data) also results in a model instance with the model field default rather
> than an empty string. Claude and I agree that for this latter case,
> transforming an empty POST value to a model field default doesn't seem
> correct (that is, the new behavior seems better).
>

That certainly sounds incorrect to me and I would not want to see pre-1.10
behavior restored for the blank ('') value case.


> However, the desired behavior in the empty POST data case isn't so clear.
> For example, I could imagine an API call where it would be useful for the
> model to use the default if a user doesn't submit any data for that field.
> An issue with the idea that values not present in POST data fallback to
> their default is for HTML widgets like checkboxes. If a checkbox isn't
> checked, the key won't appear in POST data. In such a case, it's
> inappropriate for an unchecked checkbox to fallback to the model field's
> default if it's True. A draft patch to restore the Django < 1.10 behavior
> [1] special cases this with isinstance(form[f.name].field.widget,
> CheckboxInput) to fix some test failures but that hardly seems ideal.
>
> Do you feel we should try to restore the Django < 1.10 behavior or keep
> the new behavior and document that model field defaults are used to
> populate initial blank forms but not to fill missing data from the form
> input?
>

I tend to prefer the more cautious approach, i.e., allow the application to
supply default values to the form if they're not included in the POST, but
it sounds like I might be in the minority.

Tobias
-- 


*Tobias McNulty*Chief Executive Officer

tob...@caktusgroup.com
www.caktusgroup.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 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/CAMGFDKS5YMejS2494teExxV-UJmTqX36eHa4Bq5p6b%2Bk%2B64U_Q%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Improve queries on django admin

[Tobias McNulty]

I think the question was more about memory usage than speed, but the answer
is the same, in my opinion.

The only thing I'll add is that -- if returning a mere 100 rows of a table
is really causing memory issues -- there are alternatives to storing large
blobs of data directly in the DB (e.g., files).

Tobias

On Fri, Jul 22, 2016 at 6:22 PM, Shai Berger  wrote:

> I tend to agree with Tim -- in particular, a query on the admin should only
> return a small (<100) number of records, due to paging; if, for that size
> of
> query, you see a significant difference between returning all the columns
> and
> returning just the ones you need, it is suspicious: Either you have a very
> special case (e.g. it just happens that all the fields you chose to list
> are in
> an index, and so are selected extremely fast), or you're doing something
> wrong
> (which causes your default query to be very slow).
>
> For most cases, this should not be a significant optimization IMO.
>
> On Friday 22 July 2016 20:38:40 Tim Graham wrote:
> > I'm a bit wary of the complexity this would add, especially given this
> > warning in the documentation:
> >
> > The defer() method (and its cousin, only()
> > <
> https://docs.djangoproject.com/en/1.9/ref/models/querysets/#django.db.mode
> > ls.query.QuerySet.only>, below) are only for advanced use-cases. They
> > provide an optimization for when you have analyzed your queries closely
> > and understand *exactly* what information you need and have measured that
> > the difference between returning the fields you need and the full set of
> > fields for the model will be significant.
> >
> > I think it's better if developers override ModelAdmin.get_queryset() as
> > needed, as you've done. In particular, I thought of the case where a
> method
> > is used in list_display. In that case, I believe it's impossible to do
> the
> > optimization automatically since Django can't automatically determine
> what
> > fields a method might use.
> >
> > On Friday, July 22, 2016 at 9:51:27 AM UTC-4, Rael Max wrote:
> > > Hi Lucas, thanks for reply
> > >
> > > I think that select_related gives a great improve on performance but we
> > > can improve his usage passing the columns that we want retrieve,
> avoiding
> > > getting most columns/data and allocate more memory than necessary.
> > >
> > > Em quinta-feira, 21 de julho de 2016 17:01:00 UTC-3, Lucas Magnum
> escreveu:
> > >> You can use `list_select_related` for Django Admin too.
> > >>
> > >>
> > >>
> > >>
> > >> []'s
> > >>
> > >> Lucas Magnum.
> > >>
> > >> 2016-07-21 15:52 GMT-03:00 Rael Max :
> > >>> Hi everyone,
> > >>>
> > >>> I'm working in a project with a large mysql database and i've faced
> > >>> with problems generated on django admin list. Basically, the query
> > >>> executed to retrieve a list of items from a model uses a SQL SELECT
> > >>> passing a list of all attributes of model, but usually we only use a
> > >>> small set of them on *list_display* attribute.
> > >>>
> > >>> I solved this problem overriding the *queryset* method of
> *ModelAdmin*
> > >>> and using the method only of *QuerySet* using the fields listed on
> > >>> *list_display* attribute of *ModelAdmin*. With the limit of columns
> > >>> retrieved this queries should to consume less memory to be executed.
> > >>>
> > >>> Searching about this here and on django issue tracker i've not found
> > >>> nothing about. What you think about this optimization be the default
> > >>> behavior or use a *ModelAdmin* attribute to enable?
> > >>>
> > >>> Regards,
> > >>> Rael
>



-- 


*Tobias McNulty*Chief Executive Officer

tob...@caktusgroup.com
www.caktusgroup.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 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/CAMGFDKR4D9cCUAwTvdqStWm0Rv3AYbCRU4S7JFuoGY4wxdK%2Bhg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

GitHub PR status within Trac

[Tobias McNulty]

I spent some time during the DjangoCon sprint today looking into
dashboard.djangoproject.com and how it calculates metrics. I was hoping to
add some new metrics that mash up data from GitHub and Trac together. While
technically possible, this breaks down when you want to link out to a list
of the related tickets in Trac. For example:

   - A list of Accepted tickets with no open PR or an open PR that hasn't t
   been touched in X months
   - A list of Accepted tickets with no PR and no attached patch that
   haven't been touched in  months

This got me wondering: Is checking for GitHub PRs via JavaScript the Right
Way to do it? What if we had a cronjob update Trac periodically with PR
status from GitHub?

I think it would be valuable to be able to query on PR status from within
Trac, e.g., to help find in progress but stale/abandoned tickets. Cleaning
up the work of someone else who's lost interest in a patch is often a good
way to get into Django development.

I'm sure there are some holes in this idea, so I'm putting it out there for
comment. Was something like this considered before, and if so, why wasn't
it pursued?

If it hasn't been considered before, what are the obvious problems I might
encounter?

Rather than sync the data periodically, another approach might be to extend
the existing trac-github <https://github.com/trac-hacks/trac-github>
plugin, though that would still require sync'ing existing data up front and
substantial testing to make sure all the right events (e.g., renames and
closures) are caught appropriately. It's not as simple as adding a commit
hash to a ticket's history, esp. if we ever wanted to change the fields
that were brought over from GitHub.

Tobias
-- 


*Tobias McNulty*Chief Executive Officer

tob...@caktusgroup.com
www.caktusgroup.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 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/CAMGFDKS9LkX6wAXP_gEroQAs_0uf2Q3qLWON_thTupxmDW9XGA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: change commit message format to present tense?

[Tobias McNulty]

I'm in support of this as well. Is the suggestion to change the format to:

A) Fixes #12345 -- Add support for ... / Validate that  / etc.

OR

B) Fixes #12345 -- Adds support for ... / Validates that ... / etc.

OR

C) Something else?

I assume (A) but others may interpret this differently?

On Fri, Jun 24, 2016 at 1:25 PM, Markus Holtermann  wrote:

> I don't mind either way. If everybody seems to use present tense these
> days, yeah, let's do that as well. As long as the general style of the
> commit messages stays: Fixes|Refs #12345 -- Make it work
>
> My 2¢
>
> /Markus
>
>
> On Fri, Jun 24, 2016 at 11:04:39AM -0600, Jacob Kaplan-Moss wrote:
>
>> I'm not entirely sure because my memory sucks, but odds are that I started
>> the current standard of using past-tense.
>>
>> FWIW I no longer care even at all, I think as long as commit messages are
>> clear we I don't care what tense they are. Following the standard git way
>> seems totally OK to me.
>>
>> Jacob
>>
>> On Fri, Jun 24, 2016 at 10:59 AM, Carl Meyer  wrote:
>>
>> On 06/24/2016 10:55 AM, Tim Graham wrote:
>>> > A few contributors indicated in #django-dev that it could be beneficial
>>> > to change our commit message format to match git's guidelines of
>>> present
>>> > tense (instead of our current past tense convention) as it would be one
>>> > less thing to remember when contributing to Django. Besides consistency
>>> > with the current history, do you feel there are any benefits in
>>> > continuing to use past tense instead of present tense?
>>>
>>> I was one of those contributors in #django-dev. Not only are past-tense
>>> commit messages non-standard for git (meaning they are one more thing a
>>> new contributor is likely to trip over), I also personally find them
>>> harder to write and make clear. Sometimes in a commit message you need
>>> to reference past (pre-commit) behavior and make it clear how the commit
>>> changes that behavior. I occasionally find that harder to do clearly
>>> when the entire commit message is supposed to worded in the past tense.
>>>
>>> So I find all the advantages (except for consistency with past history)
>>> in favor of switching to the imperative mood.
>>>
>>> Carl
>>>
>>> --
>>> You received this message because you are subscribed to the Google Groups
>>> "Django developers  (Contributions to Django itself)" group.
>>> To unsubscribe from this group and stop receiving emails from it, send an
>>> email to django-developers+unsubscr...@googlegroups.com.
>>> To post to this group, send email to django-developers@googlegroups.com.
>>> Visit this group at https://groups.google.com/group/django-developers.
>>> To view this discussion on the web visit
>>>
>>> https://groups.google.com/d/msgid/django-developers/576D6702.3080501%40oddbird.net
>>> .
>>> 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/CAK8PqJESDrr05-1jJeTbz8UQ%3D%2BJXYHU88w1iGBBnby5czwwVSA%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/msgid/django-developers/20160624172521.GF12981%40inel.local
> .
>
> For more options, visit https://groups.google.com/d/optout.
>



-- 


*Tobias McNulty*Chief Executive Officer

tob...@caktusgroup.com
www.caktusgroup.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 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/CAMGFDKQGyJPe%2BnNcsjusPZeMEquPGnobdhp_0pjxXEoJrWtqPQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: decorator_from_middleware changes

[Tobias McNulty]

On Tue, Jun 21, 2016 at 7:00 PM, Carl Meyer  wrote:

> Still halfway tempted to go with the original "make middleware authors
> responsible for this themselves, if they want to access
> response.content" approach.
>

I am curious to hear what others think, but I'm leaning this way too.
Having a permanent helper (perhaps MiddewareMixin as you suggested) for
dealing with TemplateResponses certainly sounds like a win, too.

Tobias
-- 


*Tobias McNulty*Chief Executive Officer

tob...@caktusgroup.com
www.caktusgroup.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 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/CAMGFDKTOoMmA-VdRUMcvgbJJr_q_xWHNoH7Su%2BTiHivsW%2B%2BVxw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: decorator_from_middleware changes

[Tobias McNulty]

On Mon, Jun 20, 2016 at 10:51 AM, Carl Meyer  wrote
> Possible disadvantages of this approach:



> 3. The new behavior may surprise some people accustomed to the old
> behavior, since it means the effect of the middleware decorator won't
> occur immediately where the decorator is applied. E.g. if you apply a
> middleware decorator to a view, and then another custom view decorator
> outside that, the custom view decorator won't see the effects of the
> middleware decorator in the actual response (it would only see a new
> entry in view_func._extra_middleware).

This one seems like the gotcha to me. What if, for example, I have a view
decorator whose effects I specifically don't want to cache, but I do want
to cache the underlying view; is it fair to require that the person write a
middleware and then turn it into a decorator to be able to do that? Are we
effectively saying, "for view decorators to behave the way you might
expect, implement them as middleware"? It seems odd, to me at least, that I
should care what the underlying implementation of a decorator is before I
use it. It also violates the 'strict in/out layering' goal, albeit for
decorators instead of middleware. (A similar argument could be said of
exceptions -- what if I want to trap an exception raised by a
middleware-turned-decorator?)

It might be okay if the decorators themselves were explicit about what they
were doing, for example @cache_page(3600) might become:

@add_middleware(CacheMiddleware, cache_timeout=3600)

However, that's probably a bigger and unnecessary change.

Would it be possible to implement a combination of the approaches, i.e.,
make the delay in applying the middleware-turned-decorator the exception
rather than the rule, perhaps only for TemplateResponses and specifically
for the purpose of supporting a deprecation plan? And then, long-term,
leave it up to middleware/decorator authors & users to decide how best to
implement/layer them, being explicit about the implications of rendering
the response or perhaps more appropriately, "not rendering if you can avoid
it" (i.e., your first strategy)?

Tobias
-- 

Tobias McNulty
Chief Executive Officer

tob...@caktusgroup.com
www.caktusgroup.com

Sent from my mobile.

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

Re: ERROR on document "request-response" , request.is_ajax()

[Tobias McNulty]

I think it's a fair point. The docs on HttpReqest.is_ajax() are
specifically discussing headers set from the client side, so I think
X-Requested-With would be more appropriate. This was discussed previously
and a more substantial change proposed:

https://groups.google.com/forum/#!searchin/django-developers/HTTP_X_REQUESTED_WITH/django-developers/Jvs3F79cY4Y/GW-S9GTYOKsJ

In fact, Collin Anderson submitted a proof of concept PR to this ticket
just ~2 days ago:

https://code.djangoproject.com/ticket/20147

Vignesh, I would follow this ticket and see if your concern could be
addressed through this implementation. If for whatever reason it doesn't go
through, you might consider filing a ticket
<https://docs.djangoproject.com/en/1.9/internals/contributing/bugs-and-features/>
and pull request (if the ticket is accepted) for a small improvement to the
documentation -- to change the header name referenced as you suggested
and/or point people to the section of the docs that talks about how headers
and META keys are different (
https://docs.djangoproject.com/en/1.9/ref/request-response/#django.http.HttpRequest.META
).

Cheers,
Tobias

On Mon, Jun 20, 2016 at 9:32 AM, Paulo Gabriel Poiati <
paulogpoi...@gmail.com> wrote:

> That is because the documentation is referring to the WSGI envrion
> dictionary (and thus the CGI spec). This is how the translation from the
> client to the server works: X-My-Header becomes HTTP_X_MY_HEADER. It isn't
> wrong IMO.
>
> On Sun, Jun 5, 2016 at 8:52 AM Vignesh Tnj  wrote:
>
>> https://docs.djangoproject.com/en/1.9/ref/request-response/
>>
>> " HttpRequest.is_ajax()[source]
>> <https://docs.djangoproject.com/en/1.9/_modules/django/http/request/#HttpRequest.is_ajax>
>> ¶
>> <https://docs.djangoproject.com/en/1.9/ref/request-response/#django.http.HttpRequest.is_ajax>
>>
>> Returns True if the request was made via an XMLHttpRequest, by checking
>> the HTTP_X_REQUESTED_WITH header for the string'XMLHttpRequest'. Most
>> modern JavaScript libraries send this header. If you write your own
>> XMLHttpRequest call (on the browser side), you’ll have to set this header
>> manually if you want is_ajax() to work. "
>>
>>
>> if we set ,  xhttp.setRequestHeader('HTTP_X_REQUESTED_WITH',
>> 'XMLHttpRequest'); as said in doc
>>
>> request.is_ajax()   return False
>>
>> ---
>>
>> if we set , http.setRequestHeader('X-Requested-With', 'XMLHttpRequest');
>>
>> request.is_ajax()   return true
>>
>> --
>> 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/7a88b8d8-b15f-4377-8264-e94130ad041e%40googlegroups.com
>> <https://groups.google.com/d/msgid/django-developers/7a88b8d8-b15f-4377-8264-e94130ad041e%40googlegroups.com?utm_medium=email&utm_source=footer>
>> .
>> For more options, visit https://groups.google.com/d/optout.
>>
> --
> *[]'s*
> *Paulo Poiati*
> blog.paulopoiati.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 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/CABqSV%3DJNiAPpR%3DW5kZa5-gm2Kmn%2BYJV2G1dxBoiBCGtJGN8-hQ%40mail.gmail.com
> <https://groups.google.com/d/msgid/django-developers/CABqSV%3DJNiAPpR%3DW5kZa5-gm2Kmn%2BYJV2G1dxBoiBCGtJGN8-hQ%40mail.gmail.com?utm_medium=email&utm_source=footer>
> .
>
> For more options, visit https://groups.google.com/d/optout.
>



-- 


*Tobias McNulty*Chief Executive Officer

tob...@caktusgroup.com
www.caktusgroup.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 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/CAMGFDKQ2eOxYW-21RZ%3Dfx%2BC%3DxWPm0gV9VByq49UHQVUxR-mNNQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Ticket #14019: SQLInsertCompiler.as_sql() failure

[Tobias McNulty]

Hi all,

I'm starting this thread in response to the recent closure as wontfix of Ticket
#14019 <https://code.djangoproject.com/ticket/14019>,
"SQLInsertCompiler.as_sql() failure"

The original summary in the ticket from mlavin goes as follows: "I came
across a problem with SQLInsertCompiler.as_sql function while trying to get
a stacktrace printed on insert errors (using
django-db-log<http://github.com/dcramer/django-db-log>).
I found that the as_sql function has an implicit condition that execute_sql
must be called first because execute_sql sets the return_id attribute."

The two proposed fixes either (a) check to make sure return_id exists
before accessing it, or (b) initialize return_id in __init__ so as to avoid
any implicit conditions that it's already set.

While as stated in the ticket this is not a public API, Django does
publicly support writing 3rd party database backends, and implicit
conditions like this make it difficult to develop and debug 3rd party
backends as well as other 3rd party database logging packages when
something goes wrong.  As kmtracey stated in the most recent comment, it
would be a big help to the larger Django community if methods like this did
not completely blow up when used incorrectly, but instead allowed a more
useful traceback to be raised by the actual offending code.

On a more general level, initializing attributes in __init__() is not a bad
practice, and ensuring that calling str() on an object doesn't raise an
exception is generally helpful too.  Given these issues, I wouldn't be
surprised if applying this fix also avoided similar issues during the
future development of Django itself.  Internal or not, "as_sql" is a
relatively common method, so making it at least somewhat resilient would be
helpful both for Django itself and the broader community of 3rd party apps
and backends.

Thanks in advance for considering re-opening this ticket.

Best,
Tobias
-- 
Tobias McNulty, Managing Member
Caktus Consulting Group, LLC
http://www.caktusgroup.com

-- 
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: Django sprint in North Carolina, Nov. 12-13, 2011

[Tobias McNulty]

Hi All -

Just a quick reminder that the Django sprint in NC is being held tomorrow
and Sunday here in Carrboro.  For more information:

https://code.djangoproject.com/wiki/Sprint20TriangleNC

Join us on IRC in the #django-sprint channel if you can't make it in
person.  We'll be on from about 9am to 3:30pm EST (UTC-5) each day and
Karen Tracey will be here for most of that time to help review and commit
our patches (thanks Karen!).  :-)

Cheers,
Tobias
-- 
Tobias McNulty, Managing Member
Caktus Consulting Group, LLC
http://www.caktusgroup.com

-- 
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: Django sprint in North Carolina, Nov. 12-13, 2011

[Tobias McNulty]

Hi all,

Just wanted to send out a quick reminder that we're hosting a Django sprint
here in Chapel Hill / Carrboro, NC next weekend (November 12th and 13th).
 All the details and related links are below.

If you're not local to Raleigh/Durham/Chapel Hill, you might consider
organizing a parallel sprint in your area.  The DSF and/or PSF can help
reimburse for sprint expenses.

Thanks and I hope to see you here or in the #django-sprint channel on
Freenode!

Cheers,
Tobias

On Tue, Oct 4, 2011 at 3:57 PM, Tobias McNulty wrote:

> Hi All,
>
> We'd like to host another Django sprint here at Caktus the weekend of
> November 12 and 13, 2011.  A development sprint is an excuse to get
> together, write some code, and have a good time doing it.  The purpose of
> this sprint will be to help finish features and push out bug fixes in
> preparation for the Django 1.4 release.  If you're interested in coming to
> work on other open source Django-based projects, that's welcome too.
>
> We'll be meeting at the Caktus Group office and we'll be here to open the
> doors at 9am both days.
>
> For more information, please check out the corresponding wiki page and
> RSVP via Eventbrite if you're interested:
>
> https://code.djangoproject.com/wiki/Sprint20TriangleNC
>
> http://nc-django-sprint-2011-11.eventbrite.com/
>
> If you you can't make it to NC but would like to participate online, you
> can RSVP by adding your name to the following page:
>
> https://code.djangoproject.com/wiki/Sprint20
>
> We're still looking for a few sponsors to help out with lunch and snacks,
> so check out the sponsors section of the wiki and add yourself (or your
> company) if you'd like to bring something.  Feel free to drop me an email
> off-list if you have any questions about sponsoring.
>
> Hope to see you there!
>
> Cheers,
> Tobias
> --
> Tobias McNulty, Managing Member
> Caktus Consulting Group, LLC
> http://www.caktusgroup.com
>
>


-- 
Tobias McNulty, Managing Member
Caktus Consulting Group, LLC
http://www.caktusgroup.com

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

Django sprint in North Carolina, Nov. 12-13, 2011

[Tobias McNulty]

Hi All,

We'd like to host another Django sprint here at Caktus the weekend of
November 12 and 13, 2011.  A development sprint is an excuse to get
together, write some code, and have a good time doing it.  The purpose of
this sprint will be to help finish features and push out bug fixes in
preparation for the Django 1.4 release.  If you're interested in coming to
work on other open source Django-based projects, that's welcome too.

We'll be meeting at the Caktus Group office and we'll be here to open the
doors at 9am both days.

For more information, please check out the corresponding wiki page and RSVP
via Eventbrite if you're interested:

https://code.djangoproject.com/wiki/Sprint20TriangleNC

http://nc-django-sprint-2011-11.eventbrite.com/

If you you can't make it to NC but would like to participate online, you can
RSVP by adding your name to the following page:

https://code.djangoproject.com/wiki/Sprint20

We're still looking for a few sponsors to help out with lunch and snacks, so
check out the sponsors section of the wiki and add yourself (or your
company) if you'd like to bring something.  Feel free to drop me an email
off-list if you have any questions about sponsoring.

Hope to see you there!

Cheers,
Tobias
-- 
Tobias McNulty, Managing Member
Caktus Consulting Group, LLC
http://www.caktusgroup.com

-- 
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: class based views: object instead of dictionary as context?

[Tobias McNulty]

On Mon, Sep 12, 2011 at 2:10 PM, Reinout van Rees wrote:

> On 12-09-11 18:25, Florian Apolloner wrote:
>
>> On Monday, September 12, 2011 5:39:03 PM UTC+2, Reinout van Rees wrote:
>>
>>Addition: disallow attributes/methods starting with an underscore?
>>
>>That's a handy way to stow away dangerous methods should you have them
>>in your view.
>>
>> That's already the case for resolving variables in templates, I don't
>> think we need any specialcasing here.
>>
>> > The only way I can see yourself shooting in the foot is
>>when you have a
>> > form view that reacts to get() and post(). Upon "get()",
>>the template
>>
>> > *could* call data-modifying methods on the class.
>>
>>
>> Not easily, since the templates can only call methods which don't
>> require extra params, get/post do take request at least.
>>
>
> I love it when problems solve themselves :-)


That's a good point.  Are there *any* methods in the CBVs that don't take
arguments, that also modify data?  The only one that I found in the list I'd
initially proposed that can be called without arguments is as_view(), and
I'm not sure that really even needs protection.  Maybe there's no need to
protect anything with alters_data / proxying?

That would certainly be the simplest, and would eliminate the possibility
that someone will later ask for us to expose a certain method or attribute
that we thought it best to hide now.

Tobias
-- 
Tobias McNulty, Managing Member
Caktus Consulting Group, LLC
http://www.caktusgroup.com

-- 
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: FloatField will not handle infinity values (Ticket #4287)

[Tobias McNulty]

On Wed, Apr 27, 2011 at 9:31 AM, Luke Plant  wrote:

>  ... If you need to store
> infinity in a database column, it's better to know sooner that your
> database doesn't support it so you can find one that does.
>

+1
-- 
Tobias McNulty, Managing Partner
Caktus Consulting Group, LLC
http://www.caktusgroup.com

-- 
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: RFC: new backports policy

[Tobias McNulty]

On Wed, Apr 20, 2011 at 3:56 PM, Paul McMillan  wrote:

> +1, I agree with Carl and Luke. The issue here is that for
> non-showstopper bugs, users have probably found (or may even be
> relying on!) the existing behavior. Keeping the "stable" branch more
> stable by only changing things when there's a serious issue seems to
> be a positive improvement.
>

Okay, I do think the regression issue makes a much stronger argument than
the developer time issue.

I'd be more comfortable if the policy stated that any new bugs introduced by
the last release would be backported to that release.  It's possible
that "major
functionality bugs in newly-introduced features" will equate to virtually the
same thing, but I'm not clear what would constitute a major functionality
bug (it sounds big, and like it might be a difficult criterion to meet).

On the other hand, if we've all been living with a trivial bug since 1.0, we
can probably live with it for just a little longer, and backporting
certainly doesn't sound worth the potential risk of a regression.

Cheers,
Tobias
-- 
Tobias McNulty, Managing Partner
Caktus Consulting Group, LLC
http://www.caktusgroup.com

-- 
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: RFC: new backports policy

[Tobias McNulty]

On Tue, Apr 19, 2011 at 3:22 PM, Jacob Kaplan-Moss wrote:

> Hi folks --
>
> Over the past few weeks, the core development team have been
> discussing how we can streamline our process to get more work done
> quicker. It's pretty clear that the bulk of the community wishes
> Django could move forward a bit faster [1], and we'd like to be able
> to deliver more awesomeness in less time. Ultimately, the goal will be
> to put out releases quicker, hit our deadlines more accurately, and be
> able to respond to community suggestions and patches in a more timely
> manner.
>
>[1] This isn't unique to Django, of course; almost every open
> source project wishes they could release more features more quickly.
>
> One way that we'd like to improve our speed is by modifying our
> existing backport policy. To refresh your memories, right now we
> backport any non-feature-containing patches to the previous release.
> So if we fix a bug on trunk, we backport the bug fix to the 1.3.X
> branch, where it would become part of the 1.3.1 release. This is a
> fair bit of work: it basically means we have to fix each bug twice.
>
> The core team has come to a rough consensus and we're planning to drop
> this backport-everything policy. Instead, we'll only backport critical
> patches. That is, we'd only backport patches for:
>
> * Security issues.
> * Data-loss bugs.
> * Crashing bugs.
> * Major functionality bugs in newly-introduced features.
>
> In other words, we'd basically only backport bugs that would have
> prevented a release in the first place.
>
> Practically, this means that if there's a minor bug in 1.3 -- for
> example, #15795, a bug with the representation of RegexURLPattern --
> the fix *will not* be applied to the 1.3.X branch, and thus no 1.3.*
> release will contain the fix, even if it's fixed in trunk. To get the
> fix for these bugs, users will have to upgrade to 1.4.
>
> The upside, of course, is that bug fixes will be quicker to apply, so
> we can fix more bugs, so we can get that 1.4 release out sooner [2].
> Additionally, this'll give users more of an incentive to upgrade to
> the latest-and-greatest. This means that they get new features, and we
> (the development community) get to focus more clearly on moving
> forward, not maintaining older releases.
>
>[2] Look for a proposed release date soon. Spoiler alert: it's
> sooner than you think.
>
> We'd like to make this change effective immediately, but we also don't
> want to just issue this change by fiat. So we're requesting comments
> and feedback on this change. Do you like the idea? Why or why not?
> Will this policy make it more likely you'll contribute? Less likely?
>
> Thanks!
>
> Jacob


Hi All -

In general I prefer to think about this the other way around: If we have a
most current stable release of product X, it makes sense to fix any bugs
that come up in that product.  For the sake of the next release, assuming
the bug was not fixed or made obsolete by some other change, it then also
makes sense to /forward port/ that bug fix to the current (unstable)
development trunk.  Calling it "forward porting" rather than "back porting"
makes it sound better, too. :-)

This workflow fits quite well if you're using one of the DVCS mirrors of the
Django repository, as it can be as easy as merging the latest release branch
into default/master on a regular basis.  There is obviously more to the
story (running tests, dealing with the occasional merge conflict), but to
me, it seems like the majority of the work is in fixing the original bug in
the first place, not in applying that same fix to another branch of the
code.  If my assumption is true, we might as well apply the fix in both
places once it has been made.

Being a non-core-committer perhaps I don't fully understand the additional
work involved, but I do appreciate the focus on stability in Django's
releases and I'd rather be forced to upgrade due to new features that I
want, rather than some silly bug that'll never be fixed -- especially if a
stable release that includes the fix I need is not even available yet.  In
other words, if a bug in a product has been fixed, it seems odd to me that
no stable release of the product will include that fix.

What if the window for bug fixes was time boxed, so that bug fixes would be
back/forward ported as usual up until 1-2 months prior to a new stable
release (perhaps coinciding with the first release candidate)?  This way at
least we have some semblance of a stable release destined to include all bug
fixes at all points in time, and the actual window in which a bug fix might
not make it into the current official stable release is reduced.

Just my 2 cents - hope

Re: Urgent Requirement: - Python Developer // 9 months // San Jose, CA

[Tobias McNulty]

Amit,

Please make job postings to the django-users mailing list.  The
django-developers list is for discussion related to the development of
Django itself.

Thank you.

Tobias

On Mon, Apr 11, 2011 at 3:27 PM, Amit Reks  wrote:

> Hi,
>
>
>
> Greetings!!!
>
>
>
> We have an opening for a *Python Developer* in San Jose, CA.
>
>
>
> We would highly appreciate it if you could recommend someone for it, in
> case you are not interested...
>
>
>
> Please find the job description below.
>
>
>
> *Job Title: Python Developer*
>
> *Job Location: San Jose, CA*
>
> *Duration: 9 months (Extendible)
> Position Type: Contract*
>
>
>
> *Job Description*
>
>  - Experience with Python
>
> -  Experience with Django
>
> If this project does not match your exact skills perhaps you know of
> someone with the necessary experience and availability; if so, please feel
> free to forward this e-mail at your discretion.
>
> If you are available and interested, please do send me a word copy of
> resume along with following details:
>
> IT Experience: in years
>
> Python:
>
> Django:
> Billing Hourly Rate__
> Earliest availability for the assignment :
> Earliest availability for the Interview :
> Current location :
> Preferred contact number :
>
> Best time to reach you:
>
> Work Authorization: Citizen/Green Card/EAD/H1b/TN Visa
>
>
>
> Thanks & Regards,
>
>
>
> *Amit |* Intelliswift Software Inc * |*
> 2201 Walnut Avenue, #180, Fremont, CA 94538*|* Phone: 510 870 8644  *|*
> Fax: 510-578-7710  *| *www.intelliswift.com
>
> --
> 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.
>



-- 
Tobias McNulty, Managing Partner
Caktus Consulting Group, LLC
http://www.caktusgroup.com

-- 
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: New messages API: regressions ?

[Tobias McNulty]

On Tue, Mar 29, 2011 at 11:08 AM, is_null  wrote:

> Greetings hackers,
>
> Django offered a feature to add messages to offline users, or to add
> messages to users in slots (if that's the pythonic name for "functions
> connected to signals"). It is still possible before 1.4, to call
> myuser.message_set.create() which doesn't need the request object.
>
> In 1.4, it will only be possible to add messages to online users and
> only in code which has the request object in its scope. That means:
>
> - no more adding messages to offline users
> - no more adding messages to users in slots
>
> A django hacker insisted that I should post on the list about this
> change, in case you were not aware about the consequences which might
> be seen as a regression.
>

Thanks for your message.  We are aware that this functionality is slated to
be removed.

It is not clear to me that the requirements for such functionality are
uniform across different applications.  It is my recommendation, at least,
that messages for users when the request object is not in scope are best
implemented in a 3rd party app.  If needed, integration with the
contrib.messages framework can be accomplished by implementing a custom
storage, similar to the following:

http://code.djangoproject.com/browser/django/trunk/django/contrib/messages/storage/user_messages.py

Cheers,
Tobias
-- 
Tobias McNulty, Managing Partner
Caktus Consulting Group, LLC
http://www.caktusgroup.com

-- 
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: Ticket #15124: BooleanField should not use False as default (unless provided)

[Tobias McNulty]

On Thu, Feb 3, 2011 at 1:22 PM, anb  wrote:

> On Feb 2, 3:08 pm, Chris Beaven  wrote:
> > On Friday, January 21, 2011 12:35:58 PM UTC+13, Karen Tracey wrote:
> >
> > > Rather, a BooleanField that raises an error on an attempt to save an
> > > instance that has no value set is what's being asked for. The quiet
> always
> > > defaulting to False does seem rather odd to me as well.
> >
> > The current behaviour still seems in-line with the behaviour a
> non-nullable
> > charfield (if not self.null, default to '').
> > So, for consistency should we also make a not-null charfield fail loudly
> if
> > instanciated without a value ? :P
>
> My argument for that is on the ticket. "It's ok for CharFields with
> blank=True to default to the empty string, because that's semantically
> the lack of a value for the field. However, True and False are equals;
> False is not the lack of a value."


Whoops, looks like I should have refreshed this thread before hitting send.
 :-)

Tobias
-- 
Tobias McNulty, Managing Partner
Caktus Consulting Group, LLC
http://www.caktusgroup.com

-- 
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: Ticket #15124: BooleanField should not use False as default (unless provided)

[Tobias McNulty]

On Wed, Feb 2, 2011 at 6:08 PM, Chris Beaven  wrote:

> On Friday, January 21, 2011 12:35:58 PM UTC+13, Karen Tracey wrote:
>>
>> Rather, a BooleanField that raises an error on an attempt to save an
>> instance that has no value set is what's being asked for. The quiet always
>> defaulting to False does seem rather odd to me as well.
>>
>
> The current behaviour still seems in-line with the behaviour a non-nullable
> charfield (if not self.null, default to '').
> So, for consistency should we also make a not-null charfield fail loudly if
> instanciated without a value ? :P
>

Really?  Django makes the case[1] that "" means "no data" for char and text
fields, as does None for integers, dates, and booleans.  As far as I can
tell, the behavior of all fields, except for BooleanField, is to default to
the empty value supported by that field.  Personally I see nothing wrong
with that (though I suppose a case could be made against the "" default for
CharFields, if someone wanted to).  On the other hand, False is in no way an
"empty value."  The flip side of the question is, given the current behavior
of BooleanFields, should we also make all not-null IntegerFields default to
0?

Tobias

[1] http://docs.djangoproject.com/en/dev/ref/models/fields/#null
-- 
Tobias McNulty, Managing Partner
Caktus Consulting Group, LLC
http://www.caktusgroup.com

-- 
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: ForeignKey with null=True

[Tobias McNulty]

On Dec 16, 2010 7:20 PM, "Christophe Pettus"  wrote:
>
>
> On Dec 16, 2010, at 2:31 PM, Luke Plant wrote:
> > That being so, there is a case for arguing that
> > ForeignRelatedObjectsDescriptor should not retrieve objects where the
> > field pointed to is NULL - for consistency with the inverse operation.
>
> I agree with this.  If the FK field is NULL, it should never return
related objects; ditto for the reverse situation.

+1

Tobias

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@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: contrib.staticfiles app concerns

[Tobias McNulty]

On Thu, Oct 21, 2010 at 11:58 AM, Jacob Kaplan-Moss wrote:

> On Thu, Oct 21, 2010 at 10:44 AM, Tobias McNulty 
> wrote:
> > I think the issue is that the commit has already been made, and that
> doesn't
> > feel like the right time to anyone to submit an alternate proposal.
>
> Well, that's why we use revision control: if there's a rough consensus
> that a commit was a mistake, we can revert it. I'm hearing a few
> voices in this thread that I *think* would like to see the change
> backed out -- though nobody's actually suggested that explicit yet, so
> I'm not sure. OTOH, I'm hearing a lot of "whoohoos" from users, so,
> yes, we couldn't just pull the rug out: we'd need something better to
> replace it with.
>
> > As far as constructive feedback goes, something I would like to see is
> > making "compilestatic" more configurable:
>
> Yes, indeed -- my main concern pre-commit was configurability, and the
> main focus of my code review was in making sure that we didn't do
> anything that precluded adding better more powerful features later. I
> didn't, however, want to hold off adding the feature waiting for some
> ill-defined set of improvements. I wanted to see a minimalistic
> addition that we can grow on later. That's how we roll.
>

I like that.


> I think realistically "later" likely means 1.4, but I'd happily review
> patches adding more hooks at every time.
>
> I really don't want staticfiles to be the tool that tries to do
> everything, though. The idea is to provide the lowest common set of
> functionality needed to handle media in reusable apps successfully,
> and then to let other more complicated features (compression, etc.)
> build on top of that. So yes: more hooks!
>
> > One might prefer to serve media
> > directly from the app static directories (via Aliases in apache or
> locations
> > in nginx), instead of copying it manually every time during a deployment.
>
> Hm, I certainly wouldn't... but it would be nice to make something
> like that possible, yes. BTW, you can right now run `collectstatic
> --links` to use symlinks instead of actually copying the files. Not
> quite the same thing, but close right now.
>

What's the argument against serving the original files directly?  Symlinks
are pretty horrible; I'd raise a bigger fit if that was the recommended
approach. ;-)


> > Another concern I have is about naming conflicts: how does staticfiles
> > address the case where multiple apps supply files with the same names?
>
> Just like templates: last one wins. See
> http://docs.djangoproject.com/en/dev/ref/contrib/staticfiles/#collectstatic
> ,
> and also see the `findstatic` command that you can use to debug which
> file shows up on which name.
>

Ah, so realistically we should put all our media in 'static/', like
for templates, if we want to avoid conflicts with other apps.  Would that be
worth mentioning as a convention in the docs so we don't end up with a bunch
of reusable apps that aren't at all reusable?

> This
> > is something that might also be addressed by being more configurable: I
> can
> > see the case where it'd make more sense to expose app-specific URLs for
> > media to the browser, instead of consolidating everything under a single
> > global namespace.  This could be implemented by a template tag, like so:
> > {% staticfile 'appname' 'path/to/file.png' %}
>
> I'm not quite sure I get the use case here, but like I said above: I
> would be thrilled to see patches making this more configurable now.


Adding something to the docs about avoiding name conflicts would make my
concerns about such conflicts (and the template tag suggested above)
obsolete.

Cheers,
Tobias
-- 
Tobias McNulty, Managing Partner
Caktus Consulting Group, LLC
http://www.caktusgroup.com

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@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: contrib.staticfiles app concerns

[Tobias McNulty]

On Thu, Oct 21, 2010 at 11:01 AM, Jacob Kaplan-Moss wrote:

> On Thu, Oct 21, 2010 at 8:19 AM, Tobias McNulty 
> wrote:
> > That thread's pretty old and doesn't really end on anything conclusive
> other
> > than "work has started".  I do see that the patch was updated numerous
> times
> > on the ticket [1] this month, but was there an associated review on the
> > mailing list?  Searching the group for "staticfiles" [2] or "12323" [3]
> > doesn't turn up much, but maybe I'm missing something.
>
> It looks like most of the review and discussion took place on the
> ticket tracker and on IRC. I'll take a mea culpa for that: I should
> have brought things back here.
>

No worries.  I certainly haven't been as involved as I could have been, so
it's quite likely I'd know more about what's going on if I'd been paying
more attention. :-)

I'd like to try again to actually move this forward: does anyone have
> an alternate proposal? I'm hearing a bit of complaining, but no
> alternate proposals.
>

I think the issue is that the commit has already been made, and that doesn't
feel like the right time to anyone to submit an alternate proposal.

That said, I'm not complaining, and I think having a standard way to bundle
static media with reusable apps is a Really Good Thing (tm).

As far as constructive feedback goes, something I would like to see is
making "compilestatic" more configurable: One might prefer to serve media
directly from the app static directories (via Aliases in apache or locations
in nginx), instead of copying it manually every time during a deployment.
 Some hooks that would let you generate a customized configuration, instead
of making copying the de facto standard implementation, would be great IMHO.

Another concern I have is about naming conflicts: how does staticfiles
address the case where multiple apps supply files with the same names?  This
is something that might also be addressed by being more configurable: I can
see the case where it'd make more sense to expose app-specific URLs for
media to the browser, instead of consolidating everything under a single
global namespace.  This could be implemented by a template tag, like so:

{% staticfile 'appname' 'path/to/file.png' %}

Just my two cents.

Cheers,
Tobias
-- 
Tobias McNulty, Managing Partner
Caktus Consulting Group, LLC
http://www.caktusgroup.com

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@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: contrib.staticfiles app concerns

[Tobias McNulty]

On Thu, Oct 21, 2010 at 8:54 AM, Dougal Matthews  wrote:

> On 21 October 2010 13:41, Tobias McNulty  wrote:
>
>>  is there another mailing list thread or wiki page somewhere that follows
>> or summarizes the decisions that went into django.contrib.staticfiles?  I
>> think pointing to the fact that such a process has already happened would
>> also resolve a lot of the concerns in this thread.
>>
>
> I think you are looking for this;
>
> http://groups.google.co.uk/group/django-developers/browse_thread/thread/b333c14f40acd22a/288a34cc41bb4395
>
> I'm not sure if its documented or summarised anywhere.
>

That thread's pretty old and doesn't really end on anything conclusive other
than "work has started".  I do see that the patch was updated numerous times
on the ticket [1] this month, but was there an associated review on the
mailing list?  Searching the group for "staticfiles" [2] or "12323" [3]
doesn't turn up much, but maybe I'm missing something.

Thanks, just trying to come up to speed.

Tobias

[1] http://code.djangoproject.com/ticket/12323
[2]
http://groups.google.com/group/django-developers/search?group=django-developers&q=staticfiles
 <http://code.djangoproject.com/ticket/12323>[3]
http://groups.google.com/group/django-developers/search?group=django-developers&q=12323

-- 
Tobias McNulty, Managing Partner
Caktus Consulting Group, LLC
http://www.caktusgroup.com

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@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: contrib.staticfiles app concerns

[Tobias McNulty]

On Thu, Oct 21, 2010 at 5:27 AM, James Bennett wrote:

> In the future, it may well turn out that people will commonly need
> much more than what the current iteration of staticfiles provides. But
> we can't cross that bridge until we come to it; for now, staticfiles
> solves the common version of the problem (let's face it: *very* few
> people are doing CDNs or offline HTML5 apps or any of the other stuff
> brought up in this thread, as compared to gathering a bunch of files
> and serving them up).
>

For the sake of posterity (including me since I seem to be arriving rather
late to the game), is there another mailing list thread or wiki page
somewhere that follows or summarizes the decisions that went into
django.contrib.staticfiles?  I think pointing to the fact that such a
process has already happened would also resolve a lot of the concerns in
this thread.

Thanks,
Tobias
-- 
Tobias McNulty, Managing Partner
Caktus Consulting Group, LLC
http://www.caktusgroup.com

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@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: #6735 -- Class based generic views: call for comment

[Tobias McNulty]

On Fri, Oct 1, 2010 at 9:55 AM, Alex Gaynor  wrote:

> On Fri, Oct 1, 2010 at 9:53 AM, Vinay Sajip 
> wrote:
> > It seems better to stress thread-safety dos and don'ts in the
> > documentation.
>
> Without wanting to beat a dead horse, I concur.  Fundamentally we need
> to have a little faith in your users, the admin has the exact same
> pattern of a single instance, and we haven't done anything special
> there.
>

+1

The thread safety issues certainly aren't insignificant, but I think they
can be solved by a big fat warning in the documentation.  I do prefer this
to the potentially false sense of security that copying the object may
involve.

Tobias
-- 
Tobias McNulty, Managing Partner
Caktus Consulting Group, LLC
http://www.caktusgroup.com

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@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: making queryset.delete issue only a single SQL query

[Tobias McNulty]

On Sun, Sep 19, 2010 at 11:41 AM, Alex Gaynor  wrote:

> On Sun, Sep 19, 2010 at 10:28 AM, drakkan  wrote:
> > in my opinion django should emulate "ON DELETE CASCADE" only on
> > database backends that doesn't support it, if you are using a database
> > such as postgres delete() on a queryset should issue a single sql
> > query and should be the database to care about the cascade/set null
> > etc.. behaviour
> >
> > http://code.djangoproject.com/ticket/7539
> >
> > I think this way django could archive the best performance,
> >
> > if one need to delete a lot of row and there are relations to other
> > tables a single raw SQL query is not enough, you need to modify the
> > database schema too to ensure the correct cascade behaviuor or you
> > need to issue an sql query for every related table
>
>
> We also support cascading generic relationships, which no database
> supports.
>

And currently the pre- and post-delete signals are called for each object,
even in a bulk delete, so changing that would be a backwards-incompatible
change.  I don't much like that it does this, but changing it would still
undoubtedly cause trouble for some people.

That said, queryset.update() does NOT iterate through all the objects in a
queryset and call save(), and nor does it call the pre- and post-save
signals. [1]

We have two bulk operations that behave differently; would it be worthwhile,
at least, to make the behavior configurable?

Tobias

[1]
http://docs.djangoproject.com/en/dev/topics/db/queries/#updating-multiple-objects-at-once
-- 
Tobias McNulty, Managing Partner
Caktus Consulting Group, LLC
http://www.caktusgroup.com

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@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: making queryset.delete issue only a single SQL query

[Tobias McNulty]

On Fri, Sep 17, 2010 at 8:27 AM, SmileyChris  wrote:
>
>  On Sep 11, 1:12 pm, Tobias McNulty  wrote:
> > I may be missing something, but queryset.delete() seems oddly implemented
> in
> > Django.  It does a select to get all the IDs to be deleted, and then
> deletes
> > them, in blocks of 100 I believe, by ID.
>
> It's because .delete() is emulating the behavior of the SQL constraint
> ON DELETE CASCADE
>
> A list of objects to be deleted is recursively populated, then this
> complete list of objects is iteratively deleted (also calling the
> pre_delete and post_delete signals in their respective places).


Hm, I see that now, and I suppose there's no sense in changing that
behavior.

To my credit, the docs are a little misleading, specifically the line
reading "Keep in mind that this will, whenever possible, be executed purely
in SQL, and so the delete() methods of individual object instances will not
necessarily be called during the process." [1]  Additionally, is ambiguous
whether the part about "ON DELETE CASCADE" applies just to single objection
deletion or to queryset deletion as well.  Admittedly what it says is not
wrong, but it does /suggest/ that delete() on a queryset doesn't do anything
per-object, which is not true at all.

Perhaps I'll work on clarifying the docs and adding a warning that Django's
delete() on a queryset will chunk the actual deletions--in addition to
calling signals and deleting related objects one by one--so raw SQL should
be used instead if one needs to delete a lot of rows and efficiency is a
concern?  Does that seem reasonable?

Tobias

[1] http://docs.djangoproject.com/en/dev/topics/db/queries/#deleting-objects
-- 
Tobias McNulty, Managing Partner
Caktus Consulting Group, LLC
http://www.caktusgroup.com

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@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: CI server - IRC bot

[Tobias McNulty]

On Sun, Sep 12, 2010 at 11:55 PM, Tobias McNulty wrote:

> At the DjangoCon sprint this weekend I setup Django on our CI server for
> OSS and had it reporting on builds in the #django-sprint IRC channel.  Would
> that be useful to continue post-sprint, and should I have it report to the
> #django-dev channel as well?
>

I got an unsolicited +1 from Carl and Alex in IRC and lazy consensus is good
enough for me...so I'll go ahead and add it.  Feel free to object if it gets
out of hand.

Cheers,
Tobias
-- 
Tobias McNulty, Managing Partner
Caktus Consulting Group, LLC
http://www.caktusgroup.com

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@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.

CI server - IRC bot

[Tobias McNulty]

Hey all,

At the DjangoCon sprint this weekend I setup Django on our CI server for OSS
and had it reporting on builds in the #django-sprint IRC channel.  Would
that be useful to continue post-sprint, and should I have it report to the
#django-dev channel as well?

Cheers,
Tobias
-- 
Tobias McNulty, Managing Partner
Caktus Consulting Group, LLC
http://www.caktusgroup.com

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@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.

making queryset.delete issue only a single SQL query

[Tobias McNulty]

Hi All,

I may be missing something, but queryset.delete() seems oddly implemented in
Django.  It does a select to get all the IDs to be deleted, and then deletes
them, in blocks of 100 I believe, by ID.  Is there a reason it needs to do
this and/or is it overly complex to implement as a single query?  Issuing
multiple queries when you're trying to delete millions of rows can be very
expensive when done like this.

There's a ticket open about this, marked "Design decision needed":

http://code.djangoproject.com/ticket/9519

Does this seem like a valid change to others out there?  Should I move it to
"Accepted" and proceed with trying to fix it (though it may be harder than I
think)?

Thanks,
Tobias
-- 
Tobias McNulty, Managing Partner
Caktus Consulting Group, LLC
http://www.caktusgroup.com

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@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: #9459 forms.DateTimeField() looses microseconds

[Tobias McNulty]

On Thu, Sep 9, 2010 at 5:43 AM, Thomas Guettler  wrote:

> Here is the patch:
>
> http://code.djangoproject.com/attachment/ticket/9459/datetime-microseconds-py25.patch
>
> If the python version is greater-equal than 2.6, it uses %f to parse the
> microseconds,
> for older versions it parses the last integer itself.
>

The patch looks reasonable enough to me and I'm excited about getting it in.
 Have you tested it on Python 2.4, 2.5, and 2.6?

Cheers,
Tobias
-- 
Tobias McNulty, Managing Partner
Caktus Consulting Group, LLC
http://www.caktusgroup.com

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@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: Any interest in adding a navigation helper to Django?

[Tobias McNulty]

On Sat, Aug 28, 2010 at 12:32 AM, Yo-Yo Ma  wrote:

> I think the thing that would be helpful to most django users is bit
> really a navigation helper per se. I think what I need could be solved
> with a more generic tool. Russell, tell me what you think about
> providing a way to make a view a "child" of another. I'm not speaking
> in the CMS sense (e.g. /accessories/hair/brushes/) as this is very
> proprietary and can be aconploshed using a number of different
> algorithms (Django TreeBeard for example). I'm speaking in terms of
> software views. (e.g. /configuration/settings/billing/), etc. I want
> to have a way to know that I should show "settings" tabs when I'm at /
> configuration/, and without having to create 2 new templates (one for
> list and one for forms) for "configuration" that just overrides the
> menu. This works until you have a lot of views and then it gets to the
> point where you have 50 templates just for menus. Imagine a theme
> update with that.  What's your thoughts on that?


django-treenav[1] accomplishes what you're looking for without proliferating
a huge mess of templates and lives a perfectly happy life outside the django
core.

Tobias

[1] http://code.google.com/p/django-treenav/
-- 
Tobias McNulty, Managing Partner
Caktus Consulting Group, LLC
http://www.caktusgroup.com

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@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: Any interest in adding a navigation helper to Django?

[Tobias McNulty]

On Thu, Aug 26, 2010 at 8:59 PM, Russell Keith-Magee <
russ...@keith-magee.com> wrote:
>
> Navigation menus strike me as something that:
>  * Can live happily outside the core - it doesn't need to integrate
> closely with any part of the Django stack.
>
>  * Isn't a problem that everyone has.
>
>  * Even if it is a common problem, is something where there are many
> possible ways to solve the problem
>

+1 leaving navigation outside the core.

Tobias
-- 
Tobias McNulty, Managing Partner
Caktus Consulting Group, LLC
http://www.caktusgroup.com

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@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: pre-object permission

[Tobias McNulty]

Andu,

I could be mistaken, but this looks like a question better asked on the
django-users list.  django-developers is for discussion related to the
development of Django itself.

Cheers,
Tobias

On Wed, Aug 18, 2010 at 2:50 AM, andu  wrote:

> Hello!
>
> I am developing some web-application. The application is expected to
> store data which is reported from different location. And the data
> needs to be accessible to different web administrators (in different
> location). In this case I want to display reported data to each
> administrator based on his location.
>
> I have tried to override the queryset(self, request) method in the
> admin.py file. i.e
>
>
> class ReporterAdmin(admin.ModelAdmin):
>list_display = ('first_name', 'last_name', 'alias', )
>search_fields = ('^first_name', '^last_name', '^alias')
>form = ReporterAdmin
>
>def queryset(self, request):
>qs = super(ReporterAdmin, self).queryset(request)
>webuser = WebUser.by_user(request.user)
>webuser_location = webuser.location
>child_locations =
> webuser_location.descendants(include_self = True)
>return qs.filter(location__in = child_locations)
>
> The above code works well (I have also applied the same thing for
> other models). But when I open the form, foreign key fields still get
> the whole data instead of filtering based on the web-users location. I
> can't event have request object as a parameter in forms.py file.
>
> Some my question is:
>1. Can I program the required feature in Django? i.e. Filter the
> data based on location in the change list, edit form and also in the
> filter list (which appears to the right side of change list view of
> admin page)
>
>2. Is there any other means?
>
> Please help me
>
> Thank you in advance
>
> Andu
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django developers" group.
> To post to this group, send email to django-develop...@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.
>
>


-- 
Tobias McNulty
Caktus Consulting Group, LLC
P.O. Box 1454
Carrboro, NC 27510
USA: +1 (919) 951-0052
http://www.caktusgroup.com

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@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: dev process [was: #11834: colorized debug page]

[Tobias McNulty]

On Mon, Aug 16, 2010 at 12:23 AM, Russell Keith-Magee <
russ...@keith-magee.com> wrote:
>
> My apologies -- I haven't watched the video for a while, so I forgot
> that detail. I'm not sure adopting that policy would help Django,
> though; we have enough of a bottleneck with committers without
> exacerbating the problem.


Sure, I just happened to be watching it right then, so I thought I'd put it
in textual form where people can see it without spending 30 minutes listing
to the talk. :-)

I'm certainly not arguing that we should adopt such a policy, but it is a
neat idea.  Like you've been saying, Django trunk does a pretty good job of
staying stable as it is and things seem to get fairly well tested on an
ongoing basis, so I'm not sure it's an issue.

Tobias
-- 
Tobias McNulty
Caktus Consulting Group, LLC
P.O. Box 1454
Carrboro, NC 27510
USA: +1 (919) 951-0052
http://www.caktusgroup.com

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@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.