content-sensitive Sphinx markup in django docs - still needed?

[Tim Graham]

Hi,

I've worked on a few patches (and noticed some others) [#9502, #11782,
#11800] to the documentation to add content-sensitive Sphinx markup to
improve the structure of the docs, however, in #11800 Alex commented
that "Jacob has been working on/did a patch for Sphinx that allowed
any literals to automatically become cross references, so this may be
unnecessary".  Just wondering if anyone could provide an update on
this as I'd like to spend my time as helpfully as possible and avoid
things that ultimately won't need to be done.  Presumably the longer
these types of patches sit, the more stale they will become since
documentation that's added in the meantime will use the old style
links, however, I understand if the core devs have more important
things to address.

Thanks,
Tim

--

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: PASSWORD_HASHERS Check

[Tim Graham]

For context, Francisco proposed this at 
https://code.djangoproject.com/ticket/33793 which was marked wontfix by Mariusz 
with the comment: 

>  Django keeps "weak" password hashers for support with legacy systems and 
​speeding up the tests 
.
 
Moreover they are not enabled by ​default 
, 
so you must add them explicitly to the PASSWORD_HASHERS. Folks that do this 
should be aware of their weakness. IMO there is not need for a new system 
check.

Francisco, have you seen this mistake made? It doesn't seem very likely to 
me. Typically, the setting is customized in a test settings file; thus, I 
don't see how this could propagate to a production environment.

On Tuesday, June 21, 2022 at 11:18:04 AM UTC-4 Francisco wrote:

> I think it would be a good idea to add a check for insecure hashers on 
> PASSWORD_HASHERS[0], 
> I know the insecure ones are not enabled by default, but I think it would 
> be useful to warn users that have enabled them that it's a bad idea.
>
> They could have enabled them on production while thinking they only 
> enabled them for testing for example.
>

-- 
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/4632834e-7864-48a9-947b-61aa0ccb11d6n%40googlegroups.com.

Re: PASSWORD_HASHERS Check

[Tim Graham]

On Friday, June 24, 2022 at 10:14:48 PM UTC-4 Francisco wrote:

> Here is a real-world example I found on a quick search: 
> https://github.com/dimagi/commcare-hq/blob/6be7be39cb3f554670685e811a15720d46cc4a2d/settings.py#L192
>

In this case, it appears that making SHA1 the default hasher wasn't 
accidental: 
https://github.com/dimagi/commcare-hq/commit/afa8f603bf1d2f3c335aba6ed8a16d46a2740f8b.
 
It's unknown whether adding a system check would cause this project to make 
a change or if there's an ongoing reason that they're using that hasher (in 
which case a warning would only be an annoyance to suppress with 
SILENCED_SYSTEM_CHECKS).

All things considered, I agree with Mariusz that this is probably not a big 
problem in the Django ecosystem that justifies adding more code.

On Fri, Jun 24, 2022 at 11:00 PM Francisco Couzo  
> wrote:
>
>> If you happen to be using pytest and want to detect if you're testing, 
>> there's a really bad recommendation on this ticket: 
>> https://github.com/pytest-dev/pytest-django/issues/333, now that alone 
>> works, but if you were to import pytest, you would be running some test 
>> settings and be none the wiser.
>>
>> Also I think it's a good practice, you could have modified 
>> PASSWORD_HASHERS years ago, and the hasher that was once secure is not any 
>> more.
>>
>> On Tue, Jun 21, 2022 at 12:31 PM Tim Graham  wrote:
>>
>>> For context, Francisco proposed this at 
>>> https://code.djangoproject.com/ticket/33793 which was marked wontfix by 
>>> Mariusz 
>>> with the comment: 
>>>
>>> >  Django keeps "weak" password hashers for support with legacy systems 
>>> and ​speeding up the tests 
>>> <https://docs.djangoproject.com/en/stable/topics/testing/overview/#password-hashing>.
>>>  
>>> Moreover they are not enabled by ​default 
>>> <https://docs.djangoproject.com/en/stable/ref/settings/#password-hashers>, 
>>> so you must add them explicitly to the PASSWORD_HASHERS. Folks that do 
>>> this should be aware of their weakness. IMO there is not need for a new 
>>> system check.
>>>
>>> Francisco, have you seen this mistake made? It doesn't seem very likely 
>>> to me. Typically, the setting is customized in a test settings file; thus, 
>>> I don't see how this could propagate to a production environment.
>>>
>>> On Tuesday, June 21, 2022 at 11:18:04 AM UTC-4 Francisco wrote:
>>>
>>>> I think it would be a good idea to add a check for insecure hashers on 
>>>> PASSWORD_HASHERS[0], 
>>>> I know the insecure ones are not enabled by default, but I think it would 
>>>> be useful to warn users that have enabled them that it's a bad idea.
>>>>
>>>> They could have enabled them on production while thinking they only 
>>>> enabled them for testing for example.
>>>>
>>> -- 
>>> You received this message because you are subscribed to a topic in the 
>>> Google Groups "Django developers (Contributions to Django itself)" group.
>>> To unsubscribe from this topic, visit 
>>> https://groups.google.com/d/topic/django-developers/CBdwSCiDKwY/unsubscribe
>>> .
>>> To unsubscribe from this group and all its topics, send an email to 
>>> django-develop...@googlegroups.com.
>>> To view this discussion on the web visit 
>>> https://groups.google.com/d/msgid/django-developers/4632834e-7864-48a9-947b-61aa0ccb11d6n%40googlegroups.com
>>>  
>>> <https://groups.google.com/d/msgid/django-developers/4632834e-7864-48a9-947b-61aa0ccb11d6n%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/44096686-0b13-4e5c-8152-3fc560a385c5n%40googlegroups.com.

Re: Model-level validation

[Tim Graham]

> Among the dozen of Django applications I have worked on, at 3 companies, 
not a single one was actually running any kind of validation. It has always 
been a mistake, 100% of the time, *never* the desired behavior.

Besides not taking time to understand how Django works, it seems they 
weren't doing any manual testing or writing tests for invalid data either, 
so for me, this doesn't add much weight to the argument.

> I was able to find was that it was for "performance reasons", and I 
refuse to believe that a mature web framework like Django would prioritize 
performance (let's face it - even my millions-of-requests-per-day API 
service doesn't care about a few extra milliseconds here and there) over 
the most basic data safety concerns by default. 

I'm not sure it's correct to dismiss performance considerations, 
particularly when Model.full_clean() could add database queries for 
validating unique or other constraints. I believe doing validation 
redundantly (e.g. with form validation) or unnecessarily (e.g. bulk loading 
good data) would add undesired overhead. I think that forcing the entire 
Django ecosystem to opt out of automatic model validation as needed would 
be a heavy requirement to impose at this point. And apparently it was 
considered too heavy a requirement to impose when model validation was 
added in Django 1.2, released May 2010. 

I would try to keep an open mind to a concrete proposal, but I'm skeptical 
and it's surely non-trivial.
On Friday, September 30, 2022 at 7:53:24 PM UTC-4 aa...@aaronsmith.co wrote:

> If `ModelForm` were truly where validation logic lived, django would not 
> even use foreign keys. All constraints would be handled at the Form layer. 
> But we do use FKs, and also do other database-level consistency and 
> validity features, because data objects should understand and enforce their 
> own constraints. So what we have now is some types of validation happen 
> below Model, and some live above in the Form. This means that the data 
> store is not a single thing that's implemented with a simple interface, it 
> is a network of things which in inherently more difficult to work with, 
> understand, and maintain.
>
> If Forms were truly the validation layer, why am I able to specify things 
> like maximum length and allowed choices on the Model? Shouldn't those 
> things be specified at the Form layer?
> On Friday, September 30, 2022 at 4:27:13 PM UTC-7 Aaron Smith wrote:
>
>> Jorg,
>>
>> I do not believe it violates any separation of concerns. `full_clean()` 
>> is already a method on the Model class itself. The Model is already where 
>> all validation logic lives, except for the actual *triggering* of the 
>> validation.
>>
>> What I believe violates separation of concerns is that models do not run 
>> something which is already internal to itself, i.e. they are not actually 
>> fully functional as a data store layer, unless an external thing 
>> (ModelForm) is implemented. That feels wrong to me.
>> On Friday, September 30, 2022 at 2:19:35 PM UTC-7 
>> j.bre...@netzkolchose.de wrote:
>>
>>> @Aaron 
>>>
>>> Oh well, if anecdotal personal evidence counts for you - here is mine: 
>>>
>>> Working here since 2008 with Django in tons of projects in different 
>>> positions. The project sizes were from small websites to big API-driven 
>>> SPA cluster installations (with and w'o DRF). Ofc it is not all rainbows 
>>> and ponies with Django, but python-side data validation never crossed my 
>>> way as seriously flawed in Django. NOT EVEN ONCE. (Could list at least 
>>> 5-7 other topics that are somewhat tedious to get done with Django, but 
>>> thats offtopic here.) 
>>>
>>> Plz dont jump from personal frustration about poor development processes 
>>> you have observed to all-conclusions, that depict most Django users as 
>>> total noobs. (Still funny to read, as it reminded me on those flaming 
>>> wars between Perl and Python folks ~18ys ago, which abruptly ended when 
>>> Perl6 finally made its debut.) 
>>>
>>> > The question is not whether you /can/ compose validation into django 
>>> > models. The concern is that it should be done /by default/ to protect 
>>> > the average naive newbie developer from mistakes. 
>>>
>>> I'm sorry if I didn't answer that more directly for you - nope, imho it 
>>> should not be done by default on `Model.save`. It violates the path in 
>>> separation of concerns Django has chosen with form validation, thus the 
>>> -1 from my side. 
>>>
>>>
>>> Regards, 
>>> Jörg 
>>>
>>

-- 
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/2331d0d6-a890-42dc-8c6d-c627e540f0ean%40googlegroups.com.

Re: `call_command` raises ValueError during testing

[Tim Graham]

Hi Ferran,

It looks like opt.option_strings is empty because "poll_ids" (in 
parser.add_argument()) isn't prefixed with a dash or double dash. 

You could instead use call_command() like this: call_command("closepoll", 1)

But I think your invocation could be fixed (or at least not fail so 
obscurely).
On Sunday, October 2, 2022 at 7:49:26 AM UTC-4 Ferran Jovell wrote:

> Hello everyone,
>
> I was working on a admin command today, and when setting up tests and 
> fixtures for running the command during testing I found this error:
>
> Traceback (most recent call last):
>   File "/home/fjm/code/django-stuff/tutorial/polls/tests.py", line 10, in 
> test_command_output
> call_command("closepoll", poll_ids=1, stdout=out)
>   File 
> "/home/fjm/.local/share/virtualenvs/tutorial/lib/python3.10/site-packages/django/core/management/__init__.py",
>  
> line 168, in call_command
> parse_args.append(min(opt.option_strings), default=0)
> ValueError: min() arg is an empty sequence
>
> However, what is weird is that when run from with the manage.py script, 
> everything seems to be working just fine.
>
> This is the command code
>
> from django.core.management.base import BaseCommand
>
>
> class Command(BaseCommand):
> def add_arguments(self, parser):
> parser.add_argument("poll_ids", nargs="+", type=int)
>
> def handle(self, *args, **options):
> pass
>
> And this is the test code:
> from io import StringIO
>
> from django.core.management import call_command
> from django.test import SimpleTestCase
>
>
> class ClosepollTest(SimpleTestCase):
> def test_command_output(self):
> out = StringIO()
> call_command("closepoll", poll_ids=1, stdout=out)
> self.assertIn("Expected output", out.getvalue())
>
> I set up a repo with the minimal code to reproduce this:
> https://github.com/mrswats/django-polls-test
> Is this a bug? Am I doing something wrong? Have I missed anything?
>
> I checked the bug tracker but could not find anything related to this and 
> before opening an issue I figured I'd ask. If it is indeed a bug I will 
> happily write a ticket in the tracker.
>
> Thanks in advance.
>
>

-- 
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/da3b35c5-eaed-49e8-9b61-eec4b3fc4736n%40googlegroups.com.

Re: Backport for ticket 34063?

[Tim Graham]

As perfectionists, it's always hard to say (and hear) "no" when this sort 
of request comes up. I'm unconvinced it's a serious issue that requires a 
break from normal policy. (Unreported for 2 years in 4 major releases; 
simple workaround present.)

Incidentally, escalating an issue to the steering council after less than 
24 hours (during a holiday week, no less) probably isn't something we want 
to model as a best practice in forming consensus.
On Friday, December 30, 2022 at 12:48:47 PM UTC-5 James Bennett wrote:

> I have put it to the Steering Council:
>
>
> https://forum.djangoproject.com/t/request-for-technical-board-steering-council-vote-requested-backport-ticket-34063/17920/1
>

-- 
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/7ef540fb-939f-4afa-9e05-33f988f6b0b0n%40googlegroups.com.

Re: Backport for ticket 34063?

[Tim Graham]

Older Django releases are currently maintained with minimal support that 
allows existing projects to continue running securely. I don't think we 
should invest resources in promoting them as a place to use experimental 
features. A benefit of running an old LTS release like 3.2 is that any 
release at this point is probably a very important upgrade (security or 
data loss issue). If we start making new LTS bug fix releases to fix 
experimental features, releases may be more frequent and less important. Of 
course, with more changes, the risk of unrelated regressions increases, 
including the possible bad situation in which users put off a bug fix 
upgrade because it doesn't have any security fixes only to face issues 
updating to a subsequent security release because of an issue in an interim 
bug fix release. (Maybe mergers can estimate how many other async fixes 
would be eligible for a backport based on the proposed criteria.)

James argues that this bug that went unreported for 2+ years is now very 
important and is going to cause massive pain for many users. Only time will 
answer this, but I'm skeptical. So far I believe we've seen two people 
affected, James and the ticket reporter.

This bug will be a non-issue for third-party apps with the release of 
Django 5.0 in December if they follow the suggested Django version support 
policy:

"Following the release of Django 5.0, we suggest that third-party app 
authors drop support for all versions of Django prior to 4.2. At that time, 
you should be able to run your package’s tests using python -Wd so that 
deprecation warnings appear. After making the deprecation warning fixes, 
your app should be compatible with Django 5.0."

Until then, apps could run the affected tests only on Django 4.2 (which 
will have an alpha release in about two weeks) if they don't want to work 
around the bug.
On Sunday, January 1, 2023 at 10:21:48 AM UTC-5 Shai Berger wrote:

> Hi,
>
> I think at this point it would help to move the discussion forward, if
> we tried to step beyond the specific issue and phrase the revision in
> the backporting policy. This will let us, I hope, have a more
> principle-based discussion.
>
> If I get it right -- please correct me, James -- it would be something
> like this addition:
>
> "In a new domain of functionality, which is considered major and
> central, bugs which would have been release blockers if found in time
> will be considered as candidates for backporting if found within the
> next two LTS versions" -- or even "... if found before use of the new
> domain of functionality becomes mainstream" -- or something similar.
>
> I think looking at it from that angle will be more fruitful. I will say
> that looking at this principle, thinking about the vicious cycle
> mentioned by James, I tend towards accepting his arguments.
>
> We may want to phrase it a different way: Think of such major domains
> as "experimental". We did that in the Python3 transition -- we had
> "experimental support" from 1.5, and IIRC that "experimental" label
> wasn't dropped until 1.8. I doubt we can retroactively declare async
> views as still experimental, but we can modify the backporting policy
> to say "release-blocker-level bugs in experimental features will be
> candidates for backporting as long as the feature is experimental";
> and we can set an exception that says "async is still experimental for
> backporting considerations", in view of the little use we've seen so
> far.
>
> (I can see the argument against the last proposition, that says
> "experimental means potentially broken, so it should be less worthy of
> backports rather than more"; I disagree, because (a) we do want to
> encourage such experimentation, and (b) no, it doesn't really mean
> potentially broken, it means the API is not yet covered by the
> stability guarantees; we're at more liberty to change things when we
> fix)
>
> HTH,
> Shai.
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/35bad7b0-1811-4a1e-a396-bd8e6591699fn%40googlegroups.com.

Re: Backport for ticket 34063?

[Tim Graham]

I guess it's nice to have a strict backport policy, partly to avoid hours 
of discussion like this, which ultimately boils down to a 
judgment/prediction about severity and whether or not the current backport 
policy should be amended. If I encountered a similar issue, I would have 
just worked around it and moved on. Surely there are other issues like this 
one that don't meet the current backport criteria but that could be 
similarly argued by someone persistent enough. It would be nice if the 
outcome here avoided that in the future.

I guess there's not much to add on either side of the argument at this 
point. Perhaps the best solution is what Shai outlined: to propose amending 
the backport criteria, either by expanding the LTS backport categories 
beyond security and data loss issues, or by allowing the steering council 
to vote on backport proposals on a case-by-case basis, at least if there's 
no consensus on the mailing list.
On Sunday, January 1, 2023 at 5:41:03 PM UTC-5 James Bennett wrote:

> On Sun, Jan 1, 2023 at 12:54 PM Tim Graham  wrote:
> > Older Django releases are currently maintained with minimal support that 
> allows existing projects to continue running securely. I don't think we 
> should invest resources in promoting them as a place to use experimental 
> features. A benefit of running an old LTS release like 3.2 is that any 
> release at this point is probably a very important upgrade (security or 
> data loss issue). If we start making new LTS bug fix releases to fix 
> experimental features, releases may be more frequent and less important. Of 
> course, with more changes, the risk of unrelated regressions increases, 
> including the possible bad situation in which users put off a bug fix 
> upgrade because it doesn't have any security fixes only to face issues 
> updating to a subsequent security release because of an issue in an interim 
> bug fix release. (Maybe mergers can estimate how many other async fixes 
> would be eligible for a backport based on the proposed criteria.)
>
> The backport policy already says that Django will backport certain
> things into older releases. I do not agree with your assessment of the
> risk of backporting, but even if we grant it for sake of argument, the
> Django project overall has already clearly endorsed -- through the
> current backport policy -- the idea that some fixes are important
> enough to override such concerns and to backport even into releases
> that are on "minimal" support.
>
> I happen to think that this is one such fix, for reasons that I have
> laid out at length. I also think the backport policy should be amended
> to prevent an issue like this from "slipping through the cracks" again
> in the future. I am still considering the wording Shai proposed,
> though on first read I thought it was getting at the right idea.
>
> > James argues that this bug that went unreported for 2+ years is now very 
> important and is going to cause massive pain for many users. Only time will 
> answer this, but I'm skeptical. So far I believe we've seen two people 
> affected, James and the ticket reporter.
>
> Well.
>
> I had been trying to avoid bringing this up because I felt that the
> backport policy and the severity of the bug were the things to focus
> on, and because I was trying to avoid singling out individual mistakes
> that contributed to the situation we have now. But there is at least
> one other report of this bug in the Django Trac instance. It is the
> first one I found when trying to diagnose the problem in my own code
> (and the one I mentioned in my initial question on IRC, as anyone who
> saw that can confirm), and it is one that was filed only a couple of
> months after the release of Django 3.1, so well within the window of
> time when the backport policy would have said to apply the fix to the
> 3.1 branch as well as to main. It also correctly diagnosed the source
> of the bug and provided an attempt at a patch.
>
> That ticket was #32189:
>
> https://code.djangoproject.com/ticket/32189
>
> But it was closed invalid as a user error. We can debate whether the
> user should have been trying to access request.POST for their
> particular use case, but we cannot debate whether this is the
> underlying bug that user was encountering. It also was clearly not the
> normal behavior one ought to see from accessing request.POST, even in
> a non-POST request or supposedly non-appropriate context, and likely
> either should not have been closed, or should have produced a
> follow-up ticket to investigate why that specific behavior was
> occurring.
>
> As for whether anyone else is affected: my searching turned up several
> references on other sites to the exact error mess

Re: Backport for ticket 34063?

[Tim Graham]

Incidentally, I don't think it's important for the ultimate decision here, 
but I looked at the below analysis of ticket #32189. Carlton's analysis on 
the ticket that request.POST is empty when using 'content-type': 
'application/json' remains true. The results of the tests provided in the 
description of #32189 remain unchanged by the fix for #34063 
(test_request_factory_data_multipart passes and 
test_request_factory_data_json fails in the same way as in the ticket 
description). I would triage #32189 exactly as Carlton did. I don't see 
anything in that ticket that leads to the "AssertionError: Cannot read more 
than the available bytes from the HTTP incoming data." as in #34063. It's 
possible I made a mistake or that my knowledge is lacking, but I see 
nothing that would make me mark #32189 as a duplicate of #34063 (which I 
was planning to correct for posterity if it's indeed the case). It's 
possible that reporter did encounter the "Cannot read..." AssertionError at 
some point, but I see nothing concrete in the ticket that reproduces it. I 
hope that's clarifying!


> > James argues that this bug that went unreported for 2+ years is now very 
> important and is going to cause massive pain for many users. Only time will 
> answer this, but I'm skeptical. So far I believe we've seen two people 
> affected, James and the ticket reporter. 
>
> Well. 
>
> I had been trying to avoid bringing this up because I felt that the 
> backport policy and the severity of the bug were the things to focus 
> on, and because I was trying to avoid singling out individual mistakes 
> that contributed to the situation we have now. But there is at least 
> one other report of this bug in the Django Trac instance. It is the 
> first one I found when trying to diagnose the problem in my own code 
> (and the one I mentioned in my initial question on IRC, as anyone who 
> saw that can confirm), and it is one that was filed only a couple of 
> months after the release of Django 3.1, so well within the window of 
> time when the backport policy would have said to apply the fix to the 
> 3.1 branch as well as to main. It also correctly diagnosed the source 
> of the bug and provided an attempt at a patch. 
>
> That ticket was #32189: 
>
> https://code.djangoproject.com/ticket/32189 
>
> But it was closed invalid as a user error. We can debate whether the 
> user should have been trying to access request.POST for their 
> particular use case, but we cannot debate whether this is the 
> underlying bug that user was encountering. It also was clearly not the 
> normal behavior one ought to see from accessing request.POST, even in 
> a non-POST request or supposedly non-appropriate context, and likely 
> either should not have been closed, or should have produced a 
> follow-up ticket to investigate why that specific behavior was 
> occurring. 
>

-- 
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/05fef0dd-e608-46d2-a850-ddc5574183c2n%40googlegroups.com.

Re: GSOC 2023

[Tim Graham]

Hello all, please take a look at 
https://docs.djangoproject.com/en/dev/internals/contributing/new-contributors/ 
to find advice for new contributors.

On Tuesday, January 10, 2023 at 11:26:12 AM UTC-5 arpitasriv...@gmail.com 
wrote:

> Hello Everyone , myself Arpita Srivastava a pre final year computer 
> science student.
> I want to contribute in GSoC 2023 as my skill sets include python , 
> Django. So I have chosen Django as the organization to contribute in.  
> I was hoping If I could get some help from the Django & python community. 
> About how to start.
>

-- 
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/c8d64741-629a-4381-af9e-809c8a7c50bfn%40googlegroups.com.

Re: Proposal for a "RegExpMatches" PostgreSQL ORM function

[Tim Graham]

Hi, please consolidate your proposal when your ideas are complete. There's 
no need to start a separate thread for every function. Also, please search 
this mailing list and ticket tracker for past discussions that might be 
relevant. A quick search turned up at least 
https://groups.google.com/g/django-developers/c/jHhzEmZk4xE/m/_EErl1GGDAAJ 
and https://code.djangoproject.com/ticket/28805 (Add database functions for 
regular expressions, e.g. RegexpReplace) which duplicates this proposal.

On Tuesday, January 17, 2023 at 11:41:26 AM UTC-5 niccol...@gmail.com wrote:

> How would you see adding the "REGEXP_MATCHES" function to the current set 
> of PostgreSQL ORM functions?
>

-- 
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/e4e678fe-3a89-4729-8e9b-008af20ddf5an%40googlegroups.com.

Re: Request for Guidance

[Tim Graham]

Hello, please take a look at 
https://docs.djangoproject.com/en/dev/internals/contributing/new-contributors/ 
to find advice for new contributors.

On Tuesday, January 17, 2023 at 2:07:02 PM UTC-5 gair...@somaiya.edu wrote:

>  
>
>  
>
> Hello sir, i am Gairick a second year MCA student and want to contribute 
> ,can you please point to me some resources by reading i can contribute to 
> codebase and learn new technologies and please share me the guide for 
> installation 
>
> Regards,
>
> Gairick
>
>  
>
>  
>
>
> 
>  
> Virus-free.www.avast.com 
> 
>  
> <#m_-5157259906153594593_DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
>
> Disclaimer
> This email is governed by the Disclaimer Terms of  somaiya.edu which may 
> be viewed at https://www.somaiya.edu/en/email-disclaimer
>
> Finally, please do not print this email unless it is necessary. Every 
> unprinted email helps the environment.
>
>

-- 
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/7add6b7e-c4fc-44d1-8259-498be3f37b9fn%40googlegroups.com.

Re: Reverse for 'car_details' with arguments '('',)' not found. 1 pattern(s) tried:

[Tim Graham]

Hi, You've found the wrong mailing list for this post. This mailing list is 
for discussing the development of Django itself, not for support using 
Django. This means the discussions of bugs and features in Django itself, 
rather than in your code using it.

For support, please follow the "Getting Help" page: 
https://docs.djangoproject.com/en/stable/faq/help/ . This will help you 
find people who are willing to support you, and to ask your question in a 
way that makes it easy for them to answer.

Did the place you found this mailing list make this unclear?

On Saturday, January 21, 2023 at 5:01:55 PM UTC-5 bipuld...@gmail.com wrote:

>   In Views.py def car_details(request, id): redirect_to=1 
> single_car = get_object_or_404(Car, pk=id), 
>  data = { 'single_car': single_car, # 'url': url, }
>  # reverse('single_car', args=(id)) 
>  return render(request, 'cars/car_details.html', data)
>  In urls.py of my app 
> urlpatterns = [ path('', views.cars, name='cars'), 
>  path('\/car_details', views.car_details, name='car_details'),]
>  and In my templates cars.html
>  {% for car in cars %}  {{car.car_title}} 
> 
>   {{car.state}}, {{car.city}}  
> {% endfor %} 
> when i tried to call this car_details.html with urls function it show me 
> this error Reverse for 'car_details' with arguments '('',)' not found. 1 
> pattern(s) tried: I also tried with reverse function it doesnot work,How 
> can I solve this error  
>

-- 
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/bc79e6cc-70ef-4721-a5ef-0e11f058378fn%40googlegroups.com.

Re: Error

[Tim Graham]

Hi, You've found the wrong mailing list for this post. This mailing list is 
for discussing the development of Django itself, not for support using 
Django. This means the discussions of bugs and features in Django itself, 
rather than in your code using it.

For support, please follow the "Getting Help" page: 
https://docs.djangoproject.com/en/stable/faq/help/ . This will help you 
find people who are willing to support you, and to ask your question in a 
way that makes it easy for them to answer.

Did the place you found this mailing list make this unclear?
On Sunday, January 22, 2023 at 2:48:48 PM UTC-5 arshakar...@gmail.com wrote:

> When I want to auto generate models from already existing mongodb 
> collections by inspectdb it raises : # The error was: 'NoneType' object is 
> not subscriptable
> Please, any solutions
>

-- 
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/558ba312-efee-49d3-a8ad-3c6a8b2b64e6n%40googlegroups.com.

Re: Claiming Tickets

[Tim Graham]

Correct

On Saturday, January 28, 2023 at 11:32:21 AM UTC-5 jonathan...@gmail.com 
wrote:

> Hi all, 
>
> I was reading up on the documentation for new contributors and was reading 
> the "Claiming Tickets" section where it says "If a ticket for this issue 
> already exists, make sure nobody else has claimed it. To do this, look at 
> the “Owned by” section of the ticket. If it’s assigned to “nobody,” then 
> it’s available to be claimed. Otherwise, somebody else may be working on 
> this ticket." Is it also safe to claim a ticket that has a blank "Owned by" 
> field? If so I figured this could be a quick PR for me to get started with 
> updating the documentation.
>
> Thanks for the help!
>

-- 
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/b30e4d63-9e63-497b-b195-9767292a7151n%40googlegroups.com.

Stalebot on djangoproject.com issues

[Tim Graham]

Hello,

In October 2022, a stalebot was activated for djangoproject.com issues:

https://github.com/django/djangoproject.com/issues/1219
https://github.com/django/djangoproject.com/pull/1220

It comments on an issue if there's no activity in the last six months: "This 
issue has been automatically marked as stale because it has not had recent 
activity. It will be closed if no further activity occurs. Thank you for 
your contributions."

The bot closes the issue if there's no activity in the next seven days.

I didn't see much discussion among the djangproject.com team outside of the 
issue and PR,  but the rationale from the issue is this: "Idea copied from 
DRF PR #8423  - Add 
a StaleBot, configured with the lowest possible run limit. The intent here 
is to help us sweep through the issue and pull request backlog, and review 
what does and does not need to remain open at this point in time."

Here is what I said at the time: "I think this is a lame way to handle old 
issues. The result seems to be Carlton triaging all issues that the bot 
comments on. You could have asked him to do that without a bot adding 
noise. Should a useless "issue still valid" comment be required every 180 
days? Why not have a human triage each issue now that more people are 
maintaining this site? Using a bot comes off to me as passive aggressive. 
Why try to automatically discard years of issues (even if minor)? It's not 
like the passage of time or lack of activity means the problem went away. A 
responsible reporter will look through existing issues so they don't report 
a duplicate and not necessarily leave a comment like "issue still valid." 
If we close the issue automatically, what did that accomplish? I would 
think triaging issues would be a good way for new team members to develop 
their understanding of the site. If you're feeling unknowledgable about an 
old issue, feel free to ping me for advice. I hope you might reconsider the 
usefulness of the bot."

It's six months later, and I'm now having to again comment on inactive 
issues "stalebot, please don't close." to keep valid issues open.

Paolo Melchiorre (author of this initiative) says, "activating the stalebot 
last year allowed us to close many old issues. I think an issue opened 7 
years ago should be closed if no one takes care of it despite two reminders 
in the last year. As the removal of the stalebot is not only up to me, I 
think it is worth discussing it in a separate issue or on the developer 
mailing list."

I remain of the opinion that continued attempts to automatically abandon 
valid issues are not helpful and do not reflect project maintenance best 
practices. I would like to hear your thoughts on the matter. Thanks!

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/84d1ee45-401b-4a52-8243-1a40fcf32955n%40googlegroups.com.

Re: Opensource Django Project

[Tim Graham]

Yes. See 
https://docs.djangoproject.com/en/dev/internals/contributing/new-contributors/

On Saturday, April 8, 2023 at 10:50:17 AM UTC-4 Naresh Pahariya wrote:

> Me too...
>
> I think there is a documentation for django contribution. 
>
> Thanks,
> Naresh
>
> On Sat, 8 Apr, 2023, 3:51 pm Dipankar,  wrote:
>
>> Hi All,
>>
>> I want to contribute  to the Open Source Django Project as a developer.
>> Can anybody help me please?
>>
>> -- 
>> Warm Regards,
>> Dipankar B.
>>
>> -- 
>> 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-develop...@googlegroups.com.
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/django-developers/CAFdBwp-m8nUVrP0Jd4o16XwBEOOOkE9ys42yYXRze58aUQZ4qQ%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/bb49f44b-056f-4e9d-95b2-c7f0462ddcd0n%40googlegroups.com.

Re: Doc make error: make: *** [Makefile:59: html] Error 127

[Tim Graham]

It looks like Sphinx isn't installed. Did you `pip install 
docs/requirements.txt`?
On Monday, April 10, 2023 at 9:12:48 AM UTC-4 Ezekiel Adetoro wrote:

> I want to generate the documentation for Django, I have the folloe error
>
> sphinx-build -b djangohtml -n -d _build/doctrees -D language=en   . 
> _build/html
> make: sphinx-build: No such file or directory
> make: *** [Makefile:59: html] Error 127
>
> I have install all requirement and no error.
> Any help on how to go about 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/34976b65-dbcc-49d8-820c-abee7de9ba28n%40googlegroups.com.

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

[Tim Graham]

I agree with Carsten. I find the groups.google.com web interface much 
easier to follow and to quickly scan and see which threads I've read and 
which have new activity. I follow this mailing list more closely than the 
forum and prefer writing to it.

Incidentally, when I look at the "Django Internals" category of the forum, 
I see a lot of inappropriate usage questions that get answered there rather 
than pointed to the correct category. Is there a way to recategorize those 
posts?

On Thursday, May 4, 2023 at 2:09:35 AM UTC-4 Carsten Fuchs wrote:

> Hello,
>
> unfortunately, the subject lines of the emails sent by the forum have the 
> forum category prepended. These prefixes are long and make it difficult to 
> parse a large number of emails quickly, which significantly reduces one of 
> the main strengths of mail(ing-list)s.
>
> To be honest, I'm surprised that not more mailing list members argue in 
> favor of the mailing list. 
>
> The mailing list makes it easy to read or at least glance at every single 
> message, if desired, while enabling readers to skip uninteresting threads 
> quickly. This is a lot more difficult on the forum, especially with the 
> user interface as implemented by Discourse, which wastes a lot of white 
> space (lines with much vertical spacing, as with the topic lines on the 
> Latest page, are difficult to parse quickly) und whose „last visit“ line is 
> unreliable, especially if you read the forum on multiple devices (home, 
> office, mobile, …) with possibly several tabs open at the same time.
>
> I'm aware that I'm in a minority and that there is no way to convince the 
> relevant people to keep the mailing-lists, but in my opinion the switch the 
> forum is a step backwards in accessibility, usability and easy of use.
>
> Best regards,
> Carsten
>
> Am 04.05.23 um 07:49 schrieb Jure Erznožnik:
>
> This has been answered affirmatively in this very thread before. 
>
> The forum even has a "Mailing list mode" in addition to several other 
> mailing options (including a nifty "activity summary").
>
> LP,
> Jure
> On 4. 05. 23 07:28, Curtis Maloney wrote:
>
> Does the Forum allow me to get email notifications / summaries?
>
> If not, it will mean I disconnect with that part of the community.
>
> --
> Curtis
>
> On Thu, 4 May 2023, at 15:19, Arthur Rio wrote:
>
> Yes please!
>
>
>
> On May 3, 2023 at 11:19:12 PM, jure.er...@gmail.com (jure.er...@gmail.com) 
> wrote:
>
>
> +1
>
>  
>
> *From:* django-d...@googlegroups.com  *On 
> Behalf Of *natali...@gmail.com
> *Sent:* sreda, 03. maj 2023 20:10
> *To:* Django developers (Contributions to Django itself) <
> django-d...@googlegroups.com>
> *Subject:* Re: Can we move the activity on this list to the Forum now?
>
>  
>
> Hello everyone!
>
>  
>
> I was wondering if we could make a decision about this topic. On the one 
> hand, and as far as I understand, the forum is the preferred channel of 
> communication. On the other hand, having multiple channels of communication 
> can spread important discussions too thin, making it difficult to have 
> productive conversations in one place.
>
>  
>
> As a newcomer to the contributing community, I can attest that the current 
> situation causes some confusion. IMHO, the same applies to the chat 
> options: there is IRC and the Discord server (though perhaps I should start 
> a new forum topic about that in order to keep decisions separated).
>
>  
>
> In summary, I'm +1 to "move on-mass (all few of us :) over there"!
>
>  
>
> Thank you!
>
> Natalia.
>
>
>

-- 
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/2c6cf8cc-91f5-48d9-a3a9-337fff1f3439n%40googlegroups.com.

Re: Transition Docs to Inline

[Tim Graham]

Hi Moshe, 

Why is consulting the online documentation insufficient? I think most 
developers build Django projects while referencing the online documentation 
rather than while reading Django's source code.

What sort of documentation would be inlined? Would this require a large 
amount of duplication between docs and source code?

Why does adding docstrings require pyi files? My text editor doesn't have 
this "hover" feature. Please elaborate on your proposal for the 
uninitiated. Are there other projects that use the approach you suggest?
On Wednesday, January 3, 2024 at 2:38:02 PM UTC-5 Moshe Dicker wrote:

> Due to the dynamic nature of Python, features aren’t obvious.
> Developers don’t know what features a class has unless they dig through 
> the convoluted source code themselves or going online to check the 
> documentation.
>
> For example when implementing a `forms.ModelForm` hovering over it reveals 
> absolutely nothing useful.
>
> [image: image]
> image1000×157 11.5 KB
>
> 
>
> What do the “Django Lords” have to say about inlining the documentation in 
> the source code itself.
>
> I know the “Django Lords” have been weary of adding type stubs.
> However adding a docstring to this
> ```
> class Model(models.Model):
> ...
> class Meta: < THIS
> ...
> ```
>
> would require some stubs/.pyi files.
>
> I wouldn’t want to work on this just to find out that there are benefits 
> of the current setup that they aren’t willing to make a tradeoff.
>
> What would be the best way of asking the Django Governing Board about 
> their opinion on 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/d079d602-a11d-46ae-86c0-4bee9a8ff01bn%40googlegroups.com.

Re: Transition Docs to Inline

[Tim Graham]

I don't think moving docs inline is a good idea. Quoting Aymeric from 2013 
regarding django.contrib.admindocs [1] summarizes my feelings: 
"""
1) It's called the "documentation generator", but it only operates on 
docstrings. This promotes the idea that docstrings are appropriate 
documentation, while the Python and Django communities now favor prose 
documentation. 

2) Even though it's possible to use docstrings to generate API 
documentation, for instance with Sphinx' autodoc, I find that heavily 
formatted, Javadoc-style docstrings (or late epydoc-style) tend to be hard 
to read for humans and I don't want Django to encourage them. 
"""
[1] 
https://groups.google.com/g/django-developers/c/0-qFyCPuSRs/m/kny7Oeu2RdoJ
On Monday, January 8, 2024 at 11:55:19 AM UTC-5 Jörg Breitbart wrote:

> Ah interesting that you mentioned django-stubs. I had good to mediocre 
> success applying it to my own django apps. It gets the job mostly done 
> for high level interfaces, but shows rough stub edges as soon as you 
> have to touch lower interfaces (can only speak for the ORM section in 
> this regard, which is highly mutating itself).
>
> Type annotations in Python are heavily inspired by Typescript, where 
> you'd strive for building up you interface types granularily and the 
> compiler does the rest pulling things together.
> I am not sure if Python's type annotations are yet or will ever be 
> capable to achieve that good enough for most common python paradigm, 
> seems Python is way too flexible for static type analysis. Typescript 
> partially solves this by banning/hiding some of JS' flexibility. (Ever 
> tried to fully type a mutating decorator in Python? Hours of fun ahead, 
> and you will still end up declaring many Anys effectively disabling 
> proper type pulling.)
>
> Now back to Django - it makes heavy usage of dynamic python features, 
> which is poison for any static type deduction. This is also the reason 
> why IDEs typically fail for more dynamic python code like django, unless 
> they do a partial runtime inspection (I think IntelliJ tries to do that 
> to some degree).
>
> So while better typing support is really nice where possible, I'd 
> suggest to not open this can of worms (yet), but mainly to stick to the 
> better inline docs idea.
>
>
> Cheers,
> Jörg
>

-- 
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/011ce3a2-3936-4e90-b205-5d12b229d536n%40googlegroups.com.

Re: [Question] Why BaseManager._get_queryset_methods need use getattr(self.get_queryset(), name) in create_method

[Tim Graham]

Hi Ryoma, a good way to investigate this would be to make the change and 
see if anything breaks. 

If I understand correctly, your suggest is:

-return getattr(self.get_queryset(), name)(*args, **kwargs)
+return method(*args, **kwargs)

In that case, running the test suite gives this error:

  File "/home/tim/code/django/django/db/models/manager.py", line 89, in 
manager_method
return method(*args, **kwargs)
   ^^^
TypeError: QuerySet.using() missing 1 required positional argument: 'alias'

I leave further investigation to you. :-)
On Tuesday, February 27, 2024 at 7:28:05 PM UTC-5 Ryoma Han wrote:

> I've been reading through the Django source code the last few days. When I 
> was reading the BaseManager source code I saw a method like this:
>
> ```python
> @classmethod
> def _get_queryset_methods(cls, queryset_class):
> def create_method(name, method):
> @wraps(method)
> def manager_method(self, *args, **kwargs):
> return getattr(self.get_queryset(), name)(*args, **kwargs)
>
> return manager_method
>
> new_methods = {}
> for name, method in inspect.getmembers(
> queryset_class, predicate=inspect.isfunction
> ):
> if hasattr(cls, name):
> continue
> queryset_only = getattr(method, "queryset_only", None)
> if queryset_only or (queryset_only is None and 
> name.startswith("_")):
> continue
> new_methods[name] = create_method(name, method)
> return new_methods
> ```
>
> My question is why we use `getattr(self.get_queryset(), name)` insted of 
> just use `method`.
>

-- 
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/86389eb3-c16f-42d6-ae0d-983038734598n%40googlegroups.com.

stability of widget API

[Tim Graham]

I recently updated the following patch regarding creating custom widgets:

https://code.djangoproject.com/attachment/ticket/11185/11185.diff

It mentions:

Interfaces of classes :class:`~django.forms.widgets.Widget` and 
> :class:`~django.forms.widgets.MultiWidget` are still in flux, therefore - 
> please take care to test all of your custom widgets when upgrading Django.


As far as I know, it's our practice *not* to document APIs that may change, 
however, I'm not sure there's anything in the patch that is subject to 
change.  Could someone give a quick look?  Thanks!

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To view this discussion on the web visit 
https://groups.google.com/d/msg/django-developers/-/R-mPArKjWtwJ.
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.

end of "coming soon" in the tutorial? - tutorial 5 feedback needed!

[Tim Graham]

Katie Miller and Ben Sturmfels have written a fifth tutorial covering 
making "polls" a reusable app.  I've given it an initial review, but I'm 
hoping we can get a few more people to give it a look and/or try it out, 
particularly if you are an expert in packaging (which I'm not).  Thanks 
guys!

p.s. I've built the docs with the latest patch here:
http://techytim.com/django/tutorial05/intro/tutorial05.html

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To view this discussion on the web visit 
https://groups.google.com/d/msg/django-developers/-/4EH8SfW_RjEJ.
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: end of "coming soon" in the tutorial? - tutorial 5 feedback needed!

[Tim Graham]

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

On Saturday, September 15, 2012 7:24:23 PM UTC-4, Tim Graham wrote:
>
> Katie Miller and Ben Sturmfels have written a fifth tutorial covering 
> making "polls" a reusable app.  I've given it an initial review, but I'm 
> hoping we can get a few more people to give it a look and/or try it out, 
> particularly if you are an expert in packaging (which I'm not).  Thanks 
> guys!
>
> p.s. I've built the docs with the latest patch here:
> http://techytim.com/django/tutorial05/intro/tutorial05.html
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To view this discussion on the web visit 
https://groups.google.com/d/msg/django-developers/-/eCoT-L40OXEJ.
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: end of "coming soon" in the tutorial? - tutorial 5 feedback needed!

[Tim Graham]

Thank-you for the feedback, guys.  I've updated the patch based on 
suggestions, so if you are interested, please take another look.

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

I also wanted to plug the tutorial 3 refactor that Daniel Greenfield 
tackled.  As far as I'm concerned it's RFC if we can get another set of 
eyes to +1.

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

On Wednesday, September 19, 2012 12:49:35 AM UTC-4, Daniel Greenfeld wrote:
>
> I'll toss in our own djangopackages.com as well as a resource. :-)
>
> On Monday, September 17, 2012 10:00:39 PM UTC+2, AJHMvanRatingen wrote:
>>
>> I'm not an expert in packaging, I've released a few apps, but my novice 
>> eyes caught some things:
>> * Bullet 6 under "Packaging your app" mentions the manifest file, without 
>> specifying anything useful about it to someone (eg: me) who doesn't know 
>> what it's for. Maybe add a descriptional oneliner, or a link to more 
>> details as a bare minimum.
>> The same goes for other steps here too; they merely instruct what to do 
>> without any background or analysis of the code, like the first tutorials do.
>> * Creating a release requires you to think about naming, and there's a 
>> couple of names to be defined:
>>   - package name as found on pypi / installable with pip   (django-polls)
>>   - module name as it's imported in python   (polls)
>>   - name of the template dir   (polls, = module name)
>> Maybe clarify the distinction and definition, and provide some 
>> guidelines. Eg: prepend 'django-' to django apps, and remove it from the 
>> module name, except when it might collide with another module, and use the 
>> same name for the template dir.
>> * The guide could include a link to documentation on how to setup and 
>> manage a VCS repo for collaboration (even just by pointing to how it's done 
>> for django itself). Also mentionable are other tools like (to name a few) 
>> readthedocs, django-apps.com, and, if CI was given a short introduction, 
>> travis-ci (since many django apps seem to use this) could be mentioned.
>>
>> Just my thoughts to make this tutorial as good as the others!
>>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To view this discussion on the web visit 
https://groups.google.com/d/msg/django-developers/-/1x2ZsZ5H5FoJ.
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: end of "coming soon" in the tutorial? - tutorial 5 feedback needed!

[Tim Graham]

Thank-you to Russ and Carl for the feedback!  I've merged the updates to 
tutorial 3 earlier this week.

I also updated the reusable apps tutorial to use distribute rather than 
distutils and incorporated other suggestions as noted in the ticket.

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

You can view the latest edition here:

http://techytim.com/django/tutorial05/intro/reusable-apps.html

I have no previous experience packaging with distribute, so any feedback is 
appreciated!

On Saturday, October 13, 2012 8:34:33 PM UTC-4, Russell Keith-Magee wrote:
>
> Hi Tim, 
>
> Both of these are looking really good. I've left some comments on the 
> tickets, mostly fairly minor suggestions. 
>
> Russ %-) 
>
> On Sun, Oct 14, 2012 at 6:43 AM, Tim Graham > 
> wrote: 
> > Thank-you for the feedback, guys.  I've updated the patch based on 
> > suggestions, so if you are interested, please take another look. 
> > 
> > https://code.djangoproject.com/ticket/16671 
> > 
> > I also wanted to plug the tutorial 3 refactor that Daniel Greenfield 
> > tackled.  As far as I'm concerned it's RFC if we can get another set of 
> eyes 
> > to +1. 
> > 
> > https://code.djangoproject.com/ticket/18715 
> > 
> > 
> > On Wednesday, September 19, 2012 12:49:35 AM UTC-4, Daniel Greenfeld 
> wrote: 
> >> 
> >> I'll toss in our own djangopackages.com as well as a resource. :-) 
> >> 
> >> On Monday, September 17, 2012 10:00:39 PM UTC+2, AJHMvanRatingen wrote: 
> >>> 
> >>> I'm not an expert in packaging, I've released a few apps, but my 
> novice 
> >>> eyes caught some things: 
> >>> * Bullet 6 under "Packaging your app" mentions the manifest file, 
> without 
> >>> specifying anything useful about it to someone (eg: me) who doesn't 
> know 
> >>> what it's for. Maybe add a descriptional oneliner, or a link to more 
> details 
> >>> as a bare minimum. 
> >>> The same goes for other steps here too; they merely instruct what to 
> do 
> >>> without any background or analysis of the code, like the first 
> tutorials do. 
> >>> * Creating a release requires you to think about naming, and there's a 
> >>> couple of names to be defined: 
> >>>   - package name as found on pypi / installable with pip   
> (django-polls) 
> >>>   - module name as it's imported in python   (polls) 
> >>>   - name of the template dir   (polls, = module name) 
> >>> Maybe clarify the distinction and definition, and provide some 
> >>> guidelines. Eg: prepend 'django-' to django apps, and remove it from 
> the 
> >>> module name, except when it might collide with another module, and use 
> the 
> >>> same name for the template dir. 
> >>> * The guide could include a link to documentation on how to setup and 
> >>> manage a VCS repo for collaboration (even just by pointing to how it's 
> done 
> >>> for django itself). Also mentionable are other tools like (to name a 
> few) 
> >>> readthedocs, django-apps.com, and, if CI was given a short 
> introduction, 
> >>> travis-ci (since many django apps seem to use this) could be 
> mentioned. 
> >>> 
> >>> Just my thoughts to make this tutorial as good as the others! 
> > 
> > -- 
> > You received this message because you are subscribed to the Google 
> Groups 
> > "Django developers" group. 
> > To view this discussion on the web visit 
> > https://groups.google.com/d/msg/django-developers/-/1x2ZsZ5H5FoJ. 
> > 
> > To post to this group, send email to 
> > django-d...@googlegroups.com. 
>
> > To unsubscribe from this group, send email to 
> > django-develop...@googlegroups.com . 
> > For more options, visit this group at 
> > http://groups.google.com/group/django-developers?hl=en. 
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To view this discussion on the web visit 
https://groups.google.com/d/msg/django-developers/-/WDpVrA8_5u8J.
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.

#16779 - a tutorial for first time Django contributors

[Tim Graham]

Taavi Taijala has written a tutorial for new contributors that I've given 
an initial review.  I'm hoping we can get a few more sets of eyes on it. 
 Might be useful to pass it on to any newbies you know and have them try it 
out as well.  Thanks!

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To view this discussion on the web visit 
https://groups.google.com/d/msg/django-developers/-/-_1dshZ5wDIJ.
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: #16779 - a tutorial for first time Django contributors

[Tim Graham]

Thanks to those who have weighed in on this thus far. I've rewritten part 
of the tutorial to use a more recent ticket from the "git era" to hopefully 
make things less confusing.

I think the part that has the most potential to confuse new contributors is 
the introduction of PYTHONPATH.  Claude suggested we could simply instruct 
users to run the tests like so:

PYTHONPATH=/path/to/django ./run_tests.py --settings=test_sqlite

I'm not particularly in love with that, but it would eliminate the need to 
try to explain things and perhaps we could link out to an external resource 
that explains PYTHONPATH well, although I haven't found anything after a 
quick search.

Any specific feedback on this paragraph, or the tutorial as whole, would be 
appreciated:
http://techytim.com/django/16779/intro/contributing.html#setting-django-up-to-run-the-test-suite

On Friday, November 2, 2012 8:03:34 PM UTC-4, Tim Graham wrote:
>
> Taavi Taijala has written a tutorial for new contributors that I've given 
> an initial review.  I'm hoping we can get a few more sets of eyes on it. 
>  Might be useful to pass it on to any newbies you know and have them try it 
> out as well.  Thanks!
>
> https://code.djangoproject.com/ticket/16779
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To view this discussion on the web visit 
https://groups.google.com/d/msg/django-developers/-/pKclp60HFCYJ.
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: Testing documentation

[Tim Graham]

This looks great, thanks for your work on this!  I've made some minor 
revisions and put up an HTML version of the new tutorial for easier review.

http://techytim.com/django/9962/intro/tutorial05.html

On Monday, November 5, 2012 12:06:53 PM UTC-5, Daniele Procida wrote:
>
> I have done some work on writing up a tutorial for testing (part 5 of the 
> existing tutorial, in effect). 
>
> My draft so far: 
>
> <
> https://github.com/evildmp/django/blob/testing-tutorial/docs/intro/tutorial05.txt>
>  
>
>
> I'd really appreciate feedback, on any aspect of this. 
>
> Trac ticket is . 
>
> Thanks, 
>
> Daniele 
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To view this discussion on the web visit 
https://groups.google.com/d/msg/django-developers/-/E5WS5S0zJ1cJ.
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: #16779 - a tutorial for first time Django contributors

[Tim Graham]

Thanks for the feedback everyone.  I'm made some updates based on these 
suggestions, please see the ticket:

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

On Sunday, November 11, 2012 5:50:18 PM UTC-5, Daniele Procida wrote:
>
> On Sat, Nov 10, 2012, Tim Graham > 
> wrote: 
>
> >Any specific feedback on this paragraph, or the tutorial as whole, would 
> be 
> >appreciated: 
>
> My four thoughts: 
>
> Firstly: I like to see things like: 
>
> ./runtests.py --settings=test_sqlite 
>
> include a comment when appropriate; in this case to say why we are using 
> --settings=test_sqlite 
>
> Secondly: "For advanced users who wish to use virtualenv" - is this really 
> implying that only advanced users would use virtualenv? 
>
> I think that the most helpful thing to say to people who are not using 
> virtualenv already is that they need spend 15 minutes learning to use it 
> before they do anything else, because it's one of the most valuable and 
> easy to learn tools they will ever encounter. 
>
> Thirdly: if everyone is using virtualenv, would that eliminate the 
> difficulties trying to explain PYTHONPATH? 
>
> Fourthly: although this and the Working with Git and GitHub tutorial 
> explain the technical part of the process well, they both somewhat assume 
> that you're able to come up with complete if not perfect patch. 
>
> In reality I think a lot of back-and-forth refinement goes on before that 
> point is reached - what would be handy is advice on how to proceed when 
> your patch is incomplete and you need some feedback before going further. 
>
> But this looks great, I wish I had read it myself before trying to submit 
> anything. 
>
> Daniele 
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To view this discussion on the web visit 
https://groups.google.com/d/msg/django-developers/-/fRCPN4aoma4J.
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.

testing tutorial feedback needed! (was: Testing documentation)

[Tim Graham]

Bumping this in hopes of getting a couple more reviews.

Please leave comments on the ticket or pull request:
https://code.djangoproject.com/ticket/9962
https://github.com/django/django/pull/548

On Tuesday, November 13, 2012 3:54:15 PM UTC-5, Tim Graham wrote:
>
> This looks great, thanks for your work on this!  I've made some minor 
> revisions and put up an HTML version of the new tutorial for easier review.
>
> http://techytim.com/django/9962/intro/tutorial05.html
>
> On Monday, November 5, 2012 12:06:53 PM UTC-5, Daniele Procida wrote:
>>
>> I have done some work on writing up a tutorial for testing (part 5 of the 
>> existing tutorial, in effect). 
>>
>> My draft so far: 
>>
>> <
>> https://github.com/evildmp/django/blob/testing-tutorial/docs/intro/tutorial05.txt>
>>  
>>
>>
>> I'd really appreciate feedback, on any aspect of this. 
>>
>> Trac ticket is <https://code.djangoproject.com/ticket/9962>. 
>>
>> Thanks, 
>>
>> Daniele 
>>
>>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To view this discussion on the web visit 
https://groups.google.com/d/msg/django-developers/-/agPUVvf07wYJ.
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: Tutorials

[Tim Graham]

Hi Daniele,

I think additional tutorials would be welcome. My suggestion, before you 
dive in and start writing, would be to create a ticket with an outline of 
the proposed tutorial.  That will give the community a chance to take a 
look and provide feedback and suggestions before you spend time doing the 
actual writing.

For some ideas, here is the list of "coming soon" tutorials that were at 
the end of tutorial 4 for a long time:

   - Advanced form processing 
   - Using the RSS framework 
   - Using the cache framework (see ticket below) 
   - Using the comments framework (not sure about this, since I think 
   comments may be removed from Django, see #18965) 
   - Advanced admin features: Permissions 
   - Advanced admin features: Custom JavaScript

These may not be the best options at this point, but someone thought they 
were good ideas at one point.

In addition, here are some tutorial tickets that have been "accepted":

#16526  - Add a tutorial on 
caching
#19106  - Add new tutorial on 
breaking templates into blocks

I think your suggestion of logging is a good candidate -- you may want to 
take a look at #19395  as well.

Thank-you for your contributions thus far, and I look forward to seeing 
what you come up with in the future. :-)

Tim

On Friday, January 4, 2013 5:42:44 PM UTC-5, Daniele Procida wrote:
>
> I am one of those people who can only learn things by doing them, and 
> finds it very hard to grasp things from reference materials. The Django 
> documentation is excellent on the latter, but not quite so good on the 
> tutorials that would guide me through doing things in a way that will help 
> me learn. 
>
> I've made a couple of tutorial contributions so far (which if I am honest 
> simply reflect the steps I took when I was learning the topic). They are 
> the testing tutorial <
> https://docs.djangoproject.com/en/1.5//intro/tutorial05/> and a 
> uWSGI/nginx tutorial, which though it may not be quite right for the Django 
> docs has gone into the uWSGI docs. 
>
> I'd like to contribute more tutorials to the documentation, and since the 
> next thing I need to get to grips with is logging I will write my own notes 
> so I remember how to do it, and I could create a tutorial for it. 
>
> Would that be useful for the documentation? I realise that a tutorial is 
> always going to be a partial and incomplete introduction to a subject, but 
> newcomers need to start with something concrete, and it gives them some 
> purchase on the reference material that is already provided. 
>
> Are there other topics that really ought to have tutorials written for 
> them? 
>
> Daniele 
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To view this discussion on the web visit 
https://groups.google.com/d/msg/django-developers/-/vdn9xXpBvEAJ.
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.

#14633 - organization of settings docs

[Tim Graham]

I'd appreciate feedback on #14633- 
"Organize settings reference docs". So far I've broken out the settings 
for each contrib app into their own sections. The one comment on the pull 
request suggests further breaking up the settings listed in the "Core 
settings" section, e.g. logging, caches, globalization (i18n/l10n), email, 
file uploads/media, storages, and security. I don't feel strongly about 
this proposal: it could be useful, but it could also be ambiguous as to 
which section a particular settings belongs in.

The pull request also suggests organizing the default settings.py in a 
similar fashion.  While it may be outside of the scope of this ticket, it 
could be worthwhile to discuss that suggestion as well.

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To view this discussion on the web visit 
https://groups.google.com/d/msg/django-developers/-/Uku6Vo8oCvIJ.
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: #14633 - organization of settings docs

[Tim Graham]

Agreed, I'm +1 to keeping deprecated settings inline rather than moving 
them to their own section, but I'd defer to whoever made the original 
decision.

On Tuesday, January 8, 2013 4:58:17 AM UTC-5, Sam Lai wrote:
>
> Looks good. Adds a bit more structure for browsing but doesn't 
> significantly change how the page is used, which is probably through 
> CTRL-F. 
>
> As mentioned by others in the issue, the distinction current and 
> deprecated settings seems very arbitrary. I think it'll be better to 
> sort the deprecated settings like any other setting, but include a 
> better visual distinction to indicate that they're deprecated (at 
> least bold the word deprecated I think). When someone's looking for a 
> setting, they're not thinking about whether or not a setting is 
> deprecated; they're probably looking for what it means and how it can 
> be configured. 
>
>
>
> On 8 January 2013 08:02, Tim Graham > 
> wrote: 
> > I'd appreciate feedback on #14633 - "Organize settings reference docs". 
> So 
> > far I've broken out the settings for each contrib app into their own 
> > sections. The one comment on the pull request suggests further breaking 
> up 
> > the settings listed in the "Core settings" section, e.g. logging, 
> caches, 
> > globalization (i18n/l10n), email, file uploads/media, storages, and 
> > security. I don't feel strongly about this proposal: it could be useful, 
> but 
> > it could also be ambiguous as to which section a particular settings 
> belongs 
> > in. 
> > 
> > The pull request also suggests organizing the default settings.py in a 
> > similar fashion.  While it may be outside of the scope of this ticket, 
> it 
> > could be worthwhile to discuss that suggestion as well. 
> > 
> > -- 
> > You received this message because you are subscribed to the Google 
> Groups 
> > "Django developers" group. 
> > To view this discussion on the web visit 
> > https://groups.google.com/d/msg/django-developers/-/Uku6Vo8oCvIJ. 
> > To post to this group, send email to 
> > django-d...@googlegroups.com. 
>
> > To unsubscribe from this group, send email to 
> > django-develop...@googlegroups.com . 
> > For more options, visit this group at 
> > http://groups.google.com/group/django-developers?hl=en. 
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To view this discussion on the web visit 
https://groups.google.com/d/msg/django-developers/-/WZWRDsCUqFcJ.
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: #14633 - organization of settings docs

[Tim Graham]

Thanks for the suggestion, I've added a topical index to the pull request.

On Tuesday, January 8, 2013 12:49:58 PM UTC-5, ptone wrote:
>
> Looks good overall Tim - I do think that the primary reference should be 
> kept alphabetical within core - this is most useful when you have a setting 
> you need to look up.  But I do think that a 'by-topic' cross reference 
> index could also be very useful for discovering or learning about all 
> settings.  Such an index could be at the bottom of the page, and include 
> the topics suggested, as well as the deprecated settings - settings that 
> apply to more than one topic could be duplicated in such an index, and 
> deprecated settings could be duplicated under a topic, and under a 
> "deprecated" heading in such an index. This is a case where more 
> organization is only good, and there is no reason we have to choose an 
> either or.
>
> -Preston
>
>
> On Monday, January 7, 2013 1:02:49 PM UTC-8, Tim Graham wrote:
>>
>> I'd appreciate feedback on 
>> #14633<https://code.djangoproject.com/ticket/14633>- "Organize settings 
>> reference docs". So far I've broken out the settings 
>> for each contrib app into their own sections. The one comment on the pull 
>> request suggests further breaking up the settings listed in the "Core 
>> settings" section, e.g. logging, caches, globalization (i18n/l10n), email, 
>> file uploads/media, storages, and security. I don't feel strongly about 
>> this proposal: it could be useful, but it could also be ambiguous as to 
>> which section a particular settings belongs in.
>>
>> The pull request also suggests organizing the default settings.py in a 
>> similar fashion.  While it may be outside of the scope of this ticket, it 
>> could be worthwhile to discuss that suggestion as well.
>>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To view this discussion on the web visit 
https://groups.google.com/d/msg/django-developers/-/abUwIznDjT4J.
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: unittest.TestCase vs. django.test.TestCase in overview example

[Tim Graham]

It seems like it could be a dangerous precedent to cater to people who 
don't take the time to fully read the docs, but in this case I'm a bit 
sympathetic. On the other hand, this example will probably be a bit more 
obvious when we drop support for Python 2.6 and no longer have 
django.utils.unittest. At the least, we could probably move the warning 
above the example so it's a bit more visible.

On Saturday, March 16, 2013 8:27:01 PM UTC-4, Lorin Hochstein wrote:
>
> Hi there:
>
> On the Django testing overview doc page <
> https://docs.djangoproject.com/en/dev/topics/testing/overview/>, the 
> initial example uses unittest.TestCase. A Django developer who was looking 
> for a quick reminder on how to write unit tests is likely to hit this page 
> first. If that developer doesn't read the "warning" section below, they 
> could mistakenly use unittest.TestCase when their unit tests change  the 
> database. This very scenario happened to a colleague of mine.
>
> I proposed changing this to django.test.TestCase <
> https://github.com/django/django/pull/903>, but that pull request with 
> closed out by Aymeric Augustin, with reference to <
> https://code.djangoproject.com/ticket/15896>. I don't think ticket #15986 
> covers quite the same issue, despite its title. Django devs, can you 
> reconsider this doc patch?
>
> Take care,
>
> Lorin
>
>

-- 
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: Fellow Report - October 31, 2014

[Tim Graham]

Hi Justin,

Thanks for the feedback. Making 1.8 the next LTS was discussed a bit 
internally before I shared the idea and tentative schedule for the 1.8 
release on the thread "1.8 release planning." The only feedback on that 
thread (2 weeks ago) was from Josh Smeaton who supported the details 
outlined there. There is still time to weigh in there if you like.

Tim

On Friday, October 31, 2014 8:28:26 PM UTC-4, Justin Holmes wrote:
>
> Tim, 
>
> This truly is a stellar report.  Thanks so much. 
>
> I do have one question about this statement: 
>
> > A reminder that we expect Django 1.8 to become the next LTS version of 
> Django, so if you have a pet bug or feature, now's a great time to get 
> it fixed! 
>
> You characterize this as a "reminder" - I didn't realize this had been 
> firmly decided, although it was obviously discussed at DjangoCon. 
> Although I'm definitely in support, I am curious: who made this decision 
> and when? 
>
>
> On 10/31/2014 04:04 PM, Tim Graham wrote: 
> > 
> > To briefly summarize the triage and review work, we continue to 
> > retrieve good bug reports for Django 1.7, particularly migration edge 
> > cases. I'd expect to see another bug fix release for the 1.7 series 
> > within a month of 1.7.1. One issue the core team will be addressing at 
> > the "Django: Under the Hood" conference in mid-November is adding more 
> > team members to the list of people who can release Django. The lack of 
> > availability of someone who has the time and privileges to do a 
> > release has been a bottleneck on occasion. In addition to bug fixing 
> > on the 1.7 branch, master (1.8) continues to receive a steady diet of 
> > new small features. A reminder that we expect Django 1.8 to become the 
> > next LTS version of Django, so if you have a pet bug or feature, now's 
> > a great time to get it fixed! 
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/98ff9e20-5bc9-474a-aef0-538b1b479aa7%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Cleaning up broken pipe errors in runserver

[Tim Graham]

I had a look at the patch.  As I mentioned on the ticket, "I am not really 
happy with that patch which copies the 
simple_server.WSGIRequestHandler.handle() method from Python's version in 
order to override it. The copied version is not in sync with the latest 
Python and I'd prefer not to be in a position where we'd have to copy 
changes from there to Django."

Matthew noted, "the change [in WSGIRequestHandler.handle()], made only last 
month (hence why this PR doesn't currently match it), is the only change to 
that function since it became part of the standard library in 2006, and is 
a small potential security issue that doesn't apply to a development server 
in any case, as that's explicitly listed as being insecure. I don't 
necessarily think you'd have to keep changes in sync from upstream, as I 
don't see there would be any changes to this function other than other tiny 
security issues that don't matter to a development server, but I can see 
you wouldn't want to be in that potential situation anyway."

I agree with that, however, many people do use runserver in production and 
several members of the core team feel we should fix security issues with 
runserver even though the docs say it's not hardened for production use 
(I'm not one of them). Any more opinions on how to proceed here?

On Wednesday, August 27, 2014 12:52:38 PM UTC-4, Richard Eames wrote:
>
> I'm +1 for this, for the same reasons; I have a monkey patch for my 
> selenium tests which does the same thing as this PR.
>
> On Saturday, 2 August 2014 18:20:18 UTC-6, Matthew Somerville wrote:
>>
>> Hi,
>>
>> I have created a branch at 
>> https://github.com/dracos/django/compare/pipe-cleaning that builds upon 
>> a previous patch posted to this list and outputs "Broken pipe" instead of a 
>> traceback for such an error. As the history below shows, practically 
>> speaking all reports of broken pipe tracebacks in the log are due to the 
>> browser cutting off output, and are not helpful to be shown as a full 
>> traceback. I get them frequently (e.g. hit refresh before your previous 
>> page has finished loading to sometimes get it), and find them annoying.
>>
>> I am posting here because ticket # - 
>> https://code.djangoproject.com/ticket/ - is marked wontfix. I am not 
>> "imagei" on that ticket, I just came across the ticket recently whilst 
>> trying to work out why my Selenium tests on Travis were failing with broken 
>> pipes when they were fine last week - 
>> https://github.com/travis-ci/travis-ci/issues/2610 (some change to 
>> underlying Travis, I assume). Ticket # was opened in May 2007, and 
>> marked wontfix in September 2007 saying "The best we could is to have a 
>> more explicit error message." In 2008 someone provided a patch to make 
>> it a logged error message rather than spew a scary traceback, there was a 
>> +1 and a "leave as-is", then silence. There was a brief reopening of the 
>> thread in 2012 by two people who also found the broken pipe tracebacks 
>> tedious, then nothing further since then. The thread (2008 and 2012) can be 
>> found at 
>> https://groups.google.com/forum/#!topic/django-developers/W1Nns9k40EQ
>>
>> (The 'python manage.py runserver --help' is a little bit confusing 
>> because it has a --traceback argument and yet you still get a traceback - 
>> you have to have read the default options section of the django-admin.py 
>> documentation to know that only makes a difference to CommandError, not any 
>> other type of error. My branch also adds "CommandError" to the help output 
>> of --traceback.)
>>
>> The 2008 patch doesn't really work any more, but I think I've made the 
>> spirit of the same thing on the current Django code. I hope this can be 
>> considered for inclusion, as I think it tidies up a common issue with 
>> runserver output that will especially confuse people new to Django. Do let 
>> me know if I've gone about fixing it in the wrong way, or if I should do 
>> something differently. In my testing it certainly makes my runserver logs 
>> nicer to follow :)
>>
>> ATB,
>> Matthew
>>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/1ff725df-5985-4c31-a238-470d1b151716%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Add ability to show the migration plan (#23359)

[Tim Graham]

If we went with a separate command, would there be any problem having 
--list on both migrate and showmigrations. I feel like deprecating it off 
of migrate will cause more complaints about needless deprecations.

On Wednesday, October 29, 2014 9:28:51 PM UTC-4, Andrew Godwin wrote:
>
> This used to be called "graphmigrations" in South, so I'm +0 on moving it 
> to showmigrations; I don't want migrate to gain any extra functionality. 
> That said, I tried moving --list to something separate during the 1.7 phase 
> but there were objections to people who liked it on migrate.
>
> I don't really mind which way you go, to be honest; both seem like 
> sensible places. Other people might have stronger opinions.
>
> Andrew
>
> On Wed, Oct 29, 2014 at 4:44 PM, Markus Holtermann <
> in...@markusholtermann.eu > wrote:
>
>> Hey folks,
>>
>> A few weeks ago I opened a ticket (
>> https://code.djangoproject.com/ticket/23359) to add the ability to show 
>> a migration plan similar as listing all migrations within a project 
>> (manage.py migrate --list). After some discussions on IRC and on the first 
>> pull request (https://github.com/django/django/pull/3116) we realized 
>> that there might even be more use cases, e.g. to output all migration files 
>> as a dot file to generate a graph (
>> https://github.com/django/django/pull/3116#issuecomment-53565075). 
>> That's when I opened a second pull request that moves the existing "--list" 
>> and the new "--plan" option from the "migrate" command to a 
>> "showmigrations" command.
>>
>> Any suggestions on which way I should follow, integrate in "manage.py 
>> migrate" (pull request 3116: https://github.com/django/django/pull/3116) 
>> or add a new dedicated command "manage.py showmigrations" (pull request 
>> 3153: https://github.com/django/django/pull/3153)?
>>
>> /Markus
>>
>> -- 
>> 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-develop...@googlegroups.com .
>> To post to this group, send email to django-d...@googlegroups.com 
>> .
>> Visit this group at http://groups.google.com/group/django-developers.
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/django-developers/f8bdabfc-f005-4e8e-b1d9-0b69dfdedd82%40googlegroups.com
>>  
>> 
>> .
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/d629e9c9-5ea1-46a4-b410-ceec6aeddfa7%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Unicode SlugField design decision (#16501)

[Tim Graham]

I wanted to solicit feedback on the two approaches to supporting unicode in 
SlugField:

1. Added a unicode argument to models.SlugField and forms.SlugField.
https://github.com/django/django/pull/1979

2. Added models.UnicodeSlugField and forms.UnicodeSlugField. 
https://github.com/django/django/pull/1987

The patch author says, "On one hand, I like the new field approach because 
it gives us an easier upgrade path. On the other hand, it feels like I'm 
polluting django.db.models and django.forms with slightly different 
versions of something that's already there."

Approach 1 does seem cleaner to me, but I'd be interested in hearing from 
those interested in this feature.

Ticket: https://code.djangoproject.com/ticket/16501

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/33e9747f-6ced-4710-9e59-ca128e065c5c%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Next LTS version after 1.4?

[Tim Graham]

See the thread on this list titled "1.8 release planning" for details on 
the current proposal (If 1.8 is the next LTS, support for 1.4 would be 
extended 6 months after 1.8 is released, etc.). Feedback on that proposal 
appreciated.

On Wednesday, November 5, 2014 9:59:03 AM UTC-5, Marc Tamlyn wrote:
>
> The current plan appears to be that 1.8 will be the next LTS, with 1.4 
> keeping security support until 6 months after 1.8's release. We will be 
> having a core meeting in 10 days in Amsterdam, I'll make sure it's 
> finalised.
>
> Marc
>
> On 5 November 2014 14:55, Rob Yates > 
> wrote:
>
>> On Monday, August 25, 2014 6:10:52 AM UTC-4, Aymeric Augustin wrote:
>>>
>>>
>>> 1.4 is LTS until March 2015. Based on past release schedules, 1.8 should 
>>> be released a few months later.
>>>
>>> We could extend 1.4 support a bit and then make 1.8 the next LTS. In my 
>>> opinion, that's the most reasonable plan. 
>>>
>>> That said, Russell rightly points out that we haven't made a definitive 
>>> decision yet. 
>>>
>>
>> I really hate to dig up an old thread, but was curious if there were 
>> additional discussions or decisions regarding LTS.  As much as our large, 
>> commercial project would love to stay on the cutting edge, our maintenance 
>> scenarios require that we settle in on a release for awhile.  
>>
>> I'm concerned that we will soon have no supported LTS version and no 
>> recommendation for which previously-released version to settle on until a 
>> new LTS release is announced.  Does anyone have any recommendations?  
>> Thanks in advance for any guidance you can provide!
>>
>> -Rob
>>
>> -- 
>> 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-develop...@googlegroups.com .
>> To post to this group, send email to django-d...@googlegroups.com 
>> .
>> Visit this group at http://groups.google.com/group/django-developers.
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/django-developers/e9d76b6d-9dea-45b0-8676-c3b1f2e05c82%40googlegroups.com
>>  
>> 
>> .
>>
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/b24f49e3-495e-4d14-acf0-49d8409a047d%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Multiple template engines for Django - week 4 - DEP ready for review!

[Tim Graham]

Hi Aymeric,

Nice work on the DEP. I tend to agree with Carl that I like a 'NAME' key in 
TEMPLATES rather than requiring the use of OrderedDict, but I can also see 
why you don't. I think it might simply the implementation if TEMPLATES was 
always a list of dictionaries rather than allowing it to be a dict or an 
OrderedDict. But if you decide not to go that route: if Django iterates 
over a plain dict to select a template, it seems that could result in some 
weird performance issues, e.g. if a page that expects template loader 'A' 
and sometimes tries 'A' as the first loader, sometimes as the second, etc 
(assuming there is some performance penalty for trying a loader and not 
finding the template). If it were me, I think I'd always enforce ordering 
if len(TEMPLATES) > 1 as Carl suggested. If the only downside is the 
ugliness of OrderedDict, well I think it might save some headaches and 
support queries.

Tim

On Wednesday, November 5, 2014 5:45:09 PM UTC-5, Aymeric Augustin wrote:
>
> > On 5 nov. 2014, at 09:42, Aymeric Augustin <
> aymeric@polytechnique.org > wrote: 
> > 
> > I'll let you know when I have a specification ready for review. 
>
>
> I just pushed an implementation plan for shortcuts and template responses. 
>
> Search for `render(request, template_name` in the DEP or look at the 
> history in 
>
> https://github.com/aaugustin/mtefd/commits/master/multiple-template-engines.rst
>  
>
> -- 
> Aymeric.

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/75c9709e-fcb4-4304-be42-63c7412fb66c%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Cleaning up broken pipe errors in runserver

[Tim Graham]

An opinion from Emil Stenström posted on the pull request (I'm inclined to 
agree with it unless there are objections or if someone can propose another 
solution):

I agree that we should use the latest version of handle() from CPython to 
make sure we are as protected as we can be, even when using runserver in 
production. I see this as a one-time copy from the python standard library. 
There was one change from 2006 - 2014, so we could expect another change 
somewhere around 2022.

The trade-off here: avoiding confusion for Django beginners (I've got 
questions about this from at least three different people), vs. copying 14 
lines from a relatively stable standard library method, is worth it.

So if we update the the latest CPython version of handle() I'm +1.
On Tuesday, November 4, 2014 10:54:12 AM UTC+1, Steve Jalim wrote:
>
> Naive / over-obvious suggestion: if there's a genuine stalemate, bundling 
> the changes into a third-party app that supplants core runserver (similar 
> to how django-devserver does it) would avoid the need for individuals to 
> monkey-patch while also making it possible to release versions with more 
> significant security fixes based on changes to the underlying Python -- 
> without tying it to core Django at all. It also puts the decision on the 
> developer re whether or not to care about the "fixed" runserver being 
> slightly less secure.
>
> In a way, it's punting the issue, but I'm all for anything that "fixes" 
> the broken pipe handling: if the fixed runserver existed as a third party 
> app today, I'd install it. And better than the issue tanking for another 
> few years.
>
> If if then gets enough traction, that opens a case for it core 
> re-consideration, potentially. Yup? 
>
> S 
>
> On Monday, November 3, 2014 6:20:35 PM UTC, Tim Graham wrote:
>>
>> I had a look at the patch.  As I mentioned on the ticket, "I am not 
>> really happy with that patch which copies the 
>> simple_server.WSGIRequestHandler.handle() method from Python's version 
>> in order to override it. The copied version is not in sync with the latest 
>> Python and I'd prefer not to be in a position where we'd have to copy 
>> changes from there to Django."
>>
>> Matthew noted, "the change [in WSGIRequestHandler.handle()], made only 
>> last month (hence why this PR doesn't currently match it), is the only 
>> change to that function since it became part of the standard library in 
>> 2006, and is a small potential security issue that doesn't apply to a 
>> development server in any case, as that's explicitly listed as being 
>> insecure. I don't necessarily think you'd have to keep changes in sync from 
>> upstream, as I don't see there would be any changes to this function other 
>> than other tiny security issues that don't matter to a development server, 
>> but I can see you wouldn't want to be in that potential situation anyway."
>>
>> I agree with that, however, many people do use runserver in production 
>> and several members of the core team feel we should fix security issues 
>> with runserver even though the docs say it's not hardened for production 
>> use (I'm not one of them). Any more opinions on how to proceed here?
>>
>> On Wednesday, August 27, 2014 12:52:38 PM UTC-4, Richard Eames wrote:
>>>
>>> I'm +1 for this, for the same reasons; I have a monkey patch for my 
>>> selenium tests which does the same thing as this PR.
>>>
>>> On Saturday, 2 August 2014 18:20:18 UTC-6, Matthew Somerville wrote:
>>>>
>>>> Hi,
>>>>
>>>> I have created a branch at 
>>>> https://github.com/dracos/django/compare/pipe-cleaning that builds 
>>>> upon a previous patch posted to this list and outputs "Broken pipe" 
>>>> instead 
>>>> of a traceback for such an error. As the history below shows, practically 
>>>> speaking all reports of broken pipe tracebacks in the log are due to the 
>>>> browser cutting off output, and are not helpful to be shown as a full 
>>>> traceback. I get them frequently (e.g. hit refresh before your previous 
>>>> page has finished loading to sometimes get it), and find them annoying.
>>>>
>>>> I am posting here because ticket # - 
>>>> https://code.djangoproject.com/ticket/ - is marked wontfix. I am 
>>>> not "imagei" on that ticket, I just came across the ticket recently whilst 
>>>> trying to work out why my Selenium tests on Travis were failing w

Fellow Report - November 7, 2014

[Tim Graham]

Sorry for the delayed report. I am traveling in Warsaw, Krakow, and 
Amsterdam until next week and my work on Django will be limited.


Report for week ending November 7, 2014:

In addition to the work below, I added a machine to our CI cluster running 
Ubuntu 14.04 which contains newer databases and versions of GIS 
dependencies. Currently there is one build which uses it: 
"django-master-trusty". Considering Marc Tamlyn's contrib.postgres work 
requires a newer version of Postgres than what's bundled with 12.04, I'll 
likely switch a few Jenkins slaves over to 14.04 so those machines become 
standard for newer versions of Django and the pull request builder.

Following up on the possible Python change that could break future versions 
of Django [1], it looks like it will only be fixed in Python 3.5, so we 
won't need to backport a fix to all supported versions of Django. In 
testing the proposed patch for Python, I created a ticket [3] and remedied 
one issue when running Django's test suite with cpython's default branch 
(3.5 pre-alpha).

[1] http://bugs.python.org/issue22796
[2] https://code.djangoproject.com/ticket/23730
[3] https://code.djangoproject.com/ticket/23763

Triaged

---

https://code.djangoproject.com/ticket/23754 - DisallowedModelAdminToField 
when using get_inline_instances() (accepted)

https://code.djangoproject.com/ticket/23751 - Code snippets display without 
formatting in PDF version of the docs (accepted)

https://code.djangoproject.com/ticket/23743 - Add markup support to 
flatpages (won’t fix)

https://code.djangoproject.com/ticket/23746 - Allow assertNumQueries to 
clear caches before it runs (accepted)

https://code.djangoproject.com/ticket/23756 - Fall DST change breaks 
timezone.py make_aware (invalid)

https://code.djangoproject.com/ticket/23741 - [System Check for migrations] 
Check presence of all foreign keys (accepted)

https://code.djangoproject.com/ticket/23760 - ModelForm wrong default value 
on field without fields Meta attribute neither initial data. (invalid)

https://code.djangoproject.com/ticket/22726 - Prevent setting nullable 
relations on unsaved objects (duplicate)

https://code.djangoproject.com/ticket/23762 - 
CACHE_MIDDLEWARE_ANONYMOUS_ONLY deprecation period was only partial 
(accepted)

https://code.djangoproject.com/ticket/23767 - Add setting to toggle 
timezone warnings in Django admin (won’t fix)

https://code.djangoproject.com/ticket/23779 - Can't use unique_together if 
one of the fields is in a mixin (invalid)

https://code.djangoproject.com/ticket/23778 - Running tests outside the 
test runner needs clarification (accepted)

https://code.djangoproject.com/ticket/23773 - 
Client().post("/someurl",data="", content_type='text/plain') results in 
request.body = {} (duplicate)

Authored



https://github.com/django/django/pull/3468 -- Updated six to 1.8.0.

Reviewed/committed

--

https://github.com/django/django/pull/3456 - Moved CSRF docs out of contrib.

https://github.com/django/django/pull/3454 - Fixed #18456 --Added path 
escaping to HttpRequest.get_full_path()

https://github.com/django/django/pull/3432 - Fixed #23620 -- Used more 
specific assertions in the Django test suite.

https://github.com/django/django/pull/2545 - Fixed #18523 -- Added 
stream-like API to HttpResponse.

https://github.com/django/django/pull/3453 - Made override_settings act at 
class level when used as a TestCase decorator.

https://github.com/django/django/pull/3341 - Fixed #23300 -- 
TestCase.assertTemplateUsed passes erroneously on an HttpResponse

https://github.com/django/django/pull/3457 - Added support for reStructured 
text in admindocs for model docstrings

https://github.com/django/django/pull/3460 - Fixed versionchanged 
indentation in docs/.

https://github.com/django/django/pull/3463 - Fixed typos using 
https://github.com/vlajos/misspell_fixer

https://github.com/django/django/pull/3466 - Fixed #23531 -- Added 
CommonMiddleware.response_redirect_class.

https://github.com/django/django/pull/3427 - Fixed #13181 -- Added support 
for callable choices to forms.ChoiceField

Reviews of core dev work



https://github.com/django/django/pull/3481 - Failure to set a memcache key 
deletes the key

In progress reviews

---

https://github.com/django/django/pull/3473 - Fixed #23750 -- 
django.core.checks.register can now be used as function 

https://github.com/django/django/pull/3479 - Fixed #11919 -- Added a 
DPASTE_URL setting

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.googl

Re: Running flake8 on pull requests

[Tim Graham]

Yes, I think so. It's been on my list of things to look into for some time. 
Thanks for the nudge.

On Tuesday, November 11, 2014 10:41:02 PM UTC+1, Aymeric Augustin wrote:
>
> Hello, 
>
> Since we started using flake8, we made many small commits to fix glitches. 
>
> Would it be possible to run flake8 on Jenkins when testing pull requests? 
>
> I think that would help. 
>
> -- 
> Aymeric. 
>
>
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/5b18ea62-cc47-4add-9660-fe6f9632c1fa%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Fellow Report - November 14, 2014

[Tim Graham]

Today at “Django Under the Hood” sprints, one of the major features that we 
expected for 1.8 was merged. Josh Smeaton has been working on “allowing 
annotations to accept all expressions” for nearly a year! You may review 
the results: 
https://github.com/django/django/commit/f59fd15c4928caf3dfcbd50f6ab47be409a43b01

Thanks to him and everyone else who’s reviewed the patch.

At the sprints, the core team had a key signing “party” so we can add more 
people to the list of those who can release Django. I hope one of the new 
releasers might be able to roll a 1.7.2 bug fix release by the end of the 
month. We also confirmed some other things like 1.8 being the next LTS, as 
Aymeric shared in the “1.8 release planning” thread.

I’ve also spent some time testing the work I’ve been doing to update 
djangoproject.org to Django 1.7: 
https://github.com/django/djangoproject.com/pull/82

My time has been again been limited by travel this week, but I’ll be back 
to a normal schedule by the second half of this week. We have a lot of pull 
requests from the sprints that need review! 


Don't forget that anyone is welcome to do review and mark a ticket as 
"ready for checkin" if it meets the criteria described in our patch review 
checklist 

.

Report for week ending November 14, 2014:

Triaged

---

https://code.djangoproject.com/ticket/23801 -- Warn when max_length is used 
with IntegerField (accepted)

https://code.djangoproject.com/ticket/23811 -- Document how to use git 
bisect with runtests.py (created)

https://code.djangoproject.com/ticket/23806 - 
settings.DISALLOWED_USER_AGENTS has no tests (created)

https://code.djangoproject.com/ticket/23812 - Use 
django.utils.six.moves.range instead of xrange (created)

https://code.djangoproject.com/ticket/23807 - Postgres backend throws error 
when coercing psycopg2 version string to int when version contains 
non-numeric characters (accepted)

https://code.djangoproject.com/ticket/23813 - Add checks for common 
URLpattern errors (accepted)

Authored



https://github.com/django/django/pull/3552 - Designated Django 1.8 as the 
next LTS.

https://github.com/django/django/commit/c24a2e6cbd391c0d6359fce00e6390de9af9d2d0
 
- Fixed #23765 -- Removed BooleanField default check which often yielded 
false positives.

Reviewed/committed

--

https://github.com/django/django/pull/3473 - Fixed #23750 -- 
django.core.checks.register can now be used as function

https://github.com/django/django/pull/3482 - Fixed #23775 -- Added docs for 
--bisect and --pair runtests options.

https://github.com/django/django/pull/3504 - Fixed #23806 -- Added a test 
case for settings.DISALLOWED_USER_AGENTS.

https://github.com/django/django/pull/3472 - Fixed #23761 -- Fixed crash 
with MySQL validator and db_type is None.

https://github.com/django/django/pull/3510 - Fixed #22407 -- Added 
AdminEmailHandler.send_mail().

https://github.com/django/django/pull/3510 - Fixed #23665 -- Noted 
precedence of settings.USE_L10N in MONTH_DAY_FORMAT and YEAR_MONTH

https://github.com/django/django/pull/3512 - Fixed #21363 -- Added 
datetime.timedelta support to TimestampSigner.unsign()

https://github.com/django/django/pull/3523 - Fixed #23825 -- Added links 
for decorating class-based views to the CSRF docs

https://github.com/django/django/pull/3515 - Fixed #23808 -- Documented 
that migrations table is created when using runserver without migrating 
first.

Reviews of core dev work


https://github.com/django/django/pull/3503 - Fixed #23795 -- Fixed a 
regression in custom form fields

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/6d92d3f6-6fcc-4841-ba70-32253f4d8823%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Documenting reporting errors on individual fields in Model.clean (#16986)

[Tim Graham]

The reasoning for why it wasn't documented is provided here: 
https://github.com/django/django/pull/1443#issuecomment-28045150

On Monday, November 17, 2014 5:21:33 PM UTC+1, Carl Meyer wrote:
>
> Hi Alasdair, 
>
> On 11/17/2014 09:05 AM, Alasdair Nicol wrote: 
> > Ticket #16986 (Model.clean cannot report errors on individual fields) 
> > was fixed in Django 1.7, but the new feature is not documented. The 
> > Model.clean() docs still state: 
> > 
> >> Any ValidationError exceptions raised by Model.clean() will be stored 
> >> in a special key error dictionary key, NON_FIELD_ERRORS, that is used 
> >> for errors that are tied to the entire model instead of to a specific 
> >> field 
> > 
> > The syntax to report an error on an individual field is to pass a dict 
> > to the ValidationError constructor. 
> > 
> >> def clean(self): 
> >>if self.name1 == 'FORBIDDEN_VALUE': 
> >>raise ValidationError({'name1': [ValidationError('Model.clean() 
> > error messages.')]}) 
> > 
> > However, this is a private API. There seemed to be some debate in ticket 
> > #20867 about whether or not to document it. 
> > 
> > I'd be happy work on a patch to update the documentation, but I wanted 
> > to check that it is ok to document this API. 
>
> I think this should be documented. It's a good use case, and a 
> reasonable API for it. Several people asked in both #16986 and #20867 
> about documenting it, and it looks to me like the general tone was in 
> favor. Nobody spoke against it, but nobody ever gave a firm answer so 
> nothing happened. 
>
> 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 http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/b35556ab-1a4a-46a2-96f6-a8593c114c92%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Request for removal: Mysql warnings get promoted to Exceptions in debug mode

[Tim Graham]

Just to close the loop, I created a ticket and will commit shortly: 
https://code.djangoproject.com/ticket/23871

On Monday, November 17, 2014 5:44:35 AM UTC-5, Florian Apolloner wrote:
>
>
>
> On Monday, November 17, 2014 11:40:15 AM UTC+1, Aymeric Augustin wrote:
>>
>> 2014-11-17 10:45 GMT+01:00 Florian Apolloner :
>>
>>> Imo we should make those exceptions instead! Data truncation should 
>>> never be just a warning ;)
>>>
>>
>> Those who think like you can use a database instead of MySQL ;-)
>>
>
> Touché :)
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/e4270363-f7d1-4399-95a4-7cd7c03d59a3%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Explicit relative imports

[Tim Graham]

I hope to get flake8 running on pull request builds soon. Then (unless 
there are objections) I will take a look at isort and see if it'll work for 
us in a similar fashion. From my perspective it would be great to get those 
checks automated so it's one less thing to think about during code reviews.

On Saturday, November 15, 2014 3:29:21 PM UTC-5, tomv wrote:
>
> Tom, there's another way to remove confusion/decision making about import 
> ordering: https://pypi.python.org/pypi/isort 
>
> For Django it could be mentioned on the contrib docs and `isort 
> --check-only` run with flake8.
>
> On Thursday, 13 November 2014 14:57:15 UTC+1, Tom Christie wrote:
>>
>> Contrary voice here, but I don't dig explicit relative imports, it's just 
>> adds an extra decision point for no real benefit.
>>
>> Personally I always recommend full absolute imports, ordered strictly 
>> alphabetically - there's then never any room for confusion or decision 
>> making around how the imports should be written, and it's always tidy and 
>> consistent.
>>
>> Not looking to necessarily change the Django project's stance on that, 
>> but that's the style I use throughout my projects and it's trivial to stick 
>> to. 
>>
>> Cheers,
>>
>>   Tom
>>
>> On Wednesday, 12 November 2014 21:59:42 UTC, Jannis Leidel wrote:
>>>
>>>
>>> > On 11 Nov 2014, at 22:51, Aymeric Augustin <
>>> aymeric@polytechnique.org> wrote: 
>>> > 
>>> > Hello, 
>>> > 
>>> > We’ve started using explicit relative imports in newer parts of the 
>>> Django source tree. They’re short and readable. That’s good. 
>>> > 
>>> > I would like to add guidelines about imports in the coding style guide 
>>> in order to improve consistency. 
>>> > 
>>> > My inclination would be to recommend relative imports within 
>>> “components” but avoid them between “components”, where a component is: 
>>> > 
>>> > - a well-defined sub-framework (django.core.cache, django.db, 
>>> django.forms, django.template, etc.) 
>>> > - a contrib app 
>>> > - an app in the tests/ directory 
>>> > - etc. 
>>> > 
>>> > I would discourage going back into parent modules with relative 
>>> imports because statements such as `from ...spam import eggs` are hard to 
>>> parse. 
>>> > 
>>> > You can see an example of this style in django.apps which has only 
>>> three files. 
>>> > 
>>> > What do you think? 
>>>
>>> Yup, the way to go. 
>>>
>>> Jannis
>>
>>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/7dbf6a36-783d-47e9-83b5-2a38b42c5006%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Fellow Report - November 21, 2014

[Tim Graham]

I’m back to a more normal schedule as of the middle of this week after 
traveling. I’ve been busy trying to clear the “Ready for Checkin” queue. 
It’s great to see more people outside of the core team reviewing patches 
and marking them as RFC.

Yesterday I deployed the Django 1.7 update to djangoproject.org. So far, 
nothing broken has come to our attention as a result of the update.

I also spent some time reviewing the new formtools repo that Jannis has 
worked on (we are moving formtools out of contrib for those who might not 
be aware). I’m sure it could use a few more eyes before we do an initial 
release: https://github.com/django/django-formtools

Finally, I got an initial version of flake8 integration with pull requests 
working. The SQLite/Python 2.7 build will indicate a failure if there are 
any errors, however, you have to click through to see the errors, so it 
would be nice if we can get a better UI, like comment on the PR with the 
errors. I’d think there’s probably a plug-in for this.

Report for week ending November 21, 2014:

Triaged

---

https://code.djangoproject.com/ticket/23848 -- Creating requirements.txt 
file in default django-admin.py startproject template (won’t fix)

https://code.djangoproject.com/ticket/23830 - Make expired session clearing 
on database backend scale better (works for me)

https://code.djangoproject.com/ticket/23868 - dumpdata options 
documentation isn't correctly formatted for some options (accepted)

https://code.djangoproject.com/ticket/23885 - Docs search view throws an 
exception when accessed via GET (created)

https://code.djangoproject.com/ticket/23886 - Accessing obsolete 
documentation page throws an exception (created)

https://code.djangoproject.com/ticket/23887 - Invalid multipart boundary 
causes internal server error (created)

https://code.djangoproject.com/ticket/23890 - Deprecation warning with 
numpy 1.8+ (created)

https://code.djangoproject.com/ticket/23851 - 'GenericForeignKey' object 
has no attribute 'deconstruct' (works for me)

https://code.djangoproject.com/ticket/23893 - naive dateime warning running 
tests with MySQL (created)


Authored



https://github.com/django/django/pull/3577 - Fixed #23871 -- Removed 
promotion of MySQL warnings to errors in DEBUG mode. 


Reviewed/committed

--

https://github.com/django/django/pull/3556 - Reordered condition to avoid 
calling allow_migrate() if unneeded.

https://github.com/django/django/pull/3551 - Avoided unneeded calls to 
state.render() in migrations.

https://github.com/django/django/pull/3519 - Moved bilateral transform 
fetching to models.lookups

https://github.com/django/django/pull/3564 - Cleaned up autodetector tests

https://github.com/django/django/pull/3572 - Fixed 22248 -- Fixed backwards 
model renaming

https://github.com/django/django/pull/3548 - Fixed #21612 -- Made 
QuerySet.update() respect to_field

https://github.com/django/django/pull/3582 - Fixed #12098 -- Simplified 
HttpRequest.__repr__().

https://github.com/django/django/pull/3507 - Fixed #23817 -- updated docs 
on QuerySet evaluation

https://github.com/django/django/pull/3546 - Fixed #23844 -- Used 
topological sort for migration operation dependency resolution

https://github.com/django/django/pull/3323 - Fixed #23605 -- added 
relabeled_clone() method to sql.Query

https://github.com/django/django/pull/3498 - Fixed #23796 -- Reduced 
reduce() usage

https://github.com/django/django/pull/3533 - Fixed #23794 -- Fixed 
migrations crash when removing a field that's part of a 
index/unique_together constraint.

https://github.com/django/django/pull/3571 - Fixed #23863 -- Made runtests 
accept the keepdb option.

https://github.com/django/django/pull/3573 - Fixed #23865 -- documented how 
to assign errors to a field in Model.clean()

https://github.com/django/django/pull/3518 - Fixed #21753 -- Raised 
exception when both `form_class` and `fields` are specified.

https://github.com/django/django/pull/3565 - Fixed #23862 -- Made 
ManyToManyRel.get_related_field() respect to_field.

Reviews of core dev work



https://github.com/django/django/pull/3575 - Remove manual caching in 
globals

https://github.com/django/django/pull/3569 - Deprecated calling a 
SQLCompiler instance.

https://github.com/django/django/pull/3562 - Fixed #23410 -- Avoided 
unnecessary rollbacks in related apps when migrating backwards.

https://github.com/django/django/pull/3555 - Cleanup template loaders

In progress reviews

---

https://github.com/django/django/pull/2882 - Fixed #901 -- Added 
Model.refresh_from_db() method
https://github.com/django/django/pull/3597 - Fixed #21587 -- Added a 
deprecation warning for RedirectView.permanent.

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

does django-admin need a man page?

[Tim Graham]

I raised the issue in #23903  
and Aymeric mentioned that it may be useful for downstream packagers, e.g. 
Debian. I installed python-django via apt-get on Ubuntu 14.04 and confirmed 
the existence of the man page. I'd like to remove it though (or make it 
point people to 'django-admin --help') as it's out-of-date and 
'django-admin --help' provides the same information in a much easier to 
maintain format. Does anyone else have input on 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 post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/ff53d919-afed-4d59-8a2e-681d6a84fb98%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

review request for anyone who likes regular expression (increasing URLs accepted by URLValidator)

[Tim Graham]

Danilo Bargen has done some work to expand the types of URLs accepted by 
URLValidator. His patch adds support for IPv6 addresses, unicode domains, 
and URLs containing authentication data. This has increased the complexity 
of the regular expression quite a bit and I would appreciate if any experts 
in this area could review the pull request.

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/c197df45-86a5-4750-8af4-775c4d9f800c%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Adding hard dependencies to Django's test suite

[Tim Graham]

There have been some proposals to add new dependencies in Django's test 
suite:

1. #23289  - unittest.mock 
(included in Python 3.3+; a backport version would need be installed when 
testing on Python 2.7 and 3.2)
2. #23792  - freezegun (to 
freeze time.time() and fix some non-deterministic tests, rather than create 
our own "poor freezegun" utility in django.test)

Our current policy is that all test dependencies are optional and if they 
aren't installed, the test is skipped. I'd like to think that Python 
packaging is mature enough that we could consider adding some "hard 
dependencies" like the above (and perhaps removing the existing skip 
requirement entirely) such that runtests.py would thrown an error if it 
doesn't find any required dependencies rather than continue down the path 
of skipping tests which can be tedious. We have the test dependencies in 
requirements files (see tests/requirements) so installing the dependencies 
is fairly painless using pip.

While I know the idea that you can simply clone Django and run the tests 
straight away is appealing, I believe the fact that Python 3.4 includes pip 
and virtualenv should allow us to move forward here. If this nudges people 
to contribute to Django using Python 3 in their local environment, I'd 
consider that a win. If the Django Girls tutorial can use Python 3 (albeit 
with the help of a coach), I'd think Django's contributing docs could take 
this approach as well.

What do you think?

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/df1b45c7-55e7-4d56-b4fa-763a211fdb5a%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

delegating our static file serving

[Tim Graham]

Berker has worked on integrating gunicorn with runserver 
 so that we might be able to 
deprecate our own homegrown webserver. Windows support for gunicorn is 
supposedly coming soon which 
may actually make the idea feasible. This way we provide a more secure 
solution out of the box (anecdotes indicate that runserver is widely used 
in production despite our documentation warnings against doing so).

On the pull request, Anssi had an idea to use dj-static 
 to serve static/media files. My 
understanding is that we would basically integrate the code for dj-static 
into Django and then add a dependency on static 
. It could be an optional dependency 
since you might want to serve static files differently in production, but 
it would likely be more or less universally used in development. We could 
then say that django.views.static.serve (and its counterpart in 
staticfiles) is okay to use in production (and I guess people are already 
using them in production despite our warnings that they are not hardened 
for production use).

What do you think of this plan?

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/5f1efe14-5858-4fb0-ac39-7f4fd582cd31%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Fellow Report - November 28, 2014

[Tim Graham]

I did a lot of review this week and cleared the "ready for checkin" queue 
after falling behind a bit during travel earlier in the month. I hope we'll 
be able to release 1.7.2 next week, so please submit a patch for any of the 
release 
blockers affecting 1.7 

 
if you are interested in seeing them fixed for this release.

The unreviewed ticket queue 

 
is down to a handful of tickets including 3 tickets regarding 
javascript_catalog which have been languishing for several months. If 
anyone has an interest in this area, it would be great to get some feedback 
on them. If not, I suppose I can take a look, although I haven't done any 
work in that area.

Report for week ending November 28, 2014:

Triaged

---

https://code.djangoproject.com/ticket/23903 - Update 
docs/man/django-admin.1 (created)

https://code.djangoproject.com/ticket/23857 - "Save as new" breaks when 
related inlines are marked to be deleted (accepted) 

https://code.djangoproject.com/ticket/23791 - Subqueries with non-"id" 
OneToOneField primary keys try to join against the wrong column name 
(accepted)

https://code.djangoproject.com/ticket/23921 - Can't hide a hidden field in 
the django admin (invalid)

https://code.djangoproject.com/ticket/23792 - Create contextmanager to 
freeze time.time() in tests (accepted)

https://code.djangoproject.com/ticket/23901 - Document how to use 
spatialite with homebrew (accepted)

https://code.djangoproject.com/ticket/23910 - Add reply_to parameter to 
EmailMessage (accepted)

https://code.djangoproject.com/ticket/23749 - Document how to get the 
database alias in migrations (accepted)

https://code.djangoproject.com/ticket/23917 - Runtime Conflict models 
message (invalid)

https://code.djangoproject.com/ticket/23755 - patch_cache_control should 
special case "no-cache" (accepted)

https://code.djangoproject.com/ticket/23925 - 
django.contrib.auth.authenticate sets the wrong backend path (accepted)

https://code.djangoproject.com/ticket/23920 - MySQL: migrate TextField() to 
TextField(blank=True) fails (accepted)

Authored



https://github.com/django/django/pull/3611 - Removed workaround for lack of 
os.getpid() in Jython.

https://github.com/django/django/commit/379431ef91023f47797a29bb0931685033c24827
 
- Updated GIS docs to use doc links. 

https://github.com/django/django/pull/3626 - Fixed #23923 -- Promoted 
Django's deprecation warnings to errors in runtests.py

https://github.com/django/django/pull/3649 - Fixed #23289 -- Added mock as 
a test dependency.

Reviewed/committed

--

https://github.com/django/django/pull/3517 -  Fixed #23543 -- Added 
documentation on testing management output.

https://github.com/django/django/pull/3598 - Updated testing documentation 
following 498ae3a36069e2d

https://github.com/django/django/pull/3606 - Fixed #13694 -- Made 
SafeMIMEText's constructor compatible with MIMEText.

https://github.com/django/django/pull/3594 - Fixed #23888 -- Fixed crash in 
File.__repr__() when name contains unicode.

https://github.com/django/django/pull/3543 - Fixed #23742 -- Added an 
option to reverse tests order.

https://github.com/django/django/pull/3597 - Fixed #21587 -- Added a 
warning for changing default of RedirectView.permanent.

https://github.com/django/django/pull/3613 - Fixed #23899 -- Added 
'Generated by Django X.Y' to startproject template.

https://github.com/django/django/pull/3537 - Fixed #23682 -- Enhanced 
circular redirects detection in tests.

https://github.com/django/django/pull/3619 - Fixed #23898 -- Added missing 
context to admin's deleted_selected view.

https://github.com/django/django/pull/3568 - Fixed #23754 -- Always allowed 
reference to the primary key in the admin

https://github.com/django/django/pull/3625 - Fixed #23901 -- Added how to 
use Homebrew for installing SpatiaLite

https://github.com/django/django/pull/3570 - Fixed #23867 -- removed 
DateQuerySet hacks

https://github.com/django/django/pull/3583 - Fixed #23875 -- cleaned up 
query.get_count()

https://github.com/django/django/pull/3585 - Fixed #23877 -- aggregation's 
subquery missed target col

https://github.com/django/django/pull/3486 - Fixed #14664 -- Logged a 
warning if MiddlewareNotUsed is raised in DEBUG mode.

https://github.com/django/django/pull/3620 - Fixed #23801 -- Added warning 
when max_length is used with IntegerField

https://github.com/django/django/pull/3426 - Fixed #23641 -- Moved 
post_migrate signals registration for contrib apps to AppConfig.ready

https://github.com/django/django/pull/3262 - Fixed #23338 -- Added warning 
when unique=True on ForeigKey

https://github.com/django/django/pull/3624 - Fixed #23910 -- Added reply_to 
parameter to EmailMessage

https://github.com/django/django/p

Re: DB Migrations: Proposed fix for "Index name collisions after objects are renamed then re-created"

[Tim Graham]

I'm not in favor of merging expectedFailure tests:
* It adds the overhead of time running tests that we know aren't expected 
to work.
* It's more code to maintain (might go stale in the meantime anyway).
* An issue might be obsoleted (via deprecation, etc.) at some point.
* When viewing commit history, it seems clearer to add tests when fixing an 
issue rather than removing a decorator on a test (the contents of the test 
won't be easily viewable in the latter case).

We currently have < 10 tests marked as such in the test suite now. I'd like 
to audit them to check their state. Here's a ticket if anyone wants to help 
with that: https://code.djangoproject.com/ticket/23943

On Monday, December 1, 2014 12:18:31 PM UTC-5, Carl Meyer wrote:
>
> On 11/30/2014 05:54 AM, tomv wrote: 
> > It's important to note that right now, index names are not re-creatable 
> in 
> > retrospect. They rely on the names of models and fields, that are free 
> to 
> > be renamed. So a complete rethink will be needed if introspection can no 
> > longer be used for user-specified types of indexes. For example, maybe 
> the 
> > user should choose the name, which they should make unique at the app 
> > level? Or if not, Django will need to either keep a record of the 
> generated 
> > index name somewhere, or start renaming indexes to keep them up-to-date 
> > with the components in their names. 
>
> I think one way or another with the indexes DEP we will need to surface 
> the name of an index as an explicit part of its deconstructed 
> specification (just like with fields, models, etc). This implies 
> probably letting the user pick an explicit name if they want. We could 
> also keep the option of using an autogenerated default name, but in that 
> case migrations should notice if that autogenerated name changes and 
> generate an index-name-change operation. 
>
> > What's the best way to proceed with the index name collision ticket 
> #23577 
> >  at this point then? I 
> can: 
> > 
> >1. re-write my "use migration names in index names" branch 
> ><
> https://github.com/tomviner/django/compare/ticket_23577_with_poc_migration_name_fix>
>  
>
> >to allow index suffix names passed from migration operations? 
>
> What about having the entire index name explicitly passed from the 
> operation in migrations (even if for now its always autogenerated 
> there)? That seems like maybe a step towards where I think we'll 
> eventually need to be. (But take with a grain of salt, you've been in 
> this code and I haven't). 
>
> >2. or declare there's no consensus on the solution / we'll wait for 
> >Mark's index DEP - in which case, can I submit my tests 
> > 
> as 
> >xfails? 
>
> Hmm, that's an interesting idea. It's not something we've generally done 
> in the past, but it might be better than just letting the tests bit-rot 
> as an un-merged PR, later probably needing to be rebased. I'm curious 
> what others think of the idea of actually merging xfail tests for 
> unfixed bugs? 
>
> 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 http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/12d091f9-1a8c-4086-b5d8-b2eb004e%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: default current_app

[Tim Graham]

Hi Peter,

I am not sure if you are the original poster on that thread, but I think 
you'll get a better response here if you have a proposal for solving the 
problem that we can evaluate or a particular design decision question you 
are trying to get answered. Just asking us to look at that thread is a bit 
open-ended.

Thanks!

On Monday, December 1, 2014 3:11:17 PM UTC-5, Peter Lauri wrote:
>
> This thread was started in django-users, but commented that it should be 
> moved to developers list instead.
>
> Take a look at the original thread here: 
> https://groups.google.com/forum/#!topic/django-users/F0J6fKP1un8
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/6ebfd375-9ec0-4587-8763-85186bd77e4f%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Status of #15619: logout via POST, but not GET

[Tim Graham]

Hi Tim,

There's an open pull request , 
but it was opened over a year ago and has gone stale. Maybe you'd like to 
review and update it.

You can use the patch review checklist:

https://docs.djangoproject.com/en/dev/internals/contributing/writing-code/submitting-patches/#patch-review-checklist

If you are happy with the patch after that, please mark the ticket as 
"ready for checkin" for a final review from a core developer.

Thanks!
Tim

On Wednesday, December 3, 2014 5:02:42 PM UTC-5, Tim Chase wrote:
>
> I've had a couple cases where browser link pre-fetching triggered 
> an unintended logout from my Django app (I haven't fully tracked down 
> the exact combination of triggering conditions, but I suspect they 
> similar to Israel Brewster's CherryPy issue mentioned on 
> comp.lang.python [1]) and was surprised that Django suffered the same 
> issue. 
>
> Researching, I found https://code.djangoproject.com/ticket/15619 
> but see that it was last modified ~10mo ago, having been opened ~4yrs 
> ago.  The current (development HEAD from git) versions of 
>
>   django/contrib/auth/views.py:logout() 
>   django/contrib/auth/__init__.py:logout() 
>
> still don't seem to contain any checks to ensure logouts can only 
> happen via POST rather than GET requests. 
>
> Is there any movement forward on resolving this so my browser 
> doesn't inconveniently boot me from the app when I don't intend to 
> log out? 
>
> -tkc 
>
> [1] 
> https://mail.python.org/pipermail/python-list/2014-December/682106.html 
>
>
>
>
>
>
> . 
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/c888627a-d1da-4755-ad77-055b7837c2e2%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Status of #15619: logout via POST, but not GET

[Tim Graham]

I think you're thinking of https://code.djangoproject.com/ticket/17209. The 
latest patch appears to allow logout via GET, but even it enforced POST, 
there are still client-side (template) updates required to turn the logout 
links into form submissions so I think it should be considered an 
independent task (I may be missing your reasoning).

On Wednesday, December 3, 2014 6:48:48 PM UTC-5, Curtis Maloney wrote:
>
> Wasn't there a PR to turn all the auth views to CBV?
>
> That would implicitly enforce the behaviour to POST-only, I would hope.
>
> --
> Curtis
>
>
> On 4 December 2014 at 09:52, Tim Graham > 
> wrote:
>
>> Hi Tim,
>>
>> There's an open pull request <https://github.com/django/django/pull/1934>, 
>> but it was opened over a year ago and has gone stale. Maybe you'd like to 
>> review and update it.
>>
>> You can use the patch review checklist:
>>
>>
>> https://docs.djangoproject.com/en/dev/internals/contributing/writing-code/submitting-patches/#patch-review-checklist
>>
>> If you are happy with the patch after that, please mark the ticket as 
>> "ready for checkin" for a final review from a core developer.
>>
>> Thanks!
>> Tim
>>
>>
>> On Wednesday, December 3, 2014 5:02:42 PM UTC-5, Tim Chase wrote:
>>>
>>> I've had a couple cases where browser link pre-fetching triggered 
>>> an unintended logout from my Django app (I haven't fully tracked down 
>>> the exact combination of triggering conditions, but I suspect they 
>>> similar to Israel Brewster's CherryPy issue mentioned on 
>>> comp.lang.python [1]) and was surprised that Django suffered the same 
>>> issue. 
>>>
>>> Researching, I found https://code.djangoproject.com/ticket/15619 
>>> but see that it was last modified ~10mo ago, having been opened ~4yrs 
>>> ago.  The current (development HEAD from git) versions of 
>>>
>>>   django/contrib/auth/views.py:logout() 
>>>   django/contrib/auth/__init__.py:logout() 
>>>
>>> still don't seem to contain any checks to ensure logouts can only 
>>> happen via POST rather than GET requests. 
>>>
>>> Is there any movement forward on resolving this so my browser 
>>> doesn't inconveniently boot me from the app when I don't intend to 
>>> log out? 
>>>
>>> -tkc 
>>>
>>> [1] 
>>> https://mail.python.org/pipermail/python-list/2014-December/682106.html 
>>>
>>>
>>>
>>>
>>>
>>>
>>> . 
>>>
>>  -- 
>> 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-develop...@googlegroups.com .
>> To post to this group, send email to django-d...@googlegroups.com 
>> .
>> Visit this group at http://groups.google.com/group/django-developers.
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/django-developers/c888627a-d1da-4755-ad77-055b7837c2e2%40googlegroups.com
>>  
>> <https://groups.google.com/d/msgid/django-developers/c888627a-d1da-4755-ad77-055b7837c2e2%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 http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/03ade6e9-457c-4d17-a4bf-542bfed0ef4c%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Django 1.7 migrations don't respect db_table in M2M relation

[Tim Graham]

Please use Django's ticket tracker to report bugs in Django: 
https://code.djangoproject.com/newticket

Thanks!

On Saturday, December 6, 2014 8:10:42 AM UTC-5, lza...@ucs.br wrote:
>
>
> Hi,
>
> If is defined "db_table" in Meta class of a model, that you are using by 
> through, the migrations create the table with original name, dosen't 
> respect the db_table attribute defined on through model.
>
> Instead of create table name "myapp_mychoicename" it create 
> "myapp_test_company_related".
>
> class Test(models.Model):
> company_related = models.ManyToManyField(Company,
>   verbose_name='xx',
>   related_name='xxx',
>   through='TestCompany')
>
> class TestCompany(models.Model):
> test = models.ForeignKey(Test)
> company = models.ForeignKey(Company)
>
> class Meta:
> auto_created = Test
> db_table = 'myapp_mychoicename'
>
>
> Enviado via UCSMail.
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/66981e4f-7efe-4f9f-8e92-f7fae413af6b%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Fellow Report - December 5, 2014

[Tim Graham]

The release for 1.7.2 didn't happen this week as I had hoped. The team is 
still sorting out how to add new releasers. Maybe next week.


Report for week ending December 5, 2014:

Triaged

---

https://code.djangoproject.com/ticket/2394 - fastcgi with fork method got 
db error (won’t fix)

https://code.djangoproject.com/ticket/23943 - Audit tests decorated with 
unittest.expectedFailure (created)

https://code.djangoproject.com/ticket/23947 - Django's test suite does not 
pass in reverse order (created)

https://code.djangoproject.com/ticket/23952 - Don't run all template tests 
with TEMPLATE_STRING_IF_INVALID='INVALID' (created)

https://code.djangoproject.com/ticket/23944 - Django should use custom 
exceptions for errors thrown by send_mail (etc.), not smtplib.SMTPException 
(won’t fix)

https://code.djangoproject.com/ticket/23949 - Add charset to JsonResponse 
(invalid)

https://code.djangoproject.com/ticket/23965 - FieldFile doesn't mention 
inheritance (fixed)

Authored



https://github.com/django/django/pull/3672 - Fixed #23939 -- Moved session 
verification out of SessionAuthenticationMiddleware.

https://github.com/django/django/pull/3673 - Added a test to verify headers 
set by default middleware; refs #23939.

https://github.com/django/django/pull/3682 - Fixed #23857 -- Fixed admin 
crash with "save as new" and deleting inline

https://github.com/django/django/pull/3683 - Fixed #23920 -- Fixed MySQL 
crash when adding blank=True to TextField.

https://github.com/django/django/pull/3686 - Fixed #23957 -- Started 
deprecation toward requiring session verification

Reviewed/committed

--

https://github.com/django/django/pull/3646 - Fixed #23933 -- Made 
override_settings(DATABASE_ROUTERS) affect the master router.

https://github.com/django/django/pull/3657 - Refs #18586 -- Split up 
model_package.ModelPackageTests

https://github.com/django/django/pull/3641 - Fixed #23929 -- Added more 
tests for create_default_site.

https://github.com/django/django/pull/3647 - Fixed #23807 -- Ignored 
non-digits in psycopg2 version

https://github.com/django/django/pull/3659 - Fixed #23945 -- Made default 
site use the configured SITE_ID.

https://github.com/django/django/pull/3637 - Fixed #23934 -- Fixed 
regression in admin views obj parameter.

https://github.com/django/django/pull/3664 - Fixed #23946 -- Fixed 
runserver crash when socket error contains Unicode chars.

https://github.com/django/django/pull/3631- Fixed #23768 -- Rewrote 
template tests as unit tests

https://github.com/django/django/pull/3651 - Fixed #23935 -- Converted 
decimals to fixed point in utils.numberformat.format

https://github.com/django/django/pull/3668 - Fixed #23950 -- Prevented 
calling deconstruct on classes in MigrationWriter.

https://github.com/django/django/pull/3464 - Fixed #20392 -- Added 
TestCase.setUpTestData()

https://github.com/django/django/pull/3658 - Refs #18586 -- Split up 
model_inheritance.ModelInheritanceTest

https://github.com/django/django/pull/3617 - Fixed #23911 -- Added support 
for buffer file uploads in the test client

https://github.com/django/django/pull/3680 - Fixed #23958 - Rewrote filter 
tests as unit tests.

https://github.com/django/django/pull/3679 - Refs #23947 -- Django's test 
suite doesn't pass in reverse order

Reviews of core dev work



https://github.com/django/django/pull/3685 - Fixed #23954 -- Added special 
text/varchar PostgreSQL indexes in migrations
https://github.com/django/django/pull/3694 - Added RasterSource/GDALBand 
GDAL objects

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/2ec76d33-fd1b-4485-a158-e5d59e86bfcf%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Experimental APIs DEP

[Tim Graham]

I am skeptical like Carl, but it seems to me the time to introduce and 
discuss this DEP is when there is an actual feature that we think could 
benefit from this policy so we don't have to talk in hypotheticals.

On Monday, December 8, 2014 7:00:44 AM UTC-5, benjaoming wrote:
>
> Hi guys!
>
> As an external user of Django, relying on its stability, I'd like to 
> comment In general, I think this is possibly a good improvement.. but 
> possibly also a very dangerous one...
>
> On Monday, December 8, 2014 12:38:18 AM UTC+1, Russell Keith-Magee wrote:
>>
>>
>> On Sun, Dec 7, 2014 at 6:35 PM, Shai Berger  wrote:
>>
>>> I like the general idea of experimental API, although Carl and Aymeric's 
>>> notes
>>> are important: If we do this, we need to very picky in its use, or else 
>>> it
>>> just becomes an easy route to avoid committment. In particular, there 
>>> should
>>> be a hard-and-fast rule that nothing should be made an "experimental 
>>> API" if
>>> it can just be done outside of core.
>>>
>>> For the example given -- backend API -- I think that, again, Carl and 
>>> Aymeric
>>> are right; the examples I have more in mind for this are user-facing ORM
>>> features like the expressions, or custom lookups. I think it might be 
>>> better
>>> to let people play with them more, in a released version, before setting 
>>> the
>>> APIs in concrete.
>>>
>>> With that in mind, I would also reconsider adding a silent warning when 
>>> the
>>> features are used -- because, if they are for general use (as opposed to 
>>> the
>>> use of, say, 3rd-party backend developers) then there's a significant 
>>> use-case
>>> where the person who would use the API is not the person who configures 
>>> the
>>> warnings on the CI.
>>>
>>
>> To my mind, the role of this new status is closer to "provisional", 
>> rather than "experimental". It's a recognition of the fact that no matter 
>> how many times we ask for pre-release testing, the first *real* test of any 
>> API is when it sees real-world use. 
>>
>
>
> What I would fear is not so much that experimentals/provisionals end up in 
> other parts of Django itself: The Django team is well-disciplined and will 
> understand its own release protocol :)
>
> I'm more worried that the application ecology starts suffering from 
> symptoms of an experimental attitude in the Django project...
>
> This DEP would definitely have to be understood by the outside 
> app-developer: For the stability of third-party apps, app maintainers 
> should consider to put "don't use experimental APIs" in their contribution 
> guidelines and make sure to go through the painful process of rejecting 
> well-intended PRs relying on experimental components. Especially if it's 
> decided not to raise Warnings when experimental modules are imported.
>
> For the projects and applications that do use experimentals, it would be 
> nice to have a guarantee of a smooth API transition when the next Django 
> ships. DEP states that APIs can change, but that it *shouldn't* do so. If 
> stated that the API should not change, that causes for a much more 
> significant guarantee, and sets the bar reasonably high for new 
> experimental components.
>
> The amount of deprecations in Django in general is very high, and 
> currently, supporting both South and db.migrations is quite hard. So adding 
> more complexity to multi-version Django support does not sound very 
> attractive to me and should be avoided at all costs.
>
> Some suggestions for the "experimental" definition / ruleset:
>
>- API has been thoroughly agreed and is not subject to change.
>- Only stability and performance is a questionable part that makes a 
>feature experimental.
>- Internal parts of an experimental component are expected to change 
>more than usual
>- Something does not get pulled out without a deprecation warning, 
>even though it's experimental
>
> If experimental components will be allowed to change their APIs, I would 
> definitely suggest a Warning to be raised so they're kept out of the app 
> ecology.
> The relevant part of the DEP reads:
>
> Instead, an Experimental designation will allow APIs to be included in 
>> Django and released without being beholden to the full deprecation cycle.
>>
>
> If you allow that to happen, then in essence, anything can be released and 
> removed again. But there should be a clear intention when something is 
> released, that it will be made permanent, right?
>
> DEP also states:
>
> Effort will be taken to communicate to users that the APIs in question are 
>> not stable to avoid inadvertent use.
>>
>
> I don't think that's possible. If the feature is attractive, it will be 
> used.
>
> RKM wrote:
>
> due to fears over whether the public-facing API is suitable for use. 
>>
>
> This could be rephrased: Because some components do not get the exposure 
> necessary for thorough testing through the availability and use of the beta 
> releases, we need experimental componen

Re: Proposal: Prevent data loss in the admin

[Tim Graham]

Hi Rune,

It's not clear to me that a fix that's coupled to the admin is the way to 
go when this problem could exist for any model form, etc.

One ticket you didn't mention that seems like it could be a good place to 
start is https://code.djangoproject.com/ticket/16549

Tim

On Monday, December 8, 2014 8:04:30 AM UTC-5, Rune Kaagaard wrote:
>
> @Daniele
>
> I struggled a bit with how to display the error message, and your solution 
> makes perfect sense.
>
> Best,
> Rune Kaagaard
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/f1a56260-89d7-4439-aed1-9407d799f62f%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Feature request: delegate more password related operations to auth backends (#23896)

[Tim Graham]

User is only annotated with backend when calling authenticate(). On 
subsequent requests, or in non-request situations like the Python shell, 
how will you know which backend to delegate to?

How do existing LDAP backends deal with this problem? (or do they just 
ignore it?)

On Thursday, December 11, 2014 4:40:09 AM UTC-5, Roman Akopov wrote:
>
> Hello,
>
> This is my fist post, so I'm not fully aware of any posting policies you 
> have, but at least I'll try to present my ideas in clear way.
>
> *Very brief description of what I suggest:*
>
> Optionally delegate password change and password reset to authentication 
> backend.
>
> *Motivation:*
>
> Django framework is very popular and widely used not only for public, but 
> for private projects too. To make it clear, by private I mean not only 
> personal, but mostly corporate intranet projects.
>
> One of the important part of any corporate project is some kind of single 
> sing on (SSO) or, at least, integration with external authentication 
> backend. From my experience it may be any service able to validate 
> credentials. LDAP is most often used for authentication purposes, however, 
> it is not the only available choice. I had projects with authentication 
> delegated to custom HTTP web-services, SMTP, POP3 and IMAP servers, and so 
> on. Corporate intranet you have to deal with may be a zoo of unbelievably 
> non-standard software. Also, even if we’ll talk about LDAP, it may be a 
> few, more than one, LDAP servers you have to try authentication against, 
> like Active Directory and OpenLDAP.
>
> Current implementation of User model as well as standard forms, delegates 
> to backend authentication only, but not password reset or change. This 
> forces to reimplementation of user model and/or reimplementation of 
> standard forms for very common tasks, high coupling and bad architecture. 
> Also, if left as is, behavior is very inconsistent, since user is 
> authenticated against one password database (LDAP), but changes or resets 
> password in another (relational model database). And while LDAP may be 
> administered externally by standard web tools, this is not a good option 
> too, since means inconsistent user experience. And custom HTTP services 
> cannot be administered by standard tools at all.
>
> *Implementation:*
>
> As far as I can see User model is already annotated with backend field
>
> https://github.com/django/django/blob/master/django/contrib/auth/__init__.py#L75
>  
> so it is possible, and looks simple, to delegate password change and reset 
> to backend, if backend support these operations, which means 
> AbstractBaseUser.set_password method
>
> https://github.com/django/django/blob/master/django/contrib/auth/models.py#L226
>  
>
> should be refactored to two methods: reset_password and change_password 
> instead of one set_password, and these two method should delegate operation 
> to backend if supported. (set_password may be left as alias of 
> reset_password). Signatures will be
>
> def reset_password(self, new_password)
> def change_password(self, old_password, new_password)
>
> Also authentication forms
>
> https://github.com/django/django/blob/master/django/contrib/auth/models.py#L226
>  
>
> should be refactored to use these new reset_password and change_password 
> methods. There must be two methods, as change_password and reset_password 
> may not be both available, also change_password requires old password as 
> backend may require it. Returning to LDAP, there may be various policies 
> which should be respected, like not to change password too often, but reset 
> whenever you want, so we need two separate methods.
>
> *Backward compatibility:*
>
> As far as I can see change is backwards compatible. Authentication 
> backends not providing extra operations will behave old way without any 
> change.
>
> *Patch:*
>
> I wanted my design to be reviewed before I’ll try to provide any patch. 
> I'mm pretty sure I've missed something, so discussion is welcome. Also, 
> this will be my first code for Django project, so I'll probably break some 
> rules and will need some help.
> With best regards,
> Roman 
> ...

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/ba661064-25dc-48ce-9b88-e5b1df1709e4%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Error accessing the table from an app with label changed

[Tim Graham]

I guess this is your ticket here: 
https://code.djangoproject.com/ticket/23981

I couldn't reproduce the issue so please provide more details.

On Wednesday, December 10, 2014 2:19:41 PM UTC-5, Paulo Maciel wrote:
>
> I put in *db_table* the table name with the new label prefix and it 
> works, it would be better to automatically identify the new name label 
> created by AppConfig. This seems to be a bug
>
> Em quarta-feira, 10 de dezembro de 2014 17h07min15s UTC-2, Paulo Maciel 
> escreveu:
>>
>> I created an app and using AppConfig I changed the label to another name 
>> (abc to my_abc). The migration was successful and the table was created 
>> with the label prefix. But when I access the page, Django emits an error 
>> that is trying to access the table without taking into account that has 
>> changed the name of the label, it is trying to access the table "abc", but 
>> should access "my_abc".
>>
>> ProgrammingError
>> relation "abc" does not exist
>>
>> Is it a bug or am I doing something wrong?
>>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/907a6c92-a32d-40cd-b916-12317b3f6e3b%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Feature request: delegate more password related operations to auth backends (#23896)

[Tim Graham]

I haven't used external authentication backends for any projects, but I 
still think the concept of dynamically changing how the password change 
form/views work based on which backend you authenticated with is too much 
complexity. This scheme feels very brittle and I'm not sure that making 
this change in Django offers much benefit (in reduced code, for example) in 
the end.

On Thursday, December 11, 2014 2:05:22 PM UTC-5, Roman Akopov wrote:
>
> I've researched a little more, and looks like there is BACKEND_SESSION_KEY 
> so it is possible to annotate user with backend on subsequent requests.
>
> https://github.com/django/django/blob/master/django/contrib/auth/__init__.py#L169
> Look like it should be a one line fix for this like
> user.backend = backend
> I think this will not break any existing code.
>
> At non-request situations for non-authenticated User model, i.e. 
> instantiated from database, or just created and saved, we can simply 
> fallback to old behavior. Actually, I think this is correct, because a user 
> can have valid credentials in various backends simultaneously. Imagine we 
> have three backends: Model, LDAP, SMTP. So if you authenticate with 
> credentials valid for SMTP backend, you can't change password because SMTP 
> does not support this at all. It should be something like methods throwing 
> NotImplementedError. If you authenticate with credentials valid for LDAP 
> backend you can change password and that change will be performed against 
> LDAP. If you authenticate with credentials valid for Model backend you can 
> change password in model database. This looks like consistent behavior, 
> since you change password you just used to authenticate, not some other 
> password you probably even do not know about. And if no custom backend is 
> registered or no backend information is available, we fallback to default 
> one. Of course there is a question, how to reset LDAP password from admin 
> interface. The answer will be "you cannot". This looks sane for me, because 
> end-users are happy using just one software for all their tasks and LDAP 
> administrator should use LDAP tools for administrative tasks anyway, and 
> password reset is just a small one, there will be permission management, 
> group membership and all of these tools should not be doubled in Django 
> admin.
>
> On Thursday, December 11, 2014 7:49:05 PM UTC+4, Tim Graham wrote:
>>
>> User is only annotated with backend when calling authenticate(). On 
>> subsequent requests, or in non-request situations like the Python shell, 
>> how will you know which backend to delegate to?
>>
>> How do existing LDAP backends deal with this problem? (or do they just 
>> ignore it?)
>>
>> On Thursday, December 11, 2014 4:40:09 AM UTC-5, Roman Akopov wrote:
>>>
>>> Hello,
>>>
>>> This is my fist post, so I'm not fully aware of any posting policies you 
>>> have, but at least I'll try to present my ideas in clear way.
>>>
>>> *Very brief description of what I suggest:*
>>>
>>> Optionally delegate password change and password reset to authentication 
>>> backend.
>>>
>>> *Motivation:*
>>>
>>> Django framework is very popular and widely used not only for public, 
>>> but for private projects too. To make it clear, by private I mean not only 
>>> personal, but mostly corporate intranet projects.
>>>
>>> One of the important part of any corporate project is some kind of 
>>> single sing on (SSO) or, at least, integration with external authentication 
>>> backend. From my experience it may be any service able to validate 
>>> credentials. LDAP is most often used for authentication purposes, however, 
>>> it is not the only available choice. I had projects with authentication 
>>> delegated to custom HTTP web-services, SMTP, POP3 and IMAP servers, and so 
>>> on. Corporate intranet you have to deal with may be a zoo of unbelievably 
>>> non-standard software. Also, even if we’ll talk about LDAP, it may be a 
>>> few, more than one, LDAP servers you have to try authentication against, 
>>> like Active Directory and OpenLDAP.
>>>
>>> Current implementation of User model as well as standard forms, 
>>> delegates to backend authentication only, but not password reset or change. 
>>> This forces to reimplementation of user model and/or reimplementation of 
>>> standard forms for very common tasks, high coupling and bad architecture. 
>>> Also, if left as is, behavior is very inconsistent, since user is 
>>> authenticated against one password datab

Fellow Report - December 12, 2014

[Tim Graham]

Today marks one month until the scheduled alpha/feature freeze for 1.8. As 
far as I can tell, we are making good progress on the remaining major 
features that we hope to land for 1.8 (model meta refactor, multiple 
template engines, contrib.postgres).

I wanted to highlight the patch from Thomas Chaumeny to load fixtures once 
within each TestCase  which 
merged this week. It decreased the time of the Django test suite 10-15% on 
my machine.

Report for week ending December 5, 2014:

Triaged

---

https://code.djangoproject.com/ticket/23974 - Ambiguous description of save 
option of FileField.save() method (fixed)

https://code.djangoproject.com/ticket/23961 - makemigrations doesn't create 
migrations package when app_label isn't specified (accepted)

https://code.djangoproject.com/ticket/23964 - MySQL: 
BaseModelFormSet.validate_unique() fails for mixed case (accepted)

https://code.djangoproject.com/ticket/20755 - Certain cookie flags don't 
get unpickled properly (won’t fix)

https://code.djangoproject.com/ticket/23980 - DATETIME_FORMAT setting not 
applied with DjangoJSONEncoder (invalid)

https://code.djangoproject.com/ticket/23981 - Error accessing the table 
from an app with label changed (invalid)

https://code.djangoproject.com/ticket/20839 - models.py module is imported 
multiple times. (fixed)

https://code.djangoproject.com/ticket/12907 - Problems with django admin on 
Jython with custom user models (needs info)

Authored



https://github.com/django/django/pull/3711 - Fixed #23975 -- Sent 
pre_migrate signal if all apps have migrations.

https://github.com/django/django/pull/3716 - Fixed #22645 -- Restored the 
GIS models in models.py.

Reviewed/committed

--

https://github.com/django/django/pull/3707 - Refs #23964 -- Added warning 
about case-insensitive, unique fields used with formsets

https://github.com/django/django/pull/3715 - Fixed #23956 -- Fixed 
migration creation for multiple table inheritance

https://github.com/django/django/pull/3713 - Fixed #23977 -- Added 
setdefault method to HttpResponse

https://github.com/django/django/pull/3715 - Fixed #23956 -- Fixed 
migration creation for multiple table inheritance

https://github.com/django/django/pull/3493 - Refactored expressions tests. 
Refs #18586

https://github.com/django/django/pull/3491 - Refactored custom manager 
tests. Refs #18586

https://github.com/django/django/pull/3483 - Refactored custom pk tests. 
Refs #18586

https://github.com/django/django/pull/3719 - Fixed #23674 -- Fixed a crash 
when a MultiValueField has invalid data

https://github.com/django/django/pull/3681 - Refs #20392 -- Load fixtures 
once within TestCase

https://github.com/django/django/pull/3655 - Fixed #23941 -- Aggregating 
over decimal field regression

Reviews of core dev work



https://github.com/django/django/pull/3697 - Added a migrate hook for 
automatically running database setup SQL

https://github.com/django/django/pull/3712 - Fixed postgis test database 
initialization

https://github.com/django/django/pull/3718 - Fixed #23982 -- Added doc note 
on generating Python 2/3 cross-compatible migrations.

In progress reviews

---

https://github.com/django/django/pull/3710 - Fixed #23884 -- Moved 
FlatPageSitemap into django.contrib.flatpages.

https://github.com/django/django/pull/3700 - Fixed #23405 - Fixed asking 
for default value for `CharField` and `TextField` in migrations

https://github.com/django/django/pull/3687 - Fixed #23822 -- Added support 
for serializing model managers in migration

https://github.com/django/django/pull/3609 - Fixed #12982 -- Added a 
``get_or_set`` method to the BaseCache backend.

https://github.com/django/django/pull/3369 - Fixed #9893 -- Filename could 
exceed max_length on a collision

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/6ef90201-3db6-4429-a432-e03b6719df15%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Feature request: delegate more password related operations to auth backends (#23896)

[Tim Graham]

Yes, I am by no means speaking definitively on the issue -- just voicing 
some concerns that I see. I'd love if people with experience with 
third-party authentication backends would join the discussion.

On Saturday, December 13, 2014 4:28:52 AM UTC-5, Roman Akopov wrote:
>
> Tim,
>
> It's not about the benefit, it's about the possibility. The one simply 
> cannot use two external backends with support of password change because 
> each backend will have to provide own User model. I understand your point, 
> and I agree that some logic I suggest seems controversial, but current 
> implementation of plugable authentication backends is technically incomplete, 
> because password cannot be changed or reset, and ideologically broken, 
> because full functionality cannot be correctly added even with a lot of 
> code. Actually whole contrib.auth should be replaced to allow pluggable 
> authentication backends to provide password change or password reset 
> independently.
>
> Also, if you think it is good idea to force old behavior even if backend 
> supports extended functionality, what stops us from introducing two boolean 
> settings AUTHENTICATION_BACKEND_DELEGATE_PASSWORD_CHANGE and 
> AUTHENTICATION_BACKEND_DELEGATE_PASSWORD_RESET which will be False by 
> default? This will force old behavior while allowing to use extended 
> backends if required.
>
> I want it to be clear, I'm not asking for specific functionality, I'm 
> asking for extensibility. External authentication is complex subject by 
> itself and fighting with incomplete Django extensibility interface does not 
> make it simpler, but better extensibility interface does.
>
> Maybe, it will be wiser to discuss this feature request with people 
> actually using external authentication, not core developers, to let them 
> share their experience and maybe suggest better ways to implement this from 
> the users/app developers point of view. Maybe this feature is desired one, 
> but I'm just first who asked or maybe nobody actually needs it and I;m just 
> Django-pervert. I can talk about my end users only, and about theirs user 
> experience, you have no externally authenticated users at all. If we've 
> done with technical side, I mean it seems clear what should be changed at 
> source code level, and if only specific behavior logic is to be discussed, 
> maybe it is better to discuss this non-core developer question with wider 
> audience. What do you think?
>
>
> On Saturday, December 13, 2014 3:19:26 AM UTC+4, Tim Graham wrote:
>>
>> I haven't used external authentication backends for any projects, but I 
>> still think the concept of dynamically changing how the password change 
>> form/views work based on which backend you authenticated with is too much 
>> complexity. This scheme feels very brittle and I'm not sure that making 
>> this change in Django offers much benefit (in reduced code, for example) in 
>> the end.
>>
>> On Thursday, December 11, 2014 2:05:22 PM UTC-5, Roman Akopov wrote:
>>>
>>> I've researched a little more, and looks like there is 
>>> BACKEND_SESSION_KEY so it is possible to annotate user with backend on 
>>> subsequent requests.
>>>
>>> https://github.com/django/django/blob/master/django/contrib/auth/__init__.py#L169
>>> Look like it should be a one line fix for this like
>>> user.backend = backend
>>> I think this will not break any existing code.
>>>
>>> At non-request situations for non-authenticated User model, i.e. 
>>> instantiated from database, or just created and saved, we can simply 
>>> fallback to old behavior. Actually, I think this is correct, because a user 
>>> can have valid credentials in various backends simultaneously. Imagine we 
>>> have three backends: Model, LDAP, SMTP. So if you authenticate with 
>>> credentials valid for SMTP backend, you can't change password because SMTP 
>>> does not support this at all. It should be something like methods throwing 
>>> NotImplementedError. If you authenticate with credentials valid for LDAP 
>>> backend you can change password and that change will be performed against 
>>> LDAP. If you authenticate with credentials valid for Model backend you can 
>>> change password in model database. This looks like consistent behavior, 
>>> since you change password you just used to authenticate, not some other 
>>> password you probably even do not know about. And if no custom backend is 
>>> registered or no backend information is available, we fallback to default 
>>> one. Of course there is a question, how to 

Re: A case for CASE expressions and bulk_update

[Tim Graham]

Unlike in previous release cycles, we are going to try a complete feature 
freeze at alpha. The details are outlined here:

https://code.djangoproject.com/wiki/Version1.8Roadmap

On Tuesday, December 16, 2014 8:01:23 PM UTC-5, Josh Smeaton wrote:
>
> On Tuesday, 16 December 2014 18:23:29 UTC+11, Michał Modzelewski wrote:
>>
>> Sure. I was planning to work on it myself, but wanted to discuss API, 
>> passing in output_fields, and casting results first.
>> I started with 2 classes because I only needed SimpleCase first to 
>> implement the bulk_update. Later I added Case and it seemed clearer to me 
>> than the SQLAlchemy and PeeWee approach of using an optional predicate 
>> argument.
>>
>> - Michael
>>
>
> If you're still planning on working on it, then I'm happy to let you do 
> so. The 1.8 alpha freeze is coming up shortly 
> 
>  
> (Jan 12th), and I'm not sure whether new constructs will be allowed in 
> after that point or not. Can someone else clarify? It would be great to 
> have something to merge around this time though, or at least before the 
> Beta.
>
> My work on other functions is being tracked at 
> https://code.djangoproject.com/ticket/23753 and developed here 
> https://github.com/jarshwah/django/tree/ticket_23753. I'll try to have 
> these finished and merged soon (hopefully within a week, pending reviews), 
> which should give a decent base to fully complete the Case stuff.
>
> Happy to discuss API and help you out where I can. I'm always in IRC as 
> jarshwah if you'd like more immediate discussion too.
>
> Cheers
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/b818725b-f4ad-44df-9b8c-106c6b45169d%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Migrations in Django 1.7 make unit testing models harder

[Tim Graham]

Andrew, I've thought of something similar to the in-memory migrations idea 
you've proposed. It would be great not to have to add and maintain 
migrations for all of the apps in Django's test suite. Do you think you 
might be able to investigate this solution in the next month or so before 
1.8 alpha? I think we need a solution in 1.8 if we are to complete #22340 - 
Legacy 
Table Creation Methods Not Properly Deprecated (otherwise, we can again 
postpone that deprecation).

On Friday, December 19, 2014 8:17:05 AM UTC-5, Andrew Godwin wrote:
>
> I agree that migrations are slower than syncdb - that's perhaps the only 
> thing worse about them - but the reason we plan to deprecate the other 
> methods is code simplicity; migrations does not share almost any code with 
> the old DatabaseCreation backends, and if we don't deprecate it we're going 
> to end up maintaining two creation backends for every database driver, 
> which isn't going to go well.
>
> There's perhaps something to be said for an option where tests make an 
> in-memory set of migrations from the autodetector and an empty state and 
> run them immediately - somewhat replicating the syncdb process while still 
> using the same code paths - but I haven't had the time to investigate how 
> well this would work yet (there are some migration decisions that would 
> need defaults inserted).
>
> I think the end result would be an alternative test runner that you could 
> switch to if you wanted this behaviour (and a mixin with the actual logic 
> or something similar so it's easy to incorporate into other test runners).
>
> Andrew
>
> On Wed, Dec 17, 2014 at 6:59 PM, > wrote:
>>
>> At the risk of reviving an old topic, I wanted to add one significant 
>> point in favor of (and mitigation for) running tests with migrations 
>> disabled: Speed.
>>
>> Creating a test DB in sqlite for our project (~100 database tables) takes 
>> approximately 1-2 minutes on most developer machines. 1-2 minutes of 
>> idle time to run any test was just unacceptable so we disabled 
>> migrations by setting fake migrations in MIGRATION_MODULES and brought the 
>> test DB creation time down to about 5 seconds (!!).
>>
>> However the risk of committing invalid code because someone forgot to 
>> makemigrations is real. We've addressed it by only overriding migrations on 
>> our local test settings and still having migrations run on our CI server. 
>> We have our CI server use settings.test, while developers running tests on 
>> their local machine use settings.test_local which is just:
>>
>> from settings.test import *
>>
>> MIGRATION_MODULES = ((app, '%s.fake_migrations' % app) for app in 
>> INSTALLED_APPS)
>>
>>
>> This seems to get us the best of both worlds. I was surprised to read 
>> through this thread and not see other mentions of the performance 
>> implications of running migrations on every test run. I'd be curious to 
>> hear if this has been a bottleneck for other teams.
>>
>> -Chris
>>
>> On Tuesday, March 25, 2014 10:21:51 AM UTC-7, Bernie Sumption wrote:
>>
>>> Hi Django devs,
>>>
>>> I've just started a new project in 1.7b, and the development experience 
>>> working with unit tests on models is more complicated than it was in 1.6. 
>>> It's all down to how the throwaway test databases are created. In 1.6, the 
>>> create_test_db function "Creates a new test database and runs syncdb 
>>> against it." In 1.7, it runs "migrate".
>>>
>>> While generally speaking, migrate is the new syncdb, this behaviour is 
>>> not ideal for tests. In 1.6 "syncdb" created a database reflecting the 
>>> current state of the models in models.py. "migrate" creates a database 
>>> reflecting the state of the models at the last time makemigrations was run. 
>>> If you're doing TDD and constantly making small changes to your models then 
>>> runnning unit tests, you have to run makemigrations before each test run to 
>>> get your tests to work. You therefore end up with many tiny migration files 
>>> representing the minute-by-minute history of development.
>>>
>>> I came up with a pretty effective workaround that is working for me, but 
>>> I thought I'd post this here as others are sure to encounter this issue, 
>>> and I think that it makes more sense for the behaviour produced by this 
>>> workaround to be the default for running tests.
>>>
>>> If makemigrations has not yet been run, the "migrate" command treats an 
>>> app as unmigrated, and creates tables directly from the models just like 
>>> syncdb did in 1.6. I defined a new settings module just for unit tests 
>>> called "settings_test.py", which imports * from the main settings module 
>>> and adds this line:
>>>
>>> MIGRATION_MODULES = {"myapp": "myapp.migrations_not_used_in_tests"}
>>>
>>> Then I run tests like this:
>>>
>>> DJANGO_SETTINGS_MODULE="myapp.settings_test" python manage.py test
>>>
>>> This fools migrate into thinking that the app is unmigrated, and so 
>>> every time a test database is created it reflects

Re: Migrations in Django 1.7 make unit testing models harder

[Tim Graham]

Yes. Claude has worked on the deprecation in 
https://github.com/django/django/pull/3220 but it requires adding more 
migrations to our test suite and he noted that each migration we add to 
Django's test suite adds up to ~3.5 seconds to the run time of the test 
suite. He also worked on some speed ups to mitigate this in 
https://github.com/django/django/pull/3484 but there are some unsolved 
issues.

On Friday, December 19, 2014 11:03:04 AM UTC-5, Andrew Godwin wrote:
>
> Hi Tim,
>
> I can have a look, but I can't be certain about hitting any deadlines. I 
> do want to get that deprecation in, though...
>
> Did you want it with a view to us being able to drop that in for tests 
> rather than making migrations for every test app, I presume?
>
> Andrew
>
> On Fri, Dec 19, 2014 at 3:06 PM, Tim Graham  > wrote:
>>
>> Andrew, I've thought of something similar to the in-memory migrations 
>> idea you've proposed. It would be great not to have to add and maintain 
>> migrations for all of the apps in Django's test suite. Do you think you 
>> might be able to investigate this solution in the next month or so before 
>> 1.8 alpha? I think we need a solution in 1.8 if we are to complete #22340 - 
>> Legacy 
>> Table Creation Methods Not Properly Deprecated (otherwise, we can again 
>> postpone that deprecation).
>>
>> On Friday, December 19, 2014 8:17:05 AM UTC-5, Andrew Godwin wrote:
>>>
>>> I agree that migrations are slower than syncdb - that's perhaps the only 
>>> thing worse about them - but the reason we plan to deprecate the other 
>>> methods is code simplicity; migrations does not share almost any code with 
>>> the old DatabaseCreation backends, and if we don't deprecate it we're going 
>>> to end up maintaining two creation backends for every database driver, 
>>> which isn't going to go well.
>>>
>>> There's perhaps something to be said for an option where tests make an 
>>> in-memory set of migrations from the autodetector and an empty state and 
>>> run them immediately - somewhat replicating the syncdb process while still 
>>> using the same code paths - but I haven't had the time to investigate how 
>>> well this would work yet (there are some migration decisions that would 
>>> need defaults inserted).
>>>
>>> I think the end result would be an alternative test runner that you 
>>> could switch to if you wanted this behaviour (and a mixin with the actual 
>>> logic or something similar so it's easy to incorporate into other test 
>>> runners).
>>>
>>> Andrew
>>>
>>> On Wed, Dec 17, 2014 at 6:59 PM,  wrote:
>>>
>>>> At the risk of reviving an old topic, I wanted to add one significant 
>>>> point in favor of (and mitigation for) running tests with migrations 
>>>> disabled: Speed.
>>>>
>>>> Creating a test DB in sqlite for our project (~100 database tables) 
>>>> takes approximately 1-2 minutes on most developer machines. 1-2 
>>>> minutes of idle time to run any test was just unacceptable so we disabled 
>>>> migrations by setting fake migrations in MIGRATION_MODULES and brought the 
>>>> test DB creation time down to about 5 seconds (!!).
>>>>
>>>> However the risk of committing invalid code because someone forgot to 
>>>> makemigrations is real. We've addressed it by only overriding migrations 
>>>> on 
>>>> our local test settings and still having migrations run on our CI server. 
>>>> We have our CI server use settings.test, while developers running tests on 
>>>> their local machine use settings.test_local which is just:
>>>>
>>>> from settings.test import *
>>>>
>>>> MIGRATION_MODULES = ((app, '%s.fake_migrations' % app) for app in 
>>>> INSTALLED_APPS)
>>>>
>>>>
>>>> This seems to get us the best of both worlds. I was surprised to read 
>>>> through this thread and not see other mentions of the performance 
>>>> implications of running migrations on every test run. I'd be curious to 
>>>> hear if this has been a bottleneck for other teams.
>>>>
>>>> -Chris
>>>>
>>>> On Tuesday, March 25, 2014 10:21:51 AM UTC-7, Bernie Sumption wrote:
>>>>
>>>>> Hi Django devs,
>>>>>
>>>>> I've just started a new project in 1.7b, and the development 
>>>>> experience w

Re: Migrations in Django 1.7 make unit testing models harder

[Tim Graham]

I did some research, and I can hit the logic in question,

if app_label == settings.AUTH_USER_MODEL and ignore_swappable:
   continue

... on both master and with Claude's patch if I follow the steps in this 
comment: https://code.djangoproject.com/ticket/22563#comment:8

Andrew, first you added an error message to say that changing 
AUTH_USER_MODEL after creating an initial migration was invalid:
https://github.com/django/django/commit/fc974313b85da932a70f1f993b33207d78d31831

and then someone reporting hitting that error with a false positive and you 
changed it to the current version:
https://github.com/django/django/commit/5182efce8d73ec552a1d7f3e86a24369bb261044

Your comment was "I've committed a patch that suppresses the error in that 
one case (where we know it's safe to do so), and I can now switch 
AUTH_USER_MODEL even midway through a migration set without errors."

Maybe this helps refresh your memory?

On Saturday, December 20, 2014 5:53:03 AM UTC-5, Andrew Godwin wrote:
>
> Clause, I believe that line is to allow people to run makemigrations when 
> AUTH_USER_MODEL points to an app that doesn't yet have migrations; before, 
> it would fail hard, as the AUTH_USER_MODEL was not in the migrate state and 
> so nothing could use it, and you couldn't run makemigrations to create it 
> as it would error out.
>
> I'd test variations of that to see if your patch still works; if not, 
> we'll need a workaround again.
>
> Andrew
>
> On Sat, Dec 20, 2014 at 10:47 AM, Claude Paroz  > wrote:
>>
>> On Friday, December 19, 2014 6:30:32 PM UTC+1, Tim Graham wrote:
>>>
>>> Yes. Claude has worked on the deprecation in https://github.com/django/
>>> django/pull/3220 but it requires adding more migrations to our test 
>>> suite and he noted that each migration we add to Django's test suite adds 
>>> up to ~3.5 seconds to the run time of the test suite. He also worked on 
>>> some speed ups to mitigate this in https://github.com/django/
>>> django/pull/3484 but there are some unsolved issues.
>>>
>>
>> I think that the first mentioned patch I worked on (PR 3220) shows that 
>> it should be possible to use the new schema infrastructure without 
>> requiring migrations, at least for apps that don't depend on other migrated 
>> apps. Tell me if I miss anything.
>>
>> But surely, I'd really like to solve first the speed issue of migrations 
>> (#23745, PR 3484). Chris, if you have the opportunity to test that patch 
>> with your database, it would be great. The way forward for this patch is to 
>> first test the "if app_label == settings.AUTH_USER_MODEL and 
>> ignore_swappable:" line which is currently not tested and is probably not 
>> addressed by my patch. Andrew, do you remember why you introduced that part 
>> of the code?
>>
>> Claude
>>
>> -- 
>> You received this message because you are subscribed to the Google Groups 
>> "Django developers (Contributions to Django itself)" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to django-develop...@googlegroups.com .
>> To post to this group, send email to django-d...@googlegroups.com 
>> .
>> Visit this group at http://groups.google.com/group/django-developers.
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/django-developers/1f5f37b2-5309-4af6-8b3c-aa76eee3bde1%40googlegroups.com
>>  
>> <https://groups.google.com/d/msgid/django-developers/1f5f37b2-5309-4af6-8b3c-aa76eee3bde1%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 http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/60e08f9c-4292-45d3-9da8-35a5ab5f5081%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

status of 1.8 release blockers

[Tim Graham]

As we approach the date for 1.8 alpha, I plan to send a weekly update on 
the status of release blocking issues.

We currently have 3 release blockers affecting master. You can use this 
Trac filter to see them:
https://code.djangoproject.com/query?status=assigned&status=new&version=master&severity=Release+blocker

You can also see other tickets we are targeting for 1.8 with this filter. 
This includes some of the remaining large features as well as a couple code 
reorganizations we want to make closer to when cut the 1.8 branch to avoid 
creating conflicts with the large features that are in progress.
https://code.djangoproject.com/query?status=assigned&status=new&keywords=~1.8-alpha

Here is a summary of where we stand with each release blocker:

#23861 - 
 Fields referenced in 
migrations cannot be (re)moved, even if migrations have been squashed 
 Owner: ?
Status: We need someone to investigate a strategy for how we can deprecate 
model fields while keeping them available in historical migrations. Any 
takers? If we cannot complete this, I propose we bump the deprecation of 
IPAddressField until the issue is solved.

#22340 -  
 Legacy Table Creation Methods 
Not Properly Deprecated  Owner: 
Claude
Status: This issue is being discussed in the thread "Migrations in Django 
1.7 make unit testing models harder". In short, we likely to need to solve 
the performance issues with migrations before we can proceed with the 
deprecation. If we cannot, we'll likely have to delay the deprecation.

#23271 - Makemessages can 
corrupt existing .po files on Windows 

Owner: Ramiro
Status: Ramiro said he would have some time to investigate the issue soon.

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/9ac2848f-8d2d-4480-8e1c-dbd8db164e18%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Fellow Report - December 19, 2014

[Tim Graham]

The team has uploaded a new policy for django-releasers which should enable 
more members of the team to roll a release. I’m optimistic we’ll finally be 
able to get the 1.7.2 bug fix release out next week.

https://www.djangoproject.com/m/pgp/django-releasers.txt

Besides the work below, I also assisted with QA and the rollout of the new 
djangoproject.com. I also did some investigation on 1.8 release blockers 
which you can find summarized in the "status of 1.8 release blockers" 
thread on this list.


Report for week ending December 19, 2014:

Triaged

---

https://code.djangoproject.com/ticket/23995 - Remove unnecessary calls to 
self.client.logout() in tests (created)

https://code.djangoproject.com/ticket/24000 - create_default_site 'db' 
kwarg should be 'using' (accepted)

https://code.djangoproject.com/ticket/24015 - Django doesn't quote index 
names in SQL generated by migrations (accepted)

https://code.djangoproject.com/ticket/24013 - reverse() escapes unreserved 
characters supplied by prefix (accepted)

https://code.djangoproject.com/ticket/24026 - migration RunPython operation 
ignores db router allow_migrate (duplicate)

https://code.djangoproject.com/ticket/24022 - Deprecate {% ssi %} template 
tag (created)

https://code.djangoproject.com/ticket/24012 - models.UUIDfield fails on 
Oracle backend (invalid)

https://code.djangoproject.com/ticket/24032 - use has_permission instead of 
explicit is_staff for AdminSite (duplicate)

Authored



https://github.com/django/django/pull/3757 - Fixed #21414 -- Removed usage 
of RelatedObject and deprecated it. (rebased this old patch to apply 
cleanly to master)

Reviewed/committed

--

https://github.com/django/django/pull/3723 - Fixed #23812 - Changed 
django.utils.six.moves.xrange imports to range

https://github.com/django/django/pull/3732 - Fixed #23987 - Sqlite should 
always use effective_default

https://github.com/django/django/pull/3700 - Fixed #23405 - Fixed asking 
for default value for `CharField` and `TextField` in migrations

https://github.com/django/django/pull/3687 - Fixed #23822 -- Added support 
for serializing model managers in migration

https://github.com/django/django/pull/3710 - Fixed #23884 -- Moved 
FlatPageSitemap into django.contrib.flatpages.

https://github.com/django/django/pull/3726 - Fixed #23947 -- Django's test 
suite doesn't pass in reverse order with PostgreSQL

https://github.com/django/django/pull/3735 - Fixed #23983 - Fixed a crash 
in migration when adding `order_with_respect_to` to table with data

https://github.com/django/django/pull/3734 - Fixed #16028 - Moved 
defaultfilters tests into template_tests.

https://github.com/django/django/pull/3728 - Fixed #23497 -- Made admin 
system checks run for custom AdminSites.

Reviews of core dev work



https://github.com/django/django/pull/3748 - Fixed #24014 -- Unified 
OGRException and GDALException

https://github.com/django/django/pull/3758 - Made model_regress unpickling 
test CWD-independent (I also helped to debug this test on Windows)

In progress reviews

---

https://github.com/django/django/pull/3729 - Fixed #16501 -- Added a 
unicode parameter to models.SlugField and forms.SlugField.

https://github.com/django/django/pull/3634 - Fixed #22276 -- Surfaced 
ValidationError to end-user if management form is invalid
https://github.com/django/django/pull/3739 - Fixed #23998 -- Added 
datetime.time support to migrations questioner

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/cd872b6b-c9b6-43a1-bdeb-9cc0de1f4a60%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

intended security model for templates

[Tim Graham]

I was hoping to get clarification on what security model we intend to 
support for template authors. In ticket #12772 
 it's proposed to allow 
loading template tags using a dotted Python path. This would allow template 
authors to trigger imports of anything on the Python path. I am not sure 
the requirement to add a template tag library to INSTALLED_APPS is a big 
burden these days (e.g. there is no more need to create an empty models.py 
file), but perhaps I don't fully understand the ticket's rationale for 
proposing these changes.

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/643fdee1-dbc2-4113-b564-aa2fd741a0ba%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Migrations in Django 1.7 make unit testing models harder

[Tim Graham]

In pull request 3791 <https://github.com/django/django/pull/3791>, I 
started working on the code removals for Django 1.9 to better understand 
how the database/migrations code will look and what APIs we still need to 
deprecate. The good news is that we can keep support for apps without 
migrations (at least for Django's test suite) without adding any additional 
code or using any deprecated database creation APIs (as Claude suggested 
earlier). If you look at the commit "Removed supported for syncing apps 
without migrations" in that PR, you'll see "Run the syncdb phase" remains 
in the migrate management command, but now it'll only be executed when 
testing (and it's also quite a bit simplified due to other removals like 
support for initial data). It seems like it should be pretty simple to 
implement something similar to the old *SOUTH_TESTS_MIGRATE* setting in 
order to allow disabling migrations for all apps when testing if we wanted 
to go that route. I think the remaining deprecations to move forward with 
ticket 
#22340 <https://code.djangoproject.com/ticket/22340> (Legacy Table Creation 
Methods Not Properly Deprecated) are straightforward and will leave a 
comment there about it.

On Saturday, December 20, 2014 2:18:17 PM UTC-5, Aymeric Augustin wrote:
>
> There's django-admin test --keepdb for this purpose (in Django 1.8).
>
> -- 
> Aymeric.
>
> Le 20 déc. 2014 à 18:41, Bernard Sumption  > a écrit :
>
> A proposition: the problem isn't that migrations take 80 seconds, it's 
> that this 80 seconds is repeated every time a developer runs tests. How 
> about serialising the structure and content of the database to disk after 
> applying migrations, then whenever you need a migrated test database, load 
> it from disk unless the migration files have been altered since the 
> serialised version was created?
>
> Bernie :o)
>
> On 20 December 2014 at 10:52, Andrew Godwin  > wrote:
>>
>> Clause, I believe that line is to allow people to run makemigrations when 
>> AUTH_USER_MODEL points to an app that doesn't yet have migrations; before, 
>> it would fail hard, as the AUTH_USER_MODEL was not in the migrate state and 
>> so nothing could use it, and you couldn't run makemigrations to create it 
>> as it would error out.
>>
>> I'd test variations of that to see if your patch still works; if not, 
>> we'll need a workaround again.
>>
>> Andrew
>>
>> On Sat, Dec 20, 2014 at 10:47 AM, Claude Paroz > > wrote:
>>>
>>> On Friday, December 19, 2014 6:30:32 PM UTC+1, Tim Graham wrote:
>>>>
>>>> Yes. Claude has worked on the deprecation in https://github.com/django/
>>>> django/pull/3220 but it requires adding more migrations to our test 
>>>> suite and he noted that each migration we add to Django's test suite adds 
>>>> up to ~3.5 seconds to the run time of the test suite. He also worked on 
>>>> some speed ups to mitigate this in https://github.com/django/
>>>> django/pull/3484 but there are some unsolved issues.
>>>>
>>>
>>> I think that the first mentioned patch I worked on (PR 3220) shows that 
>>> it should be possible to use the new schema infrastructure without 
>>> requiring migrations, at least for apps that don't depend on other migrated 
>>> apps. Tell me if I miss anything.
>>>
>>> But surely, I'd really like to solve first the speed issue of migrations 
>>> (#23745, PR 3484). Chris, if you have the opportunity to test that patch 
>>> with your database, it would be great. The way forward for this patch is to 
>>> first test the "if app_label == settings.AUTH_USER_MODEL and 
>>> ignore_swappable:" line which is currently not tested and is probably not 
>>> addressed by my patch. Andrew, do you remember why you introduced that part 
>>> of the code?
>>>
>>> Claude
>>>
>>> -- 
>>> You received this message because you are subscribed to the Google 
>>> Groups "Django developers (Contributions to Django itself)" group.
>>> To unsubscribe from this group and stop receiving emails from it, send 
>>> an email to django-develop...@googlegroups.com .
>>> To post to this group, send email to django-d...@googlegroups.com 
>>> .
>>> Visit this group at http://groups.google.com/group/django-developers.
>>> To view this discussion on the web visit 
>>> https://groups.google.com/d/msgid/django-developers/1f5f37b2-5309-4af6-8b3c-aa76eee3bde1%40googlegroups.com
>>>  
>>> <https://groups.

Re: status of 1.8 release blockers

[Tim Graham]

Here is the second update with three weeks to go until alpha:

#23861 - 
 Fields referenced in 
migrations cannot be (re)moved, even if migrations have been squashed 

#23891  - Revise deprecation / 
removal timeline for IPAddressField 

Owner: ?
This week: On ticket #23891 I proposed the idea of moving model field 
deprecation warnings to the system check framework. I am waiting for 
feedback on this approach before investing further.
Last week's status: We need someone to investigate a strategy for how we 
can deprecate model fields while keeping them available in historical 
migrations. Any takers? If we cannot complete this, I propose we bump the 
deprecation of IPAddressField until the issue is solved.

#22340 -  
 Legacy Table Creation Methods 
Not Properly Deprecated 
Owner: ?
This week: I think the performance concerns are no longer a blocker to 
resolving this ticket (see the mailing list thread for details). I did 
research on the remaining work needed and left a comment on the ticket. I 
will work on the implementation next week if no one else picks it up.
Last week's status: This issue is being discussed in the thread "Migrations 
in Django 1.7 make unit testing models harder". In short, we likely to need 
to solve the performance issues with migrations before we can proceed with 
the deprecation. If we cannot, we'll likely have to delay the deprecation.

#23271 - Makemessages can 
corrupt existing .po files on Windows 

Owner: Ramiro
This week: no update
Last week's status: Ramiro said he would have some time to investigate the 
issue soon.

#23745 - Migrations migrate is slow 
 (new)
Owner: Claude
Status: Patch seems to need improvement so it doesn't cause a regression 
with swappable models.

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/b632fa62-3292-457c-bee0-87b1314d8a97%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Multiple template engines for Django - week 12

[Tim Graham]

I agree with your expected behavior for select_template() and the 
conclusions you drew.

On Saturday, December 27, 2014 5:59:37 PM UTC-5, Aymeric Augustin wrote:
>
> Hello, 
>
> My twelfth update is online: 
> https://myks.org/en/multiple-template-engines-for-django/#2014-12-28 
>
> It comes with a question — should I drop `select_template` from the 
> backend API? I think I should. Follow the link above for details. 
>
> Looking forward to your feedback, 
>
> -- 
> Aymeric. 
>
>
>
> > On 20 déc. 2014, at 23:57, Aymeric Augustin <
> aymeric@polytechnique.org > wrote: 
> > 
> > Hello, 
> > 
> > I haven’t written to this mailing-list for three weeks because nothing 
> warranted your immediate attention. 
> > 
> > Now the code is in reasonably good shape. Feel free to have a look: 
> > https://github.com/aaugustin/django/commits/multiple-template-engines 
> > 
> > I plan to merge this branch within a few days. 
> > 
> > Updates for weeks 9 to 11 are available at the usual location: 
> > https://github.com/aaugustin/django/commits/multiple-template-engines 
> > 
> > -- 
> > Aymeric. 
> > 
> > 
> > 
> >> On 30 nov. 2014, at 10:37, Aymeric Augustin <
> aymeric@polytechnique.org > wrote: 
> >> 
> >> Hello, 
> >> 
> >> Here’s my eight update — this is getting repetitive :-) 
> >> https://myks.org/en/multiple-template-engines-for-django/#2014-11-30 
> >> 
> >> -- 
> >> Aymeric. 
> >> 
> >> 
> >> 
> >>> On 23 nov. 2014, at 00:02, Aymeric Augustin <
> aymeric@polytechnique.org > wrote: 
> >>> 
> >>> Hello, 
> >>> 
> >>> I published my seventh update: 
> >>> https://myks.org/en/multiple-template-engines-for-django/#2014-11-23 
> >>> 
> >>> I have another pull request ready for review: 
> >>> https://github.com/django/django/pull/3605 
> >>> 
> >>> Let me know if you have any questions! 
> >>> 
> >>> -- 
> >>> Aymeric. 
> >>> 
> >>> 
> >>> 
>  On 16 nov. 2014, at 09:19, Aymeric Augustin <
> aymeric@polytechnique.org > wrote: 
>  
>  Hello, 
>  
>  Here’s my sixth update: 
>  https://myks.org/en/multiple-template-engines-for-django/#2014-11-16 
>  
>  I have a first pull request ready for review: 
>  https://github.com/django/django/pull/3555 
>  
>  Whenever possible, I’ll merge changes that make sense regardless of 
> the Multiple Template Engines Project in small batches, in order to 
> minimize the size of the final pull request. 
>  
>  -- 
>  Aymeric. 
>  
>  
>  
> > On 9 nov. 2014, at 22:05, Aymeric Augustin <
> aymeric@polytechnique.org > wrote: 
> > 
> > Hello, 
> > 
> > Here’s my fifth update: 
> > https://myks.org/en/multiple-template-engines-for-django/#2014-11-09 
> > 
> > The first step of my project, as outlined in my original proposal, 
> is complete. 
> > 
> > -- 
> > Aymeric. 
> > 
> > 
> > 
> >> On 1 nov. 2014, at 23:30, Aymeric Augustin <
> aymeric@polytechnique.org > wrote: 
> >> 
> >> Hello, 
> >> 
> >> I’m happy to annonce that the DEP is ready for public review! 
> >> 
> >> Direct link, HTML: 
> >> https://myks.org/en/multiple-template-engines-for-django/dep/ 
> >> 
> >> Direct link, ReStructured Text: 
> >> 
> https://raw.githubusercontent.com/aaugustin/mtefd/master/multiple-template-engines.rst
>  
> >> 
> >> (I’m not reproducing it here because I don’t think email is a very 
> good medium for communicating 50kB of markup.) 
> >> 
> >> I’ve written a bit more about what “ready” means: 
> >> 
> https://myks.org/en/multiple-template-engines-for-django/#2014-11-01 
> >> 
> >> Of course, your regularly scheduled update will also be available 
> (in half an hour): 
> >> 
> https://myks.org/en/multiple-template-engines-for-django/#2014-11-02 
> >> 
> >> I’m looking forward to your feedback! 
> >> 
> >> -- 
> >> Aymeric. 
> >> 
> >> 
> >> 
> >>> On 26 oct. 2014, at 22:36, Aymeric Augustin <
> aymeric@polytechnique.org > wrote: 
> >>> 
> >>> Hello, 
> >>> 
> >>> I just published the third update: 
> >>> 
> https://myks.org/en/multiple-template-engines-for-django/#2014-10-26 
> >>> 
> >>> -- 
> >>> Aymeric. 
> >>> 
> >>> 
> >>> 
>  On 19 oct. 2014, at 00:09, Aymeric Augustin <
> aymeric@polytechnique.org > wrote: 
>  
>  Hello, 
>  
>  Here’s the second update: 
>  
> https://myks.org/en/multiple-template-engines-for-django/#2014-10-19 
>  
>  Best, 
>  
>  -- 
>  Aymeric. 
>  
>  
>  
>  On 12 oct. 2014, at 20:31, Aymeric Augustin <
> aymeric@polytechnique.org > wrote: 
>  
> > Hello, 
> > 
> > I just posted the first update on this project: 
> > 
> https://myks.org/en/multiple-template-engines-for-django/#2014-10-12 
> > 
> 

Re: "stable API" misconception giving BaseManager and Manager as examples

[Tim Graham]

In fact, there's an open ticket to create a reference of the public manager 
methods. There's a detailed comment from Loic about some ideas for that: 
https://code.djangoproject.com/ticket/20768

I think our existing policy about stable APIs being the ones that are 
documented works pretty well. I don't think there would be much gain in 
shuffling around a lot of code to distinguish between public and private 
APIs, plus we'd needlessly break a lot of code that's using private APIs.

On Saturday, December 27, 2014 7:28:55 PM UTC-5, Ilya Kazakevich wrote:
>
> Hello,
>
> In Djnago 1.7 Manager class extends BaseManager (actually, it extends its 
> proxy, created using from_queryset). BaseManager is not mentioned in 
> official documentation, so it is not part of official ("stable") api, right?
>
> "All the public APIs (everything in this documentation) " (from here 
> https://docs.djangoproject.com/en/dev/misc/api-stability/)
>
> But it does not start with underscore and its module 
> (django.db.models.manager) is public module aswell. So, it should be 
> considered as public class according to python codestyle. 
> I believe this fact confuses user. May one use BaseManager or minor api 
> change may brake such usage?
>
> The other problem is there is no official Manager reference: there is a 
> good manual, but no reference where all methods are listed (like we have 
> for QuerySet, for example).
>
> So, what is the official, stable Manager API? Most developers know answer 
> to this question intuitively, but there is no formal way to answer it, 
> right?
>
> I believe that in Ideal Project there should be something like this:
> 1) Move all "non public" classes to "_non_public" packages (or make 
> classes _NonPublic)
> 2) For each public class list all members in doc or directly in python 
> documentation. 
>
> What do you think?
>
> Ilya.
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/c6ffc041-c120-4c02-8ce4-777207cf4a9e%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Fellow Report - December 26, 2014

[Tim Graham]

I spent a good chunk of time this week reviewing two of the major features 
for 1.8 (multiple template engines and _meta refactor), as well as fixing 
and researching release blockers (more on that in the "status of 1.8 
release blockers" thread). With two weeks left until the scheduled alpha, I 
expect more of the same next week (and finding someone to assist me with 
the 1.7.2 bug fix release, I hope).


Report for week ending December 26, 2014:

Triaged

---

https://code.djangoproject.com/ticket/24048 - only() doesn't override 
fields included in defer() as documented (accepted)

https://code.djangoproject.com/ticket/24045 - Useless calls to mark_safe 
and mark_for_escaping (accepted)

https://code.djangoproject.com/ticket/23994 - ModelFormsets do not check pk 
fields of deleted forms in validation (duplicate)

https://code.djangoproject.com/ticket/24028 - Related instance caching 
causes abstraction leaks from Field.get_db_prep_save (accepted)

https://code.djangoproject.com/ticket/24042 - Custom AutoField fields do 
not work correctly on postgres (accepted)

https://code.djangoproject.com/ticket/24044 - filtering by annotation 
executes sql function twice (accepted)

https://code.djangoproject.com/ticket/24047 - Cannot combine values_list 
querysets that do subqueries (accepted)

https://code.djangoproject.com/ticket/24053 - Drop IE6/7 admin CSS/icons 
(created)

Authored



https://github.com/django/django/pull/3782 - Fixed #24037 -- Prevented data 
loss possibility when changing Meta.managed.

https://github.com/django/django/pull/3785 - Fixed #24045 -- Removed 
useless mark_safe() call in trans_null.py

https://github.com/django/django/pull/3795 - Replaced sqlall in some 
bash_completion/admin_scripts tests.

https://github.com/django/django/pull/3792 - Fixed #24054 -- Enabled 
sqlsequencereset for apps with migrations.

https://github.com/django/django/pull/3791 - [WIP] Removed code per 
deprecation timeline

Reviewed/committed

--

https://github.com/django/django/pull/3739 - Fixed #23998 -- Added 
datetime.time support to migrations questioner

https://github.com/django/django/pull/3494 - Fixed #23792 -- Added 
test.utils.freeze_time() context manager.

https://github.com/django/django/pull/3780 - Fixed #24035 -- Clarified docs 
on CACHE_MIDDLEWARE_KEY_PREFIX vs KEY_PREFIX

https://github.com/django/django/pull/3332 - Fixed #20349 -- Moved 
setting_changed signal to django.core.signals.

https://github.com/django/django/pull/3764 - Fixed #22461 -- Support for 
if-unmodified-since in condition decorator

https://github.com/django/django/pull/2986 - Fixed #10414 -- Made 
select_related fail on invalid field names.

https://github.com/django/django/pull/3787 - Fixed #24041 -- Documented 
effect of changing a model instance's primary key.

https://github.com/django/django/pull/3104 - Fixed lazy() to lookup methods 
on the real object, not resultclasses.

https://github.com/django/django/pull/3799 - Fixed #24000 -- Corrected 
contrib.sites default site creation in a multiple database setup.

Reviews of core dev work



https://github.com/django/django/pull/3770 - Multiple template engines

https://github.com/django/django/pull/3754 - Fixed #23753 -- Added a suite 
of SQL Functions

https://github.com/django/django/pull/3784 - Fixed #23831 -- Supported 
strings escaped by third-party libs in Django. 

https://github.com/django/django/pull/3798 - [1.7.x] Fixed #24051 -- Made 
schema infrastructure honor tablespaces

In progress reviews

---

https://github.com/django/django/pull/3762 - Fixed #22295 -- Replaced 
permission check for displaying user-tools

https://github.com/django/django/pull/3677 - Fixed #12118 - Added ability 
to share sqlite in-memory database in threads.

https://github.com/django/django/pull/3153 - Fixed #23359 -- Added 
showmigrations command to list migrations and show migration plan

https://github.com/django/django/pull/3114 - Meta API refactor

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/4b0d6892-6c57-40f9-a35a-eda9f9dcb62f%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Updating logging docs

[Tim Graham]

Definitely would be welcome. Perhaps these tickets cover at least some of 
your points:

https://code.djangoproject.com/ticket/23394 - Need documentation for 
merging the project's logging configuration with Django's defaults
https://code.djangoproject.com/ticket/23784 - Error reporting docs needs to 
state clearly that changing logging conf error emails are not sent out 
unless configuring it again

I'll be happy to review anything you'd like to draft.

On Tuesday, December 30, 2014 2:12:38 PM UTC-5, Lee Trout wrote:
>
> Hey gang,
>
> I finally got past 1.5 and I'm finding so many nice features in 1.7. 
> Thanks to everyone!
>
> To my surprise logging had an overhaul from #21714 [0] and I found the 
> documentation a bit confusing / lacking of details.
>
> Theres an explanation of merging settings in 
> https://docs.djangoproject.com/en/1.7/topics/logging/#configuring-logging 
> but no description of what the defaults are.
>
> Visiting 
> https://docs.djangoproject.com/en/1.7/topics/logging/#django-s-default-logging-configuration
>  
> doesn't offer any more help to understanding the technical details.
>
> I'd like to see a mention of the defaults existing in 
> `django.utils.log.DEFAULT_LOGGING` *at a minimum*. Given the desire to 
> understand the entire technical scope I think it would be worth repeating 
> the default settings in the default logging configuration heading at the 
> bottom of the page (and toss a comment in django.utils.log that if it's 
> updated remember to update the docs).
>
> Thoughts?
>
> Thanks & Happy New Year!
> Lee
>
>
> [0] https://code.djangoproject.com/ticket/21714
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/964c1077-7283-449d-88ab-049be477d3a9%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: status of 1.8 release blockers

[Tim Graham]

Here is the third update with a week and a half to go until alpha (I 
incorrectly said in the last update a couple days ago that we have 3 weeks 
left!):

#23861 - 
<https://code.djangoproject.com/ticket/23861> Fields referenced in 
migrations cannot be (re)moved, even if migrations have been squashed 
<https://code.djangoproject.com/ticket/23861>
#23891 <https://code.djangoproject.com/ticket/23891> - Revise deprecation / 
removal timeline for IPAddressField 
<https://code.djangoproject.com/ticket/23891>
Owner: Tim
Now: I've implemented the system check solution I proposed and am waiting 
for review and/or concerns with this approach.
Last time: On ticket #23891 I proposed the idea of moving model field 
deprecation warnings to the system check framework. I am waiting for 
feedback on this approach before investing further.

#22340 -  
<https://code.djangoproject.com/ticket/22340> Legacy Table Creation Methods 
Not Properly Deprecated <https://code.djangoproject.com/ticket/22340>
Owner: Tim
Now: I took a closer look at this and don't think we need to do this 
deprecation at all as it doesn't seem to offer any benefits. See the ticket 
for details.
Last time: I think the performance concerns are no longer a blocker to 
resolving this ticket (see the mailing list thread for details). I did 
research on the remaining work needed and left a comment on the ticket. I 
will work on the implementation next week if no one else picks it up.

#23745 - Migrations migrate is slow 
<https://code.djangoproject.com/ticket/23745> (new)
Owner: Claude/Markus
Now: I committed the test that Markus wrote and Claude incorporated a fix 
from Markus so the branch appears about ready for merge. Markus will give 
it another review.
Last time: Patch seems to need improvement so it doesn't cause a regression 
with swappable models.

#23271 - <https://code.djangoproject.com/ticket/23271>Makemessages can 
corrupt existing .po files on Windows 
<https://code.djangoproject.com/ticket/23271>
Owner: Ramiro
Now: Resolved by Ramio
Last time: no update

On Tuesday, December 30, 2014 7:49:59 AM UTC-5, Markus Holtermann wrote:
>
> On Monday, December 29, 2014 10:40:06 AM UTC+1, Claude Paroz wrote:
>>
>> On Saturday, December 27, 2014 4:46:52 PM UTC+1, Tim Graham wrote:
>>>
>>> #23745 - Migrations migrate is slow 
>>> <https://code.djangoproject.com/ticket/23745> (new)
>>> Owner: Claude
>>> Status: Patch seems to need improvement so it doesn't cause a regression 
>>> with swappable models.
>>>
>>
>> Sorry, but I'm afraid you should remove my name as the owner at this 
>> stage.
>>
>
> I took a look at the PR and added a test case that passes on stable/1.7.x 
> and master. If the PR is applied as-is it fails: 
> https://github.com/MarkusH/django/commit/9bc0d669e1fec3d9b3886ecf0c44bbf77b25ef6d
>  
> . But I'd like to get a few more eyes on the test so we can make sure it 
> correctly represents the issue described in the ticket.
>
> I furthermore tried to fix the issue with the patch in 
> https://github.com/MarkusH/django/commit/9651ceebfe5a27bf4a095098e92454766480d931
>  
> . Assuming the test above is correct, this might be a way to solve the 
> issue.
>
> /Markus
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/ce2b5e72-e21c-4ce8-a348-e6486c979471%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: status of 1.8 release blockers

[Tim Graham]

Here is the fourth update with a week to go until alpha. At this time, I am 
thinking we'll have the feature freeze on Monday, January 12 as planned, 
but perhaps issue the actual alpha release a couple days later just to give 
some time for some extra polish in case any large patches are committed 
next weekend.

#23861 - 
 Fields referenced in 
migrations cannot be (re)moved, even if migrations have been squashed 

#23891  - Revise deprecation / 
removal timeline for IPAddressField 
 (resolved)
Owner: Tim
Now: I committed a patch for the second ticket and will polish the patch 
for the first issue.
Last time: I've implemented the system check solution I proposed and am 
waiting for review and/or concerns with this approach.

After completing the issue above, I'll prioritize any issues here:
https://code.djangoproject.com/query?status=assigned&status=new&keywords=~1.8-alpha

Resolved since last time:

#22340 -  
 Legacy Table Creation Methods 
Not Properly Deprecated 
Owner: Tim
Now: Resolved this by removing the deprecation as discussed in the ticket.
Last time: I took a closer look at this and don't think we need to do this 
deprecation at all as it doesn't seem to offer any benefits. See the ticket 
for details.

#23745 - Migrations migrate is slow 

Owner: Claude/Markus
Now: Patch committed; thanks to Markus and Claude.
Last time: I committed the test that Markus wrote and Claude incorporated a 
fix from Markus so the branch appears about ready for merge. Markus will 
give it another review.

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/b196f095-530c-45ec-9b21-82fcd1c06ed8%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Fellow Report - January 2, 2015

[Tim Graham]

This week I focused on release blockers and helping with review of the 
Model._meta pull request. Thanks to James Bennett for helping me with the 
bug fix releases last night.

Report for week ending January 2, 2015:

Triaged

---

https://code.djangoproject.com/ticket/24062 - Reversing Model names fails 
(duplicate)

https://code.djangoproject.com/ticket/21281 - Make override_settings act at 
class level when used as a TestCase decorator (reopened and investigated a 
regression)

https://code.djangoproject.com/ticket/24070 - Mention the topic of the 
tutorial parts in doc index (fixed)

Authored



https://github.com/django/django/pull/3811 - Fixed #23581 -- Prevented 
extraneous DROP DEFAULT statements.

https://github.com/django/django/pull/3818 - Fixed #23891 -- Moved 
deprecation of IPAddressField to system check framework.

https://github.com/django/django/pull/3810 - Moved 
DatabaseCreation.data_types properties to DatabaseWrapper.

https://github.com/django/django/pull/3809 - Added tests for migrations 
handling of database defaults.

https://github.com/django/django/commit/b9feec959b9dfc08513607c9046fb38c5b8f7e8a
 
- Fixed #23700 -- Fixed non-deterministic static files test failures on 
Windows.

https://github.com/django/django/pull/3832 - Fixed #23861 -- Added an API 
to deprecate model fields.

https://github.com/django/django/pull/3829 - Updated six to 1.9.0.

Reviewed/committed

--

https://code.djangoproject.com/ticket/24000 - create_default_site 'db' 
kwarg should be 'using'

https://github.com/django/django/pull/3804 - Converted middleware tests to 
use RequestFactory.

https://github.com/django/django/pull/3665 - Fixed #23938 -- Added 
migration support for m2m to concrete fields and vice versa

https://github.com/django/django/pull/3677 - Fixed #12118 - Added ability 
to share sqlite in-memory database in threads.

https://github.com/django/django/pull/3819 - Ignored warnings correctly in 
test_get_formsets_with_inlines_returns_tuples.

https://github.com/django/django/pull/3783 - Refs #18586 -- Split up 
tests.defer.DeferTests.test_defer

https://github.com/django/django/pull/3557 - Fixed #23758 -- Allowed more 
than 5 levels of subqueries

https://github.com/django/django/pull/3153 - Fixed #23359 -- Added 
showmigrations command to list migrations and plan.

https://github.com/django/django/pull/3762 - Fixed #22295 -- Replaced 
permission check for displaying admin user-tools

https://github.com/django/django/pull/3827 - Fixed #9104 -- Moved 
FieldDoesNotExist to core.exceptions

https://github.com/django/django/pull/3821 - Fixed #24064 - Prevented 
database access at compile time in spatialite models

https://github.com/django/django/pull/3822 - Fixed #23749 -- Added an 
example of using database routers in migrations

https://github.com/django/django/pull/3826 - Fixed #24069 - Made 
ServerHandler a new style class

Reviews of core dev work


https://github.com/django/djangoproject.com/pull/276 - djangoproject.com 
host refactor

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/59c7743e-0ddf-4607-8284-f2818f2039c8%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Multiple template engines for Django - week 13

[Tim Graham]

I don't think it's fair to put pressure on Aymeric like that. It seems to 
me with should, if anything, be more conservative with an LTS -- not try to 
cram in last minute features. We have 2-3 months until the scheduled final 
release -- if we liberalize our "rules", I'm sure we can kick that date out 
the window. My own hope (from what others have expressed interest in) is to 
move Django to a more rapid release cycle of 6-9 months instead of the more 
historical 9-12 months. I believe this feature will be all the better in 
1.9 after getting a first version out the door in 1.8.

On Sunday, January 4, 2015 3:51:22 AM UTC-5, Florian Apolloner wrote:
>
> On Sunday, January 4, 2015 2:44:52 AM UTC+1, jdunck wrote:
>>
>> If getting proper support for other template backends would only delay 
>> the 1.8 release timeline by a couple weeks, I think that is preferable to a 
>> generalized 1.8 backend which only include DTL until 1.9.
>>
>
> Define proper support. Either way -1 on pushing the alpha further. 
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/3e10a35f-16cf-46c1-a832-7c9a17ac5a80%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

documenting changes to the database backend API

[Tim Graham]

To authors of third-party database backends,

We'd like to start documenting changes to the database backend API [1], but 
we need some help with this.

First, please introduce yourself and which backend you maintain so we know 
of your existence.

Second, we'd like to know if you attempt to support multiple versions of 
Django in a particular release of your backend? This will help us to decide 
whether or not try to document the changes in a backwards and forwards 
compatible way.

Third, could you try updating your backend to 1.8 and let us know what 
problems you run into so we know what documentation to add?

The section of the release notes that will be expanded with details is: 
https://docs.djangoproject.com/en/dev/releases/1.8/#database-backend-api

Thank-you!

[1] https://code.djangoproject.com/ticket/24106

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/a9c2aefc-f6f0-46db-804a-3608d033017c%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: status of 1.8 release blockers

[Tim Graham]

Here is the fifth update with several days to go until alpha. I believe we 
are on track for a feature freeze at the end of day on Monday. Let's see 
how things go, but I'd like to cut the stable/1.8.x branch and issue the 
alpha release by the following Friday (a week from today).

New blockers:

#24075 <https://code.djangoproject.com/ticket/24075> - Can't migrate 
contenttypes and auth to zero <https://code.djangoproject.com/ticket/24075>
Owner: Simon
Status: This is an existing issue on 1.7, but addressing it seems to 
require (or at least, would be a lot easier) with the proposed new feature 
of adding a "plan" argument to the post_migrate() signal. There is a patch 
in the works.

Resolved since last time:

#23861 - 
<https://code.djangoproject.com/ticket/23861> Fields referenced in 
migrations cannot be (re)moved, even if migrations have been squashed 
<https://code.djangoproject.com/ticket/23861>
Owner: Tim
Now: I polished and committed the patch for this.
Last time: I committed a patch for the second ticket and will polish the 
patch for the first issue.

Most of the issues tagged "1.8-alpha" have been completed or deferred. The 
two main ones that remain are "Case/When expressions" and "Allowing 
expressions to be used in order_by queryset method." Depending on what 
progress is made over the weekend on these issues, they may or may not make 
it into 1.8.
https://code.djangoproject.com/query?status=assigned&status=new&keywords=~1.8-alpha

On Saturday, January 3, 2015 at 1:19:25 PM UTC-5, jdunck wrote:
>
> Thank you, Tim, for shepherding this.
> On Jan 3, 2015 8:09 AM, "Tim Graham" > 
> wrote:
>
>> Here is the fourth update with a week to go until alpha. At this time, I 
>> am thinking we'll have the feature freeze on Monday, January 12 as planned, 
>> but perhaps issue the actual alpha release a couple days later just to give 
>> some time for some extra polish in case any large patches are committed 
>> next weekend.
>>
>> #23861 - 
>> <https://code.djangoproject.com/ticket/23861> Fields referenced in 
>> migrations cannot be (re)moved, even if migrations have been squashed 
>> <https://code.djangoproject.com/ticket/23861>
>> #23891 <https://code.djangoproject.com/ticket/23891> - Revise 
>> deprecation / removal timeline for IPAddressField 
>> <https://code.djangoproject.com/ticket/23891> (resolved)
>> Owner: Tim
>> Now: I committed a patch for the second ticket and will polish the patch 
>> for the first issue.
>> Last time: I've implemented the system check solution I proposed and am 
>> waiting for review and/or concerns with this approach.
>>
>> After completing the issue above, I'll prioritize any issues here:
>>
>> https://code.djangoproject.com/query?status=assigned&status=new&keywords=~1.8-alpha
>>
>> Resolved since last time:
>>
>> #22340 -  
>> <https://code.djangoproject.com/ticket/22340> Legacy Table Creation 
>> Methods Not Properly Deprecated 
>> <https://code.djangoproject.com/ticket/22340>
>> Owner: Tim
>> Now: Resolved this by removing the deprecation as discussed in the ticket.
>> Last time: I took a closer look at this and don't think we need to do 
>> this deprecation at all as it doesn't seem to offer any benefits. See the 
>> ticket for details.
>>
>> #23745 - Migrations migrate is slow 
>> <https://code.djangoproject.com/ticket/23745>
>> Owner: Claude/Markus
>> Now: Patch committed; thanks to Markus and Claude.
>> Last time: I committed the test that Markus wrote and Claude incorporated 
>> a fix from Markus so the branch appears about ready for merge. Markus will 
>> give it another review.
>>
>> -- 
>> 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-develop...@googlegroups.com .
>> To post to this group, send email to django-d...@googlegroups.com 
>> .
>> Visit this group at http://groups.google.com/group/django-developers.
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/django-developers/b196f095-530c-45ec-9b21-82fcd1c06ed8%40googlegroups.com
>>  
>> <https://groups.google.com/d/msgid/django-developers/b196f095-530c-45ec-9b21-82fcd1c06ed8%40googlegroups.com?utm_medium=email&utm_source=footer>
>> .
>> For more options, visit https://groups.google.com/d/optout.
>>
>

-- 
You received this message beca

Fellow Report - January 9, 2015

[Tim Graham]

This is my second to last report before the fellowship pilot ends. If you’d 
like to see the program happen again, please encourage your company or 
organization to donate to the DSF 

.

Highlights of this week included reviewing many of the remaining large 
features for 1.8: Daniel’s _meta refactor work, Aymeric’s multiple template 
engines docs, Marc’s work on Range fields for contrib.postgres, and a large 
ORM patch from Anssi to leverage the new expressions functionality 
internally. I am pleased that we've finished all the major features we 
targeted during the 1.8 release planning [1] and that we're on schedule for 
an alpha release next week. Thank-you to everyone from the community for 
making it happen.


[1] https://code.djangoproject.com/wiki/Version1.8Roadmap

Report for week ending January 9, 2015:

Triaged

---

https://code.djangoproject.com/ticket/24089 - Misleading error raised 
during system check related to ModelAdmin (accepted)

https://code.djangoproject.com/ticket/24102 - SchemaEditor.create_model 
doesn't create a constraint name for unique_together (accepted)

https://code.djangoproject.com/ticket/24105 - When upload_to is callable, 
storage.get_valid_name() does not get called (accepted)

https://code.djangoproject.com/ticket/24081 - Latest six update broke 
Python 2.5 compatibility (fixed)

https://bitbucket.org/gutworth/six/issue/112/sixmovesreload_module-uses-deprecated-imp
 
- six.moves.reload_module uses deprecated imp module on Python 3.4+ 
(created; it causes a warning in Django’s test suite)

Authored



https://github.com/django/django/pull/3837 - [1.7.x] Increased the default 
PBKDF2 iterations.

https://github.com/django/django/pull/3839 - Updated release instructions 
with latest process.

https://github.com/django/django/pull/3855 - Fixed #24095 -- Prevented 
WarningLoggerTests from leaking a warnings filter.

https://github.com/django/django/pull/3860 - Fixed #24101 -- Fixed flaky 
admin_views selenium tests; refs #7361.

https://github.com/django/django/pull/3863 - Isolated some cache tests; 
refs #23947.

https://github.com/django/django/pull/3870 - Added best practices for 
versionadded/changed annotations.

Reviewed/committed

--

https://github.com/django/django/pull/3836 - Fixed #24072 -- Added support 
for wsgi.file_wrapper

https://github.com/django/django/pull/3846 - Fixed #24022 -- Deprecated the 
ssi tag.

https://github.com/django/django/pull/3114- Fixed #12663 -- Formalized the 
Model._meta API for retrieving fields.

https://github.com/django/django/pull/3840 - Fixed #24078 -- Removed empty 
strings from GenericIPAddressField

https://github.com/django/django/pull/3669 - Fixed #24020 -- Refactored SQL 
compiler to use expressions & refactored select_related() implementation

https://github.com/django/django/pull/3859 - Fixed #24098 -- Added no-op 
attributes to RunPython and RunSQL

Reviews of core dev work



https://github.com/django/django/pull/3838 - Fixed #24073 -- Deactivated 
translations when leave_locale_alone is False

https://github.com/django/django/pull/3828 - Fixed #8280 -- Allowed 
management command discovery for eggs

https://github.com/django/django/pull/3858 - Fixed #24099 -- Removed 
contenttype.name deprecated field

https://github.com/django/django/pull/3849 - Fixed #22583 -- Allowed 
RunPython and RunSQL to provide hints to the db router.

https://github.com/django/django/pull/3845 - Multiple template engines docs

https://github.com/django/django/pull/3478 - Fixed #24011-- Added Range 
fields for contrib.postgres
https://github.com/django/django/pull/3542 - Fixed #13165 -- Added edit and 
delete links for admin related fields.

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/1a9aef69-76c9-4791-ba7c-1eaba4f6fa93%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: status of 1.8 release blockers

[Tim Graham]

We did it -- all features are in or out for alpha. Please consider master 
frozen for new features until we cut the stable/1.8.x branch later this 
week. Feel free to commit code cleanups and/or bug fixes until then.

On Friday, January 9, 2015 at 1:14:02 PM UTC-5, Tim Graham wrote:
>
> Here is the fifth update with several days to go until alpha. I believe we 
> are on track for a feature freeze at the end of day on Monday. Let's see 
> how things go, but I'd like to cut the stable/1.8.x branch and issue the 
> alpha release by the following Friday (a week from today).
>
> New blockers:
>
> #24075 <https://code.djangoproject.com/ticket/24075> - Can't migrate 
> contenttypes and auth to zero 
> <https://code.djangoproject.com/ticket/24075>
> Owner: Simon
> Status: This is an existing issue on 1.7, but addressing it seems to 
> require (or at least, would be a lot easier) with the proposed new feature 
> of adding a "plan" argument to the post_migrate() signal. There is a patch 
> in the works.
>
> Resolved since last time:
>
> #23861 - 
> <https://code.djangoproject.com/ticket/23861> Fields referenced in 
> migrations cannot be (re)moved, even if migrations have been squashed 
> <https://code.djangoproject.com/ticket/23861>
> Owner: Tim
> Now: I polished and committed the patch for this.
> Last time: I committed a patch for the second ticket and will polish the 
> patch for the first issue.
>
> Most of the issues tagged "1.8-alpha" have been completed or deferred. The 
> two main ones that remain are "Case/When expressions" and "Allowing 
> expressions to be used in order_by queryset method." Depending on what 
> progress is made over the weekend on these issues, they may or may not make 
> it into 1.8.
>
> https://code.djangoproject.com/query?status=assigned&status=new&keywords=~1.8-alpha
>
> On Saturday, January 3, 2015 at 1:19:25 PM UTC-5, jdunck wrote:
>>
>> Thank you, Tim, for shepherding this.
>> On Jan 3, 2015 8:09 AM, "Tim Graham"  wrote:
>>
>>> Here is the fourth update with a week to go until alpha. At this time, I 
>>> am thinking we'll have the feature freeze on Monday, January 12 as planned, 
>>> but perhaps issue the actual alpha release a couple days later just to give 
>>> some time for some extra polish in case any large patches are committed 
>>> next weekend.
>>>
>>> #23861 - 
>>> <https://code.djangoproject.com/ticket/23861> Fields referenced in 
>>> migrations cannot be (re)moved, even if migrations have been squashed 
>>> <https://code.djangoproject.com/ticket/23861>
>>> #23891 <https://code.djangoproject.com/ticket/23891> - Revise 
>>> deprecation / removal timeline for IPAddressField 
>>> <https://code.djangoproject.com/ticket/23891> (resolved)
>>> Owner: Tim
>>> Now: I committed a patch for the second ticket and will polish the patch 
>>> for the first issue.
>>> Last time: I've implemented the system check solution I proposed and am 
>>> waiting for review and/or concerns with this approach.
>>>
>>> After completing the issue above, I'll prioritize any issues here:
>>>
>>> https://code.djangoproject.com/query?status=assigned&status=new&keywords=~1.8-alpha
>>>
>>> Resolved since last time:
>>>
>>> #22340 -  
>>> <https://code.djangoproject.com/ticket/22340> Legacy Table Creation 
>>> Methods Not Properly Deprecated 
>>> <https://code.djangoproject.com/ticket/22340>
>>> Owner: Tim
>>> Now: Resolved this by removing the deprecation as discussed in the 
>>> ticket.
>>> Last time: I took a closer look at this and don't think we need to do 
>>> this deprecation at all as it doesn't seem to offer any benefits. See the 
>>> ticket for details.
>>>
>>> #23745 - Migrations migrate is slow 
>>> <https://code.djangoproject.com/ticket/23745>
>>> Owner: Claude/Markus
>>> Now: Patch committed; thanks to Markus and Claude.
>>> Last time: I committed the test that Markus wrote and Claude 
>>> incorporated a fix from Markus so the branch appears about ready for merge. 
>>> Markus will give it another review.
>>>
>>> -- 
>>> 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 dja

[ANNOUNCE] Security releases issued (1.4.18, 1.6.10, 1.7.3)

[Tim Graham]

Today the Django team is issuing multiple releases -- Django 1.4.18, Django 
1.6.10, and Django 1.7.3 -- as part of our security process. These releases 
address several security issues, and we encourage all users to upgrade as 
soon as possible.

More details can be found on our blog:

https://www.djangoproject.com/weblog/2015/jan/13/security/

As a reminder, we ask that potential security issues be reported via 
private email to secur...@djangoproject.com, and not via Django's Trac 
instance or the django-developers list. Please see 
https://www.djangoproject.com/security for further information.

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/6d8ec199-c011-422a-a268-cb8aeed4d402%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Generic relations and aggregation

[Tim Graham]

Yes, there is an open ticket to update the documentation: 
https://code.djangoproject.com/ticket/24019

If you're able to work on a patch, I'll be happy to review it.

On Wednesday, January 14, 2015 at 5:56:26 PM UTC-5, x13 wrote:
>
>
> According to Django 1.7 Docs, aggregation API is not working with generic 
> relations
>
> https://docs.djangoproject.com/en/1.7/ref/contrib/contenttypes/#generic-relations-and-aggregation
>
> Bookmark.objects.aggregate(Count('tags'))   # Not working according to 
> Docs.
>
>
> But this bug seems to be fixed in #10870
> https://code.djangoproject.com/ticket/10870
>
> Are aggregations working in 1.7?
> Thanks in advance.
>
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/dd09c1fb-4390-437d-8164-8c5520ad6522%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Can't login after upgrading to 1.7.3, and workaround

[Tim Graham]

Hi Horacio,

Thanks for the report. Unfortunately, I can't reproduce this issue.

My steps to reproduce using the project from the tutorial:
Bump PBKDF2PasswordHasher.iterations to a higher value
Login at /admin/
Confirm at /admin/auth/user/#/ that the password of the user I logged in as 
reflects the new iteration count.

Maybe there is something different in your setup?

On Wednesday, January 14, 2015 at 4:57:13 PM UTC-5, Horacio G. de Oro wrote:
>
> The problem is because the iterations in PBKDF2PasswordHasher where 
> updated to 15000, so it updates the password, but later, 
> SessionAuthenticationMiddleware detects a password change and PUF! the 
> login doesn't work.
>
> Right new I've created a PBKDF2PasswordHasher implementation with 
> iteartions = 12000 (the old value), but I want to report the issue (I don't 
> know if this is a bug) in case it happens to anyone else.
>
> Saving the user returned by authenticate() before calling login() solved 
> the issue too, but I dont' want to save the user just in case the password 
> changed.
>
> Regards!
> Horacio
>
>
> --
> Horacio G. de Oro
> Email: hgd...@gmail.com 
> Web: http://www.data-tsunami.com
> LinkedIn: https://www.linkedin.com/in/hgdeoro
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/1a165ceb-d97a-4451-b110-52a67e559542%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: status of 1.8 release blockers

[Tim Graham]

I think master is stabilizing and the number of unsolved regressions should 
be ~0 by tomorrow. I'd like to release the alpha around 2100 UTC tomorrow 
+/- ~4 hours depending on how things go with the remaining issues. Let me 
know if there is anything you think needs to be in the alpha that wouldn't 
meet this deadline.

On Tuesday, January 13, 2015 at 1:50:26 AM UTC-5, Tino de Bruijn wrote:
>
> Congratulations! Looks like you've steadily moved it through.
>
> Tino
>
> On Tue, Jan 13, 2015 at 3:25 AM, Tim Graham  > wrote:
>
>> We did it -- all features are in or out for alpha. Please consider master 
>> frozen for new features until we cut the stable/1.8.x branch later this 
>> week. Feel free to commit code cleanups and/or bug fixes until then.
>>
>>
>> On Friday, January 9, 2015 at 1:14:02 PM UTC-5, Tim Graham wrote:
>>>
>>> Here is the fifth update with several days to go until alpha. I believe 
>>> we are on track for a feature freeze at the end of day on Monday. Let's see 
>>> how things go, but I'd like to cut the stable/1.8.x branch and issue the 
>>> alpha release by the following Friday (a week from today).
>>>
>>> New blockers:
>>>
>>> #24075 <https://code.djangoproject.com/ticket/24075> - Can't migrate 
>>> contenttypes and auth to zero 
>>> <https://code.djangoproject.com/ticket/24075>
>>> Owner: Simon
>>> Status: This is an existing issue on 1.7, but addressing it seems to 
>>> require (or at least, would be a lot easier) with the proposed new feature 
>>> of adding a "plan" argument to the post_migrate() signal. There is a patch 
>>> in the works.
>>>
>>> Resolved since last time:
>>>
>>> #23861 - 
>>> <https://code.djangoproject.com/ticket/23861> Fields referenced in 
>>> migrations cannot be (re)moved, even if migrations have been squashed 
>>> <https://code.djangoproject.com/ticket/23861>
>>> Owner: Tim
>>> Now: I polished and committed the patch for this.
>>> Last time: I committed a patch for the second ticket and will polish the 
>>> patch for the first issue.
>>>
>>> Most of the issues tagged "1.8-alpha" have been completed or deferred. 
>>> The two main ones that remain are "Case/When expressions" and "Allowing 
>>> expressions to be used in order_by queryset method." Depending on what 
>>> progress is made over the weekend on these issues, they may or may not make 
>>> it into 1.8.
>>> https://code.djangoproject.com/query?status=assigned&;
>>> status=new&keywords=~1.8-alpha
>>>
>>> On Saturday, January 3, 2015 at 1:19:25 PM UTC-5, jdunck wrote:
>>>>
>>>> Thank you, Tim, for shepherding this.
>>>> On Jan 3, 2015 8:09 AM, "Tim Graham"  wrote:
>>>>
>>>>> Here is the fourth update with a week to go until alpha. At this time, 
>>>>> I am thinking we'll have the feature freeze on Monday, January 12 as 
>>>>> planned, but perhaps issue the actual alpha release a couple days later 
>>>>> just to give some time for some extra polish in case any large patches 
>>>>> are 
>>>>> committed next weekend.
>>>>>
>>>>> #23861 - 
>>>>> <https://code.djangoproject.com/ticket/23861> Fields referenced in 
>>>>> migrations cannot be (re)moved, even if migrations have been squashed 
>>>>> <https://code.djangoproject.com/ticket/23861>
>>>>> #23891 <https://code.djangoproject.com/ticket/23891> - Revise 
>>>>> deprecation / removal timeline for IPAddressField 
>>>>> <https://code.djangoproject.com/ticket/23891> (resolved)
>>>>> Owner: Tim
>>>>> Now: I committed a patch for the second ticket and will polish the 
>>>>> patch for the first issue.
>>>>> Last time: I've implemented the system check solution I proposed and 
>>>>> am waiting for review and/or concerns with this approach.
>>>>>
>>>>> After completing the issue above, I'll prioritize any issues here:
>>>>> https://code.djangoproject.com/query?status=assigned&;
>>>>> status=new&keywords=~1.8-alpha
>>>>>
>>>>> Resolved since last time:
>>>>>
>>>>> #22340 -  
>>>>> <https://code.djangoproject.com/ticket/22340> Legacy Table Creation 
>>>

Fellow Report - January 16, 2015

[Tim Graham]

Here’s my final report for the 3 month fellowship pilot. I hope the DSF’s 
fundraising efforts will be successful and I’ll have an opportunity to "be 
back" soon. :-)


On Monday, I reviewed the last couple of tickets before the 1.8 feature 
freeze. On Tuesday, we had the security release. I’ve been working in the 
background on putting that release together for the last month or so. The 
rest of the week was focused on polishing the master branch and fixing 
regressions to get it in a good state for today's release of 1.8 alpha 1. 
If all goes well, we’ll get lots of testers and will be able to release a 
more polished "beta" in about a month.

Report for week ending January 16, 2015:

Triaged

---

https://code.djangoproject.com/ticket/24112 - Inconsistency in 
TestCase.assertInHTML (accepted)

https://code.djangoproject.com/ticket/24086 - No pre_migrate signal is 
emitted if rolling back the migration history (worksforme)

https://code.djangoproject.com/ticket/24148 - test_combined_expression test 
failure on Windows/Python 2 (created)

https://code.djangoproject.com/ticket/24155 - Make migration generation 
more deterministic (accepted)

https://code.djangoproject.com/ticket/24142 - extra() field overwritten 
when using union on two querysets (accepted)

Authored



https://github.com/django/django/pull/3899 - Fixed #22603 -- Organized 
django.db.backends classes

https://github.com/django/django/pull/3923 - Fixed #24135 -- Made 
RenameModel rename many-to-many tables.

Reviewed/committed

--

https://github.com/django/django/pull/3889 - Fixed #23878 -- Move Query and 
Prefetch documentation

https://github.com/django/django/pull/3897 - Fixed #24124 -- Changed 
context_processors in the default settings.py

https://github.com/django/django/pull/3825 - Fixed #24031 -- Added CASE 
expressions

https://github.com/django/django/pull/3876 - Fixed #24089 -- Added check 
for when ModelAdmin.fieldsets[1]['fields'] isn't a tuple.

https://github.com/django/django/pull/3847 - Fixed #23712 -- Fixed KeyError 
with BaseForm._html_output()

https://github.com/django/django/pull/3926 - Fixed #24148 -- Documented the 
bug with case expressions in SQLite < 3..0.

https://github.com/django/django/pull/3879 - Fixed #9893 -- Allowed using a 
field's max_length in the Storage.
https://github.com/django/django/pull/3918 - Fixed #24146 -- Fixed a 
missing fields regression in admin checks.

Reviews of core dev work



https://github.com/django/django/pull/3883 - Multiple template engines - 
continued

https://github.com/django/django/pull/3868 - Fixed #24060 -- Added OrderBy 
Expressions

https://github.com/django/django/pull/3878 - Fixed #24092 -- Widened base 
field support for ArrayField.

https://github.com/django/django/pull/3890 - Fixed #24123 -- Used all 
available migrations to generate the initial migration state

https://github.com/django/django/pull/3891 - Fixed #24129 -- Added 
indicator that migrations are rendering the initial state

https://github.com/django/django/pull/3913 - Fixed #24147 -- Prevented 
managers leaking model during migrations

https://github.com/django/django/pull/3894 - Fixed #24075 -- Prevented 
running post_migrate signals when unapplying initial migrations of 
contenttypes and auth

https://github.com/django/django/pull/3920 - Fixed #24152 -- Deprecated 
GeoQuerySet aggregate methods

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/b1676d67-aaa1-4c03-adfa-dee12f55d3ae%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[ANNOUNCE] Django 1.8 alpha 1 released

[Tim Graham]

We've made the first release on the way to Django's next long-term support 
release, Django 1.8! With only two and a half months until the scheduled 
final release, we'll need prompt testing from the community to ensure a 
timely and stable release. Check out the blog post:

https://www.djangoproject.com/weblog/2015/jan/16/django-18-alpha-1-released/

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/28462ef9-4769-4cfb-bb8c-65ac035506ca%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Fellow Report - January 16, 2015

[Tim Graham]

Thanks, Anssi. By the way, we are compiling testimonials to help in the 
fundraising efforts. Do you mind if we include those two sentences from 
you? (feel free to add a couple more sentences if you like). If anyone else 
would like to share one, please send them my way. I am especially 
interested in non-core team members perspective on the program. Also, feel 
free to share any general feedback (positive or negative) -- even if you 
don't want it posted as a testimonial on the fundraising page. Thank you!

On Monday, January 19, 2015 at 5:20:49 AM UTC-5, Anssi Kääriäinen wrote:
>
> On Friday, January 16, 2015 at 10:19:15 PM UTC+2, Tim Graham wrote:
>>
>> Here’s my final report for the 3 month fellowship pilot. I hope the DSF’s 
>> fundraising efforts will be successful and I’ll have an opportunity to "be 
>> back" soon. :-)
>>
>
> From my point of view the fellowship pilot has been a huge success. The 
> amount of tickets and patches worked on during the pilot is astounding.
>
> A very big thank you, and lets hope the fundraising program is successful.
>
>  - Anssi
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/490e2218-2e6c-41f4-a625-0778ff2d237a%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

docstring verbs

[Tim Graham]

The current version of our style guide [1] recommends to use "action verbs" 
(Checks instead of Check). However this contradicts PEP 257 (Docstring 
Conventions) [2]. The current code mixes these two forms. Claude advocates 
to follow the PEP [3]. Anyone care to comment on the historical reason we 
deviated from it and whether or not we should switch?

[1] 
https://docs.djangoproject.com/en/dev/internals/contributing/writing-code/coding-style/#python-style

[2] ​https://www.python.org/dev/peps/pep-0257/
[3] https://code.djangoproject.com/ticket/24175

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/a37f3514-1d2e-46b0-b104-c020166b8125%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Pull request builder now on Ubuntu 14.04

[Tim Graham]

The pull request builders are now running on Ubuntu 14.04. The master still 
runs 12.04 and handles builds for versions older than 1.8 as those builds 
don't pass on 14.04. Also I've reserved three of the slaves for the pull 
request builder -- this should hopefully cut down on the dreaded "git 
checkout  where hash was not the commit" errors.

A reminder that the documentation for the CI cluster is on the wiki:
https://code.djangoproject.com/wiki/Jenkins

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/928b72f7-3ad0-480e-8c89-494b119f58bc%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Can't login after upgrading to 1.7.3, and workaround

[Tim Graham]

I think that's a bit different from the originally reported issue, but it 
seems like a reasonable thing to fix if we can.

On Monday, January 26, 2015 at 5:43:54 PM UTC-5, Florian Apolloner wrote:
>
> I can reproduce the issue:
>
> Log a user into the admin
> Change iteration count
> Use a new browser (or private window) and log the same user into the admin
> Refresh the admin page of the first user -> login window
>
> Cheers,
> Florian
>
> On Thursday, January 15, 2015 at 2:31:55 AM UTC+1, Tim Graham wrote:
>>
>> Hi Horacio,
>>
>> Thanks for the report. Unfortunately, I can't reproduce this issue.
>>
>> My steps to reproduce using the project from the tutorial:
>> Bump PBKDF2PasswordHasher.iterations to a higher value
>> Login at /admin/
>> Confirm at /admin/auth/user/#/ that the password of the user I logged in 
>> as reflects the new iteration count.
>>
>> Maybe there is something different in your setup?
>>
>> On Wednesday, January 14, 2015 at 4:57:13 PM UTC-5, Horacio G. de Oro 
>> wrote:
>>>
>>> The problem is because the iterations in PBKDF2PasswordHasher where 
>>> updated to 15000, so it updates the password, but later, 
>>> SessionAuthenticationMiddleware detects a password change and PUF! the 
>>> login doesn't work.
>>>
>>> Right new I've created a PBKDF2PasswordHasher implementation with 
>>> iteartions = 12000 (the old value), but I want to report the issue (I don't 
>>> know if this is a bug) in case it happens to anyone else.
>>>
>>> Saving the user returned by authenticate() before calling login() solved 
>>> the issue too, but I dont' want to save the user just in case the password 
>>> changed.
>>>
>>> Regards!
>>> Horacio
>>>
>>>
>>> --
>>> Horacio G. de Oro
>>> Email: hgd...@gmail.com
>>> Web: http://www.data-tsunami.com
>>> LinkedIn: https://www.linkedin.com/in/hgdeoro
>>>
>>>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/e926327b-da72-47b1-851c-e9294f8e3485%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.