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

[Collin Anderson]

Hi Aymeric,

Thanks for all of your work on this. Am I too late to discuss the settings?

I don't see much advantage to the OPTIONS dict. It is consistent with 
DATABASES, and it separates the engine specific settings from the common 
settings. However, it doesn't seem like that helpful of a distinction to 
the user, especially considering there's only 3(?) non-OPTIONS settings. It 
seems like it only opens up the door to misconfiguration. Could we just 
pop-off the 3 common settings when configuring the template engine?

Thanks,
Collin


-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to 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/adf99a14-e993-490f-b713-7ca68fd201f8%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

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

[Collin Anderson]

Hi All,

On Monday, November 3, 2014 5:54:38 PM UTC-5, Carl Meyer wrote:
>
> I favor keeping OPTIONS. I don't think OPTIONS will be significantly 
> confusing to beginners (it may even provide a useful hedge between "the 
> basics" and "the advanced knobs"). 
>
> Once you are doing anything beyond the basics, the distinction between a 
> setting that is handled specially by Django vs one that is just passed 
> as-is to the template backend is an important distinction to keep clear. 
>
 That makes sense, though, is it just me or is CONTEXT_PROCESSORS a fairly 
frequently configured setting? My main use case is to enable the request 
context processor.

Collin

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to 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/bceedf80-c514-4cc5-a6cf-b88f764e54ee%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [RFC] Python 3 and MySQL

[Collin Anderson]

I started the ball rolling on getting mysqlclient packaged in Debian/Ubuntu.

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=768096

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to 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/382ac68c-e992-4b1f-b50c-917057036e04%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

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

[Collin Anderson]

On Tuesday, 4 November 2014 17:30:27 UTC-5, Aymeric Augustin wrote:
>
> In my opinion the request context processor should be enabled by default.
>
+1 

> I suspect the only reason why it isn't is to avoid changing the default 
> settings (django.conf.global_settings).
>
Right. Can we uncomment it anyway? I can't imagine that there are many 
people are using the "request" name for anything other than the django 
request.

Or, I would also be happy with a render('template.html', {'request': 
request, 'myvar': 3}) convention and then stop using context processors 
completely.

Thanks,
Collin

 

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to 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/9920e493-a478-41e4-94e6-bcc5ba669037%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

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

[Collin Anderson]

Could we do a list of 2-tuples instead of OrderdDict?

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to 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/05874603-ff79-4ce4-b191-c087969d90dc%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Information on construction of object on form (philosophy)

[Collin Anderson]

Hello,

The way  works in html forms, there's no distinction 
between "unchecked" and "form field not present". The browser won't even 
send an empty key for the the checkbox at all if it's not checked. 
Therefore, if the django form has a BooleanField and doesn't see a key in 
the data for it, then it needs to assume a false value.

The "data" argument on a django form is expected to be fairly raw browser 
data.

You may either want to create the fields on the form dynamically based on 
what keys are present in your data, or dynamically remove the non-existent 
fields from form.fields in __init__ once you have the data.

Collin


On Tuesday, November 18, 2014 12:21:38 PM UTC-5, aRkadeFR wrote:
>
> Hello everyone, 
>
> Sorry to bother cause I did a ticket and got an answer by Tim Graham. 
> https://code.djangoproject.com/ticket/23760 
>
> But I wonder what's the philosophy of the Django developers community on 
> this ticket. 
> If Tim Graham want to be more explicit here, I would be really happy to 
> read from all of you. 
>
>  From my point of view, in many case it's not a developer error, it can 
> be a template problem, a 
> generation of the data not updated before handled to the form __init__ 
> problem, or so much 
> more. 
>
> Plus, it's not "new django developer" friendly. 
>
> If the object created, even though there's missing fields in the form, 
> can created the object 
> attribute with the default one, it would be much more friendly. 
>
> Thank you 
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To 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/0efc5dd3-01e8-4a9e-8fc1-8335d70b45a9%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Information on construction of object on form (philosophy)

[Collin Anderson]

Philosopy-wise, I agree it would be good (and more secure) to error if the 
form detects that a field was not present in the html, however it's not 
possible to properly detect it in every case.

On Tuesday, November 18, 2014 12:39:03 PM UTC-5, Collin Anderson wrote:
>
> Hello,
>
> The way  works in html forms, there's no 
> distinction between "unchecked" and "form field not present". The browser 
> won't even send an empty key for the the checkbox at all if it's not 
> checked. Therefore, if the django form has a BooleanField and doesn't see a 
> key in the data for it, then it needs to assume a false value.
>
> The "data" argument on a django form is expected to be fairly raw browser 
> data.
>
> You may either want to create the fields on the form dynamically based on 
> what keys are present in your data, or dynamically remove the non-existent 
> fields from form.fields in __init__ once you have the data.
>
> Collin
>
>
> On Tuesday, November 18, 2014 12:21:38 PM UTC-5, aRkadeFR wrote:
>>
>> Hello everyone, 
>>
>> Sorry to bother cause I did a ticket and got an answer by Tim Graham. 
>> https://code.djangoproject.com/ticket/23760 
>>
>> But I wonder what's the philosophy of the Django developers community on 
>> this ticket. 
>> If Tim Graham want to be more explicit here, I would be really happy to 
>> read from all of you. 
>>
>>  From my point of view, in many case it's not a developer error, it can 
>> be a template problem, a 
>> generation of the data not updated before handled to the form __init__ 
>> problem, or so much 
>> more. 
>>
>> Plus, it's not "new django developer" friendly. 
>>
>> If the object created, even though there's missing fields in the form, 
>> can created the object 
>> attribute with the default one, it would be much more friendly. 
>>
>> Thank you 
>>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To 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/95623339-37d2-4736-8939-725cfaa70f31%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Adding hard dependencies to Django's test suite

[Collin Anderson]

I'm -0 for freezegun, +0 for unittest.

I see unittest as a polyfill that we'll only need to keep around for about 
3 years, and I like the "nudging people to use python3"

Freezegun is a less popular, less established library, and I'd personally 
still rather see it be an optional dependency. 

I think pip helps a lot with dependencies, but I don't think it solves all 
problems. It would still be great to run and test django without needing to 
use a virtual environment (even if only on the latest version of python).

(But, as always, I'm not the one writing the tests :)

Collin

On Friday, November 28, 2014 12:36:27 PM UTC-5, Jannis Leidel wrote:
>
>
> > On 28 Nov 2014, at 02:42, Tim Graham > 
> wrote: 
> > 
> > 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? 
>
> +1 on assuming pip or another installer for running the Django tests. 
>
> Providing a requirements file for the tests is even more awesome, but 
> let's say no to VCS requirements and always require the dependencies to be 
> hosted on PyPI. 
>
> 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/6d91dcda-2461-4e1b-a6ba-4dcf57725054%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: delegating our static file serving

[Collin Anderson]

Hi All,

I think doing something here is really good idea. I'm happy with any of the 
solutions mentioned so far.

My question is: what does static/dj-static do that our built-in code 
doesn't do? What makes it more secure? It seems to me we're only missing is 
wsgi.file_wrapper and maybe a few more security checks. Why don't we just 
make our own code secure and start supporting it?
Here's basic wsgi.file_wrapper support: 
https://github.com/django/django/pull/3650

We could then, over time, start supporting more extensions ourselves: 
ranges, pre-gziped files, urls with never-changing content, etc. That way 
we get very, very deep django integration. It seems to me this is a piece 
that a web framework should be able to support itself.

Collin


On Friday, November 28, 2014 9:15:03 AM UTC-5, Tim Graham wrote:
>
> 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/e3be33a3-3675-4397-b017-e0565bda84fb%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

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

[Collin Anderson]

I was just thinking about this. I agree that a GET causing logout is wrong, 
and we need to not break things and I agree we need to keep the original 
view untouched so we don't break anything. _maybe_ deprecate it. The admin 
could begin using the new view right away.

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/cbd1d995-6a3b-4ce2-b31d-cf533ac65758%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: delegating our static file serving

[Collin Anderson]

Hi All,

I'm pretty interested in getting secure and _somewhat_ efficient static 
file serving in Django.

Quick history:
2005 - Jacob commits #428: a "static pages" view.  Note that this view 
should only be used for testing!"
2010 - Jannis adds staticfiles. Serving via django is considered "grossly 
inefficient and probably insecure".
2011 - Graham Dumpleton adds wsgi.file_wrapper to Gunicorn.
2012 - Aymeric adds StreamingHttpResponse and now files are read in chunks 
rather than reading the entire file into memory. (No longer grossly 
inefficient IMHO.)

I propose:
- Deprecate the "show_indexes" parameter of static.serve() (unless people 
actually use it).
- Have people report security issues to secur...@djangoproject.com (like 
always)
- Audit the code and possibly add more security checks and tests.
- add wsgi.file_wrapper support to responses (5-line proof of concept: 
https://github.com/django/django/pull/3650 )
- support serving static files in production, but still recommend 
nginx/apache or a cdn for performance.
- make serving static files in production an opt-in, but put the view in 
project_template/project_name/urls.py

I think it's a huge win for low-traffic sites or sites in the "just trying 
to deploy and get something live" phase. You can always optimize later by 
serving via nginx or cdn.
We already have the views, api, and logic around for finding and serving 
the correct files.
We can be just as efficient and secure as static/dj-static without needing 
to make people install and configure wsgi middleware to the application.
We could have staticfiles classes implement more complicated features like 
giving cache recommendations, and serving pre-gzipped files.

Is this a good idea? I realize it's not totally thought through. I'm fine 
with waiting until 1.9 if needed.

Collin

On Saturday, November 29, 2014 6:07:05 PM UTC-5, Collin Anderson wrote:
>
> Hi All,
>
> I think doing something here is really good idea. I'm happy with any of 
> the solutions mentioned so far.
>
> My question is: what does static/dj-static do that our built-in code 
> doesn't do? What makes it more secure? It seems to me we're only missing is 
> wsgi.file_wrapper and maybe a few more security checks. Why don't we just 
> make our own code secure and start supporting it?
> Here's basic wsgi.file_wrapper support: 
> https://github.com/django/django/pull/3650
>
> We could then, over time, start supporting more extensions ourselves: 
> ranges, pre-gziped files, urls with never-changing content, etc. That way 
> we get very, very deep django integration. It seems to me this is a piece 
> that a web framework should be able to support itself.
>
> Collin
>
>
> On Friday, November 28, 2014 9:15:03 AM UTC-5, Tim Graham wrote:
>>
>> Berker has worked on integrating gunicorn with runserver 
>> <https://github.com/django/django/pull/3461> so that we might be able to 
>> deprecate our own homegrown webserver. Windows support for gunicorn is 
>> supposedly coming soon <https://github.com/benoitc/gunicorn/issues/524>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 
>> <https://github.com/kennethreitz/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 
>> <https://pypi.python.org/pypi/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/bfc1eb0d-8b69-4450-bfe0-7147ef729317%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Settings: lists or tuples?

[Collin Anderson]

I agree lists are the way to go. I have heard that tuples are faster, but I 
don't think that outweighs comma issue and inconsistency.

global_settings isn't completely undocumented, based on greping the docs. 
Seems to me we should at least make the docs and project_template 
consistent and use lists everywhere.

On Wednesday, December 17, 2014 4:04:22 PM UTC-5, Aymeric Augustin wrote:
>
> On 17 déc. 2014, at 21:54, Carl Meyer > 
> wrote: 
>
> > So I think there is a backwards-compatibility issue. 
>
> Indeed. 
>
> > Personally, I would love to decide to just bite this bullet and 
> > normalize to lists, but I think it would need to be marked as a 
> > backwards-incompatibility in the release notes, and it would certainly 
> > bite people. 
>
> We can do that. The error is easy to fix if it occurs. Technically 
> django.conf.global_settings is a private API. 
>
> But I feel guilty to break code just for consistency and aesthetics :-/ 
>
> -- 
> 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/02dd5042-6b79-4d1c-8c80-0559e69fb53f%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Bypassing 1.7+ migrations

[Collin Anderson]

Hi All,

Totally a shot in the dark here, but would allow_migrate work in this case?

https://docs.djangoproject.com/en/dev/topics/db/multi-db/#allow_migrate

Collin

On Friday, December 19, 2014 2:04:37 PM UTC-5, Carl Meyer wrote:
>
> On 12/19/2014 11:59 AM, Marcin Nowak wrote: 
> > 
> > 
> > On Friday, December 19, 2014 12:19:11 AM UTC+1, Shai Berger wrote: 
> >> 
> >> 
> >> As far as I understood, Marcin wants to treat *all* models as 
> unmanaged; 
> >> there 
> >> are no managed models to reference the unmanaged ones. 
> >> 
> > 
> > I would like to disable/remove/kick-off built-in migration mechanism. :) 
> > 
> > If may I suggest something - the migration subsystem should be delivered 
> in 
> > the same way as other "contrib" apps. 
> > It should be an extension similar to South, but delivered as a part and 
> of 
> > framework. 
>
> The "syncdb" functionality is on its way to deprecation, replaced by 
> migrations, so at some point within a few releases migrations will be 
> the only way Django can translate your models into database schema. This 
> is not an optional contrib add-on, it's a core part of the ORM. 
>
> That said, if you don't want to use migrations, you don't have to - it 
> just means that you are 100% responsible for creating and modifying your 
> necessary database tables. That's what setting `managed = False` on the 
> `Meta` of all your models will accomplish. 
>
> 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/a1ad6468-d78e-4c8a-9dcf-30c534ef7b60%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Delivering PR 3114 - The _meta refactor

[Collin Anderson]

Ditto. I'm ok with a tiny shim for GFK, and we should get the API right for 
RelatedObject going forward, (as long as it's at least _possible_ to detect 
which is which and write code that works on both 1.7 and 1.8).

On Monday, December 22, 2014 9:29:15 AM UTC-5, Aymeric Augustin wrote:
>
> Hi Russell,
>
> 2014-12-22 8:39 GMT+01:00 Russell Keith-Magee  >:
>
>> The question: Do we - 
>>
>> 1) Accept this particular internal specific naming of GFK as a quirk 
>> reflecting the limitations of contrib.admin
>>
>> 2) Try to nail down what a "virtual" field means, or find some 
>> alternative flag to identify what "GFK" is a proxy for in this case.
>>
>
> I'm in favour of (1) mostly because of the YAGNI principle. Defining 
> "virtual"  without a concrete use case sounds hard.
>
>
> The question: Do we:
>>
>> 1) Accept this as a backwards incompatible change.
>>
>> 2) Accept the inconsistency in the new API.
>>
>> 3) Find a pair of names other than model/related_model to represent the 
>> "subject/object" pair in fields
>>
>
> I'm also in favour of (1) because the point of a refactoring is to clean 
> up inconsistencies. We can say something in the release notes to help 
> people who have used the RelatedObject private API.
>
>
> Best,
>
> -- 
> 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/13baaf10-2395-47f6-8d1a-3a3b1543b7ff%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Delivering PR 3114 - The _meta refactor

[Collin Anderson]

Odd. We should really save the "through" attribute on the m2m field itself. 
Maybe in 1.9...

On Tuesday, December 23, 2014 8:33:58 AM UTC-6, Tom Christie wrote:
>
> Thanks Russ, appreciate your time. 
>
> I've no great problem with keeping 'through' table API undocumented with 
> 1.8, probably doesn't matter too much either way. Just flagging it up, but 
> looks like 'no change' there, which is okay.

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to 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/ffaaeb71-5e3a-42e5-8baf-177b02d7a4fd%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: intended security model for templates

[Collin Anderson]

I also think the "load your tag lib by default for your project" is a good 
idea. It's a tad magical, but very nice.

On Sunday, December 28, 2014 5:26:46 PM UTC-6, Curtis Maloney wrote:
>
> I certainly like the idea of making public the API to load your tag lib by 
> default for your project.  It's there, it's clean, and it's been stable for 
> a looong time.  Of course, the multi-template-engine work may change this.
>
> Also, I agree that "explicit is better than implicit", and thus reducing 
> the number of places Django "discovers" things, instead of being instructed 
> where to look, is probably a good idea.
>
> --
> Curtis
>
>
> On 27 December 2014 at 10:18, Shai Berger  > wrote:
>
>> On Wednesday 24 December 2014 20:35:09 Tim Graham wrote:
>> > 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.
>>
>> In addition to what Curtis and Florian said, the ticket was made before 
>> the
>> default-project-layout change that made project-apps common; since Django 
>> 1.4
>> (or was it 1.3?) those have been a natural place for "common tags [to] be 
>> kept
>> together".
>>
>> Reading also the ticket, I agree with Carl's argument that the libraries
>> available for loading should be explicitly controlled from Python code. In
>> fact, this point makes me wonder if it wouldn't be better (ignoring 
>> backwards
>> compatibility, of course) to require custom tags to be passed in through 
>> the
>> context ("project-global" custom tags could then be added in a context-
>> processor).
>>
>> Shai.
>>
>
>

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

simplifying the default template context_processors

[Collin Anderson]

Hi All,

In talking to Aymeric and other developers, we're starting to think about 
the usefulness of global template context_processors. It seems to us that 
ideally you should only need the "request" context processor. You could 
even imagine removing context_processors all together and having render() 
and class based views simply put the request in the context.

Some ways to avoid context processors:
{% static "my.css" %} instead of {{ STATIC_URL }} (a good idea regardless)
{{ mediafile.url }} instead of {{ MEDIA_URL }}
{{ request.user }} instead of {{ user }}
{% get_current_timezone as TIME_ZONE %}
{% get_current_language as LANGUAGE_CODE %}

I propose:

- Enabling the request context processor for new projects.
- Modifying the admin to work without context 
processors. https://code.djangoproject.com/ticket/24117
- Removing the other context processors for new projects. (Possibly waiting 
for 1.9).
- Possibly adding `request.messages` similar to `request.user`.
- Maybe adding `user.perms` or a template tag to replace {{ perms }}

This would be a somewhat controversial change. I think django originally 
tried hard to keep the request as separate from the response as possible. 
This would tie the two together even more. In my experience working with 
django projects, it's often very helpful to have the request object 
directly available in templates.

What do you think?

Collin


-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to 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/bf74b593-3fbb-46fe-89f6-ce280124d707%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: simplifying the default template context_processors

[Collin Anderson]

Hi All,

Based on the early feedback, here's a scaled back proposal:

1. In the project_template settings.py for new projects:
- Enable the request context processor
- Keep the auth context processor
- Remove the rest (you can always install them by hand).
2. Make the admin work without needing specific context_processors enabled.

It sounds like context_processors as a feature are here to stay, but here 
are some alternatives anyway:
- Request attributes added by a middleware, like request.cart for a store. 
These can also be used in views.
- Assignment tags, like {% get_navigation as nav %}. I agree creating 
custom template tags is not fun.

Reusable apps can't assume specific context_processors are installed and 
may need to use alternatives anyway.

Collin

On Saturday, January 10, 2015 at 6:42:21 PM UTC-5, Russell Keith-Magee 
wrote:
>
>
> On Sun, Jan 11, 2015 at 6:40 AM, Collin Anderson  > wrote:
>
>> Hi All,
>>
>> In talking to Aymeric and other developers, we're starting to think about 
>> the usefulness of global template context_processors. It seems to us that 
>> ideally you should only need the "request" context processor. You could 
>> even imagine removing context_processors all together and having render() 
>> and class based views simply put the request in the context.
>>
>> Some ways to avoid context processors:
>> {% static "my.css" %} instead of {{ STATIC_URL }} (a good idea regardless)
>> {{ mediafile.url }} instead of {{ MEDIA_URL }}
>> {{ request.user }} instead of {{ user }}
>> {% get_current_timezone as TIME_ZONE %}
>> {% get_current_language as LANGUAGE_CODE %}
>>
>> I propose:
>>
>> - Enabling the request context processor for new projects.
>> - Modifying the admin to work without context processors. 
>> https://code.djangoproject.com/ticket/24117
>> - Removing the other context processors for new projects. (Possibly 
>> waiting for 1.9).
>> - Possibly adding `request.messages` similar to `request.user`.
>> - Maybe adding `user.perms` or a template tag to replace {{ perms }}
>>
>> This would be a somewhat controversial change. I think django originally 
>> tried hard to keep the request as separate from the response as possible. 
>> This would tie the two together even more. In my experience working with 
>> django projects, it's often very helpful to have the request object 
>> directly available in templates.
>>
>> What do you think?
>>
>>
> I feel like I've missed part of a discussion. We're talking about the 
> contents of TEMPLATE_CONTEXT_PROCESSORS, right? What exactly is the issue 
> with global context processors? 
>
> Speaking personally - I'm definitely using global context processors at 
> the moment, and it isn't clear to me what alternative you're proposing.
>
> My use case - my site is multi-tenant, and on every request, I need to 
> exact who the tenant is, and a couple of important attributes of the user 
> in light of that tenancy. These attributes are all used in my site base 
> template, so it's not like they are only used on some views - they really 
> are used globally.
>
> However, I think my use case ultimately isn't that much different to the 
> messages case. contrib.messages is an optional app; if you're using it, 
> then you're probably going to have a place in your base template where you 
> want to display those messages. Making every view manually define that they 
> want to have messages available sounds extremely onerous; it would be 
> trivial to accidentally forget to add messages handling to a view, and site 
> behavior would be dramatically impacted. 
>
> At a conceptual level, I have no problem with the idea that there may be a 
> collection of context variables that need to be applied to *every* view - 
> or, at the very least, a significant subset of pages. I can see how you 
> might couple reworked context processors and middleware into a reworked 
> hierarchical URL structure (so a URL subtree has a particular set of 
> context processors and middlewares; subtrees of that subtree inherit those 
> augmentations; by default, there's only one URL subtree, so context 
> processors and middlewares are global). 
>
> So, unless there's a particularly compelling technical reason that I'm 
> missing, or an equally "global" alternative being proposed, I'm -1 to 
> removing TEMPLATE_CONTEXT_PROCESSORS.
>
> Yours,
> Russ Magee %-)
>
>

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

Re: simplifying the default template context_processors

[Collin Anderson]

Here's a PR for this change https://github.com/django/django/pull/3897

On Sunday, January 11, 2015 at 4:58:53 AM UTC-5, Aymeric Augustin wrote:
>
> On 11 janv. 2015, at 09:43, Russell Keith-Magee  > wrote: 
>
> > However, I'd still have some concerns about a project template that took 
> out all the "useful" utilities, and required users to remember the exact 
> spelling of half a dozen builtins to have functionality that would have 
> historically been automatic. 
>
> I would argue that many of them are only useful in a very loose sense :-) 
> and the most obviously useful one, request, is omitted. 
>
> I added the tz processor for consistency with the i18n processor but I 
> never used it and I don’t think it’s needed. 
>
> I don’t remember using on the i18n processor either. Perhaps some i18n 
> features implicitly depend on it. I would have to check. 
>
> The media and static processor enable obsolete template coding style. We 
> shouldn’t encourage their use. 
>
> Without having spent much time to research the consequences — it's on my 
> TODO list but Collin brought it up before I investigated — my straw man 
> proposal is: 
>
> TEMPLATES = [ 
> { 
> 'BACKEND': 'django.template.backends.django.DjangoTemplates', 
> 'DIRS': [], 
> 'APP_DIRS': True, 
> 'OPTIONS': { 
> 'context_processors': [ 
> 'django.template.context_processors.debug', 
> 'django.template.context_processors.request', 
> 'django.contrib.auth.context_processors.auth', 
> 'django.contrib.messages.context_processors.messages', 
> ], 
> }, 
> }, 
> ] 
>
> -- 
> 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/70e5b344-6ba6-48a1-a81a-9fd81770d94f%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Replace decimal prefix(kB) with binary prefix (KiB) for bytes

[Collin Anderson]

I'd be fine changing MB -> MiB in just docs wherever needed, and then not 
using KB or MB at all because of their ambiguity. I've seen "KiB" and "MiB" 
around before, but I've never seen "Mebi" before today.

On Monday, January 12, 2015 at 6:53:37 PM UTC-5, Markus Holtermann wrote:
>
> Hey folks, 
>
> I saw that the Django docs currently use file size units kB, MB, etc. 
> that refer to a multiple of 1000 (1000, 100 bytes respectively -- 
>
> https://docs.djangoproject.com/en/dev/ref/settings/#file-upload-max-memory-size
>  
> ). But the numbers actually are to the power of 1024. To remedy 
> inconsistencies there are binary prefixes KiB (Kibibyte), MiB 
> (Mebibyte), etc. which refer to 1024 and 1048576 bytes respectively ( 
> http://en.wikipedia.org/wiki/Binary_prefix ) 
>
> The Python documentation itself changed the notation about 2 years ago ( 
> http://bugs.python.org/issue17193 ) -- Thanks for the hint, Berker. 
>
> I therefore propose to change the notation to use the binary prefix. 
>
> I opened a ticket to track this proposal: 
> https://code.djangoproject.com/ticket/24140 
>
> Input and thoughts welcome :) 
>
> /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/024da3bd-9249-4893-a08d-55c561aa45ef%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Settings: lists or tuples?

[Collin Anderson]

Hi All,

Should change tuples to lists in more places in the docs?
https://github.com/django/django/pull/3929

Collin

On Thursday, December 18, 2014 at 7:56:47 AM UTC-5, Carl Meyer wrote:
>
> On 12/17/2014 11:49 PM, Russell Keith-Magee wrote: 
> > On Thu, Dec 18, 2014 at 7:48 AM, Carl Meyer  > wrote: 
> >> This is clever, but on second thought I'm trying to figure out in what 
> >> scenario a backwards-compatibility would actually occur here. In the 
> >> context of a user's settings modules, global_settings plays no role at 
> >> all: you can't add to a global setting default in your settings.py 
> >> (unless you've imported global_settings yourself, which is certainly 
> >> making use of undocumented internals). 
> >> 
> >> So it seems to me that the only scenario in which this would actually 
> >> cause a back-compat problem would be if someone is using a tuple 
> >> setting, which they are not setting themselves (and thus are using the 
> >> global default), and they are adding to it in their runtime code (not 
> in 
> >> their settings file). For instance: 
> >> 
> >> my_ctx_procs = settings.TEMPLATE_CONTEXT_PROCESSORS + ('another',) 
> >> 
> >> The common case of appending to a setting in your settings.py (due to 
> >> use of some kind of split-settings) should not be impacted at all 
> >> 
> > 
> > That's a fair point. The benefit for an __add__ definition is likely to 
> be 
> > a lot smaller than I originally thought. 
> > 
> > The only place I can think that it might pop up is in older (pre 
> > @override_settings) test harnesses; that said, a failure during test 
> isn't 
> > a major inconvenience 
> > 
> > So - I retract my suggestion - I think I can live with just documenting 
> > this as a backwards compatibility. 
>
> Works for me! 
>
> 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/38ba3ba6-86e3-40c5-b251-6a6ed2d3f3d0%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Settings: lists or tuples?

[Collin Anderson]

Hi Andreas,

I agree that tuples do slightly help enforce that settings are supposed to 
be immutable, and I agree that if someone were to try to modify the 
settings the way you showed it would be very hard to debug. However, I 
think it's a pretty rare case.

I think a much more common case is the trailing comma problem with single 
element tuples. This can also be very frustrating for beginners. I'd 
personally rather help out the beginner cases than someone attempting to do 
things that they shouldn't be doing.

I also think lists of tuples are easier to read than tuples of tuples.

Anyone could still use tuples in their settings if they want the extra 
strength.

What do you think?

Collin

On Monday, January 19, 2015 at 10:05:46 AM UTC-5, Andreas Kahnert wrote:
>
> Test Code:
> old_var = settings.TEMPLATE_DIRS
> settings.TEMPLATE_DIRS += ('foo',) if isinstance(settings.TEMPLATE_DIRS, 
> tuple) else ['foo']
> old_var is settings.TEMPLATE_DIRS  # will return True if it was a list; 
> will return False if it was a tuple, since a new tuple was assigned to 
> settings.TEMPLATE_DIRS (violating the docs)
>
> This was just a silly example, but if think of modularity and so on, this 
> could get a disaster. The assignment could be somewhere in a 
> helper-function where it's not obvious that the list originates from the 
> settings. Another helper-function might use settings.TEMPLATE_DIRS to 
> iterate over (maybe to validate all templates are reachable or something) 
> yielding different results than the framework actual usage. Debuging this 
> would be pretty hard (especially for those who arn't aware of the subtile 
> differences between lists and tuples)
>
>
> Am Montag, 19. Januar 2015 15:49:37 UTC+1 schrieb Marc Tamlyn:
>>
>> I think Florian's point would be that you can still do:
>>
>> from django.conf import settings
>> settings.TEMPLATE_DIRS += ('foo',)
>>
>> if it is a tuple, so I don't really see how it being a tuple is making it 
>> necessarily more safe than a list - is the above code really much different 
>> to:
>>
>> from django.conf import settings
>> settings.TEMPLATE_DIRS.append('foo')
>>
>> On 19 January 2015 at 14:45, Andreas Kahnert  
>> wrote:
>>
>>> I'm not talking about modifications inside the settings.py but in other 
>>> place. With lists, unexperienced devs might do things like: from 
>>> django.conf import settings; settings.TEMPLATE_DIRS[3] = '/my_tpls'; and 
>>> expect to work out good. (This doesn't violate the docs, since technicaly 
>>> settings.TEMPLATE_DIRS is still the same list, means the settings variable 
>>> itself hasn't been changed.) This is realy just a question of logic: lists 
>>> are mutable - settings are immutable; see the conflict?
>>>
>>> Am Montag, 19. Januar 2015 14:20:51 UTC+1 schrieb Florian Apolloner:
>>>


 On Monday, January 19, 2015 at 12:35:10 PM UTC+1, Andreas Kahnert wrote:
>
> I'm strongly against lists. Lists are mutable objects, their 
> components can be changed in place. The settings are initialized at 
> server 
> start and after that changes on them arn't reflected. Therefore all 
> settings should be tuples from my point of view. Using a custom 
> list/tuple 
> class for "easy" notation within the settings.py might be an option, but 
> after server startup all of those should be immutable. So for the sake of 
> logic, take tuples, please.
>

 As long as  something like settings.MY_SETTING=(1,); 
 settings.MY_SETTING+=(1,2,3) works, that argument is kinda moot imo.

 Cheers,
 Florian

>>>  -- 
>>> You received this message because you are subscribed to the Google 
>>> 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/5b974048-0c9f-4ae2-8ff2-8db1fbd736f4%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/e003c6b4-ea5b-470c-bf0f-30ec115bb5c3%40googlegroups.com.
For more o

Re: automated import sorting and better pull request checks

[Collin Anderson]

I personally prefer multi_line_output = 4 (closing parentheses on the same 
line), but no big deal either way.

On Thursday, January 29, 2015 at 10:56:03 AM UTC-5, Tim Graham wrote:
>
> Here's the current iteration of the config (it's stored in setup.cfg).
>
> [isort]
> combine_as_imports = true
> known_first_party = django
> multi_line_output = 5
> skip = build,.git
>
> On Thursday, January 29, 2015 at 9:39:04 AM UTC-5, Aymeric Augustin wrote:
>>
>> Hi Tim,
>>
>> Good idea. There are so many changes on PR 4009 that I couldn't check if 
>> you wrote a .isort.cfg. Did you, or are you just using the defaults?
>>
>> -- 
>> Aymeric.
>>
>> 2015-01-29 14:18 GMT+01:00 Tim Graham :
>>
>>> As a code reviewer, I've really appreciated that we've cleaned up the 
>>> code using flake8 and have automated "enforcement" via the CI server. I'd 
>>> like to extend the idea to apply to standardizing import ordering using 
>>> isort [1]. This mail is to advise everyone of the change and to address any 
>>> concerns.
>>>
>>> Documentation:
>>> https://github.com/django/django/pull/4008
>>>
>>> Automated cleanups:
>>> https://github.com/django/django/pull/4009
>>>
>>> On a related note, the UI for flake8 errors isn't currently very good 
>>> (you have to look at the bottom of the Jenkins build logs). I'd like to 
>>> improve that by using a separate service that uses the GitHub status API 
>>> [2] so that the check can run separately from the tests build. I don't want 
>>> to reinvent the wheel though, so if there is an existing service we can use 
>>> for this, great. I'd like to also add checks for documentation build and 
>>> spelling errors, as well as isort checks (assuming adoption per above).
>>>
>>> [1] https://github.com/timothycrosley/isort#readme
>>> [2] 
>>> https://github.com/blog/1935-see-results-from-all-pull-request-status-checks
>>>
>>> -- 
>>> You received this message because you are subscribed to the Google 
>>> 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/d356e388-fa45-4fdf-871f-ce484a7b43bf%40googlegroups.com
>>>  
>>> 
>>> .
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>>
>>
>>
>> -- 
>> 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/21a9602e-280d-4c8d-b8dc-662f5fec8656%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Feature proposal: Conditional block tags

[Collin Anderson]

Sounds like a spot where we might be able to improve the documentation.

On Sunday, February 1, 2015 at 10:33:09 AM UTC-5, Markus Amalthea Magnuson 
wrote:
>
> Which is, I guess, why it is the block tag's behavior that would need to 
> change rather than the if tag's, if support for blocks inside if tags were 
> to be implemented.
>
> Have not had a look myself at this though, but I too was confused the 
> first few times I tried to put blocks in if statements and not getting it 
> to work.
>
> On Sun, Feb 1, 2015 at 2:57 PM, Raphael Michel  > wrote:
>
>> Hi,
>>
>> Am Sat, 31 Jan 2015 22:36:05 +0100
>> schrieb Aymeric Augustin >:
>> > I suspect it has to do with {% if %} being interpreted at runtime
>> > while {% block %} is interpreted at compile time.
>> >
>> > I never investigated this fully. If someone does, I’m interested :-)
>>
>> This was my guess as well. However, if this indeed is the reason, then
>> a {% block … if … %} syntax would make it impossible to interpret
>> blocks at compile time, and I don't think Markus' proposal (or the {%
>> if %}{% block %} syntax, which I do like more than {% block if %}) is
>> worth that effort.
>>
>> Raphael
>>
>> --
>> You received this message because you are subscribed to the Google 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/20150201145722.76fae6d0%40arlen
>> .
>> 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/041b3568-8c2b-42ad-b28e-df5609a2f25a%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: resurrecting an old friend, whitespace in forms, #6362

[Collin Anderson]

Hi frantisek,

I've also ran into a number of problems with extra whitespace in forms. 
Pretty annoying.

I also find settings pretty annoying. :) We were just talking on another 
thread [1] about the possibility of packaging packaging django.forms as a 
standalone package, but global settings are one of the main roadblocks to 
doing that.

Here are a few more possible solutions:

1.  Include some javascript on your page that .trim()s everything, maybe 
onsubmit.
2.  form = Form({k: v.strip() for k, v in request.POST.items()})
3.  Use a custom form subclass that strips the incoming values in __init__
4.  call strip() on model.save() or a pre_save signal.

[1] https://groups.google.com/d/msg/django-developers/WF3My-cZNtY/V0Z8QkQaOnAJ

Collin

On Tuesday, February 3, 2015 at 12:22:38 PM UTC-5, frantisek holop wrote:
>
> good day, 
>
> a recent technical support incident conducted remotely and 
> involving a lot of back and forth of "huh? but i have entered 
> what you sent me" left me my head scratching. 
>
> the reason turned out to be a trailing space in the username of 
> the django admin loginform (thank god for nginx's "$request_body" 
> log_format parameter). 
>
> this of course sent me on an archeological journey into the lands 
> of stackoverflow, blogs, and finally #6362 and this mailing list. 
> it has been some 5 years now since the decision on that 
> controversial ticket. 
>
> i also went through the whole emotianal rollercoaster: 
>
> how come, so many batteries are included, but when it comes to 
> this essential POST best practice, i needed in every single 
> webform i have ever made, and now i have to do it myself? 
> error-prone and not DRY. especially for the admin login form, 
> it is a usability issue. 
>
> vs 
>
> the BDFL is right, silently discarding user input is just wrong. 
> just use a package like happyforms[1], or pick a stackoverflow 
> answer and be done with it. 
>
>
> but wait, then HTML is also wrong, because it silently folds all 
> whitespace into 1 piece of space, we are all used to this.  even 
> if the user entered whitespace is saved, pushing it back onto the 
> web will silently corrupt it (unless taken care of).  i am not 
> saying this requirement does not exist for someone, somewhere, 
> but i have yet to see a site in the wild that needs this (hello, 
> ascii art people).  whitespace in fields was always reserved for 
> government sites :) 
>
>
> it seems to me that there is a vocal group (majority?) that would 
> welcome a simple switch to make whitespace go away _now_, instead 
> of waiting for that perfect solution lurking in the future along 
> the lines of a generic normalize kwarg, or a flag on _every_ 
> {Char,Text}Field on the model or overriding form.fields 
> attributes like required. 
>
> apps that need to preserve the whitespace are the exception, 
> not the rule, and that is why i would prefer not to start every 
> project by overriding BaseForm._clean_fields[2]. 
>
> so i would like to present another idea for a possibe solution, a 
> proposal i have not seen so far: to have a global setting like 
> FORM_STRIP_FIELDS=True or some such and then roughly: 
>
> diff --git a/django/forms/forms.py b/django/forms/forms.py 
> index c9b8cf2..aab737a 100644 
> --- a/django/forms/forms.py 
> +++ b/django/forms/forms.py 
> @@ -8,6 +8,7 @@ from collections import OrderedDict 
>  import copy 
>  import datetime 
>   
> +from django.conf import settings 
>  from django.core.exceptions import ValidationError, NON_FIELD_ERRORS 
>  from django.forms.fields import Field, FileField 
>  from django.forms.utils import flatatt, ErrorDict, ErrorList 
> @@ -355,6 +356,8 @@ class BaseForm(object): 
>  if isinstance(field, FileField): 
>  initial = self.initial.get(name, field.initial) 
>  value = field.clean(value, initial) 
> +elif isinstance(value, basestring) and 
> settings.FORM_STRIP_FIELDS: 
> +value = field.clean(value.strip()) 
>  else: 
>  value = field.clean(value) 
>  self.cleaned_data[name] = value 
>
> i know, it is a big hammer, but for me, it is like the timezone, 
> or csrf, i'd like to just set it, and forget about it. 
>
> -f 
>
> [1] https://pypi.python.org/pypi/happyforms 
> [2] http://chriskief.com/2012/12/21/trim-spaces-in-django-forms/ 
> -- 
> nobody can be exactly like me.  even i have trouble doing so. 
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to 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/c9

Re: CSRF REASON_NO_REFERER with meta referrer tags

[Collin Anderson]

If we add Origin checking, could we then allow a missing referrer and 
token? (check referrer and token if no origin header)

On Tuesday, February 3, 2015 at 5:15:08 PM UTC-5, Paul McMillan wrote:
>
> The referer check is primarily there to help make users who choose not 
> to use HSTS safer. 
>
> Without HSTS, a mitm can set CSRF cookies (e.g. by serving an HTTP 
> page emulating your domain in an iframe on a different unencrypted 
> page, even if you only ever serve your own page from HTTPS), and then 
> post (from wherever) to your secured page. By forcing the post to come 
> from the same domain, we've made this attack significantly less 
> convenient. 
>
> I agree that it's really unfortunate that we don't have a better 
> mechanism for this in the browsers, but this still seems to be the 
> best tradeoff we have right now. 
>
> -Paul 
>
>
> On Tue, Feb 3, 2015 at 9:43 PM, Jon Dufresne  > wrote: 
> > On Tue, Feb 3, 2015 at 11:52 AM, Aymeric Augustin 
> > > wrote: 
> >> You can fix that problem by saving some authentication info in the 
> user's session, most likely with a custom auth backend — see django-sesame 
> for an example of how to do this. Then redirect immediately to an URL that 
> doesn't contain the nonce. Of course all this must happen over HTTPS to 
> reduce the likelihood of leaving the nonce in the logs of various caches or 
> reverse proxies. 
> > 
> > My application is 100% over HTTPS, HTTP traffic is not allowed. 
> > 
> > Thanks for these pointers. This may not work exactly for me, but it 
> > certainly is something interesting to think about. I'll look into it 
> > more. 
> > 
> > -- 
> > You received this message because you are subscribed to the Google 
> 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/CADhq2b6SXqY78qiNdB7BkAQUcBHzAFUON%3DY69mEddu6Q55SWdg%40mail.gmail.com.
>  
>
> > For more options, visit https://groups.google.com/d/optout. 
>

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

Re: resurrecting an old friend, whitespace in forms, #6362

[Collin Anderson]

Hi All,

I'd be ok with a well thought-out strip-by-default.

- I think most of my problems have been with trailing whitespace on 
CharFields.
- I once have seen a minor unintentional leading whitespace. I think I also 
may have once used a leading whitespace for sorting purposes, but I'd be ok 
with even having leading whitespace stripped by default.

I can't think of many cases where trailing whitespace has been an issue for 
TextFields. Has this been an issue for people? I could imagine some people 
would want a trailing newline on TextFields. However, peeking at what other 
frameworks do, I'd be ok with this by default too :)

Also, did we decide if the Model-field-layer or Form-field-layer would be 
better?

Collin

On Wednesday, February 4, 2015 at 5:51:30 PM UTC-5, Shai Berger wrote:
>
> On Wednesday 04 February 2015 11:00:50 Tom Christie wrote: 
> > > it will be backwards incompatible for every Django installation out 
> > 
> > there, but also because throwing away data that the user actually 
> entered 
> > should be an opt-in, not opt-out behavior. 
> > 
> > If adequately called out I think there'd be a valid case that the 
> current 
> > and future issues it'll be causing to applications right now would 
> outweigh 
> > the risk of compatibility breakages. I can see a couple of cases where I 
> > might not want stripped whitespace, but only in slightly contrived and 
> edge 
> > case situations. 
> > 
> > Validating and normalizing input at the field level in a way that 
> supports 
> > the common case by default seems like a good plan to me. I'm not sure I 
> see 
> > any great difference between a user entering "3.1" in an integer field 
> and 
> > having 3 returned is so very different from having "hello " return 
> "hello" 
> > on a char field. And we're not of course throwing anything away at the 
> > `request.POST` or `Form` layer - it's only once we're validating an 
> > individual field that the normalization is being applied. 
> > 
> > I don't have an great investment in this either way around, but I think 
> > it's a valid user-focused improvement worth considering *if* someone 
> > actually puts together a pull request for it. 
>
> I agree with this as well; I'd argue, though, that there is a difference 
> between leading and trailing whitespace. Leading whitespace is usually 
> visible 
> and, to my mind, much more likely to be intentional. 
>
> Shai. 
>

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

User.username max_length 254

[Collin Anderson]

Hi All,

I was reminded by:
Allow shadowing of abstract fields 
https://groups.google.com/d/msg/django-developers/6zUfnElOIks/8uwXji559EsJ
and https://code.djangoproject.com/ticket/24288 (Custom User Models for 
small tweaks).

Could we reopen https://code.djangoproject.com/ticket/20846 and increase 
User.username max_length to 254?

Personally, that's the only thing I've ever needed to change about my User 
class. I just need it long enough to hold email addresses. I've seen many 
other people wanting the same thing.

In 1.8 we migrated the length of EmailField from 75 to 254, so it should be 
almost™ as easy to change the username field.

If needed, we could keep the 30-character limit on UserCreationForm and 
UserChangeForm for backwards compatibility. The limit in the database is 
the real killer :) Though, consistency is also nice.

Thanks,
Collin

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to 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/3cbf2307-dc8c-475b-909b-360fb2597a50%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Bytecode in Migrations

[Collin Anderson]

Hah. Check out this ticket :) https://code.djangoproject.com/ticket/23406

On Wed, Feb 11, 2015 at 4:04 PM, abhillman  wrote:

> I have gotten bitten by lingering bytecode in migrations on several
> occasions. Steps to reproduce are a little bit complex, but here is an
> rough example:
>
> Local Box:
> — have *.pyc rule in .gitignore
> — create some migrations
> — commit them
>
> Server Box:
> — pull repository
> — execute migrations
>
> Local Box:
> — remove migrations
> — commit
> — create new initial migration
>
> Server Box:
> — pull repository
> — remove migrations history from db
> — run fake initial migration — get an error here
>
> At this point, the server box has a migrations directory that looks
> something like this (bytecode is still around because it was in the
> gitignore):
> — migrations
> — __init__.py
> — 0001_initial.py
> — 0001_initial.pyc
> — 0002_second.pyc
> — 0003_third.pyc
>
> When running "python manage migrate" the bytecode appears to be
> referenced, which often causes errors when running the migrations. When
> using git, for example "git clean -df" clears out the problem. What I am
> wondering is if it might make sense to make a deliberate attempt to ignore
> bytecode without accompanying *.py files. This appears to be an issue
> because of the way that migrations dynamically import python code, but I am
> not sure. Perhaps the problem is more subtle as I am not deeply familiar
> with the way that migrations work.
>
> aryeh
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django developers (Contributions to 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/1dbf1434-b24a-47c9-b45b-ae04530d7867%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/CAFO84S6pvZBD4LnzsGr_LDx%3Di%3D%3DcXY7yi1Z2kvHPRZLmq1RPQw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Relations to non-trivial fields

[Collin Anderson]

Long term, eventually we want the FK to use a real models.UUIDField under
the hood, right?

On Sat, Feb 14, 2015 at 1:17 PM, Shai Berger  wrote:

> Hi all,
>
> This comes from trying to fix #24343[1] -- a problem where a UUIDField is
> used
> as a PK (legitimate and common practice), and we wish to test a FK to that
> model. The problem is that, on database backends which do not support
> native
> UUIDFields (that is, all but postgres), the underlying field for an FK is a
> CharField, not a UUIDField. This is not a problem in most normal use, but
> sometimes people do access the underlying field, and they're in for a
> surprise
> there.
>
> I am almost certain that a similar problem exists with any non-trivial
> field --
> e.g. if someone had reason to use a CommaSeparatedIntField as a PK, they
> would
> probably run into the same issue.
>
> Now, there are two essential ways to fix the test failure in the ticket:
> One,
> as suggested by Tim in a comment on the ticket, is to just deal with the
> difference in the test. The other is to solve the deeper issue, which
> could be
> seen as a little disruptive at this point in the release cycle (and is, in
> general, more disruptive).
>
> Note that, as Tim notes on the ticket, the test failure is Oracle only, but
> the real issue is everyone-but-postgres.
>
> Opinions?
>
> Thanks,
> Shai.
>
> [1] https://code.djangoproject.com/ticket/24343
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to 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/CAFO84S4CF_qo%2BMmJ1ybUsOMfD%3DPTyVxQZy8wD3vYKC6rE5%3DDwQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Psycopg2 version support

[Collin Anderson]

Right, I think the situation would be if you don't have admin/sudo and the
-dev / -devel header files are not present.

Seems to me 2.4.5 would be a safe minimum today, but supporting it until
2018 seems a bit excessive.

On Sun, Feb 15, 2015 at 7:18 PM, Christophe Pettus  wrote:

>
> On Feb 15, 2015, at 4:14 PM, Tim Graham  wrote:
>
> > Is there a scenario where you could pip install Django but not pip
> install psycopg2?
>
> Installing psycopg2 does require development tools, while Django does
> not.  I'm not offering this as a compelling argument for anything, just an
> observation.
>
> --
> -- Christophe Pettus
>x...@thebuild.com

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

Re: Drop the TEMPLATE_DEBUG setting

[Collin Anderson]

Hi,

Is there a reason to not always store the debug information? Performance?
Why have two behaviors?

Thanks,
Collin


On Sun, Feb 15, 2015 at 9:15 AM, Aymeric Augustin <
aymeric.augus...@polytechnique.org> wrote:

> Hello,
>
> During the multiple template engines refactor, I didn’t touch
> TEMPLATE_DEBUG.
> The only purpose of this setting is to control whether Django stores the
> information required to display stack traces for exceptions that occur
> while
> rendering Django templatse. I think I should have deprecated it for the
> following reasons.
>
> 1) Having the debug option of Django template engines default to DEBUG
> instead
> of TEMPLATE_DEBUG will allow everyone to remove TEMPLATE_DEBUG = DEBUG from
> their settings.
>
> 2) For the uncommon situation where one needs TEMPLATE_DEBUG != DEBUG, the
> new
> TEMPLATES settings provides a solution:
>
> TEMPLATES = [
> {
> 'BACKEND': 'django.template.backends.django.DjangoTemplates',
> 'OPTIONS': {
> 'debug': True,
> },
> },
> ]
>
> There should be only one way to do it and TEMPLATES beats TEMPLATE_DEBUG.
>
> 3) That will save developers of third-party backends from thinking about
> the
> semantics of TEMPLATE_DEBUG vs. DEBUG. At best it's a pointless exercise
> and
> at worst it will introduce inconsistencies. For example the maintainer of
> django-jinja is about to diverge from Django in this regard:
> https://github.com/niwibe/django-jinja/issues/87
>
> I would like to update the DEP and make this change in Django 1.8 beta.
>
> What do you think?
>
> --
> 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/45CFE41A-16D5-4A6B-AF27-505C3E4BEA75%40polytechnique.org
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>

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

Re: Psycopg2 version support

[Collin Anderson]

On Mon, Feb 16, 2015 at 1:41 PM, Thomas Stephenson 
wrote:

> And now I'll shut up, because I'm not entitled to an opinion here yet :D
>

By the way, Thomas, your opinion is welcome. :)

Collin

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to 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/CAFO84S5Fo27wJr_O%3DcFEi4oR7YT0en7eSxBoJac_dmkNRs7iaw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: User.username max_length 254

[Collin Anderson]

Hi,

I'm actually about to run into a similar situation myself where I already 
have migrations for my project but need to start using a custom user model 
(because I need a longer username :).

There's talk of possibly including a custom user in the project template 
https://code.djangoproject.com/ticket/24370. However, I think we need to at 
least document how to hack your project so you can switch to a custom user 
after using migrations.

Collin

On Wednesday, February 25, 2015 at 11:19:46 AM UTC-5, Daniel Hawkins wrote:
>
> Beta 1 marks the end of any changes that aren't considered release 
>> blocking bugs. A bug is a "Release blocker" if it's a regression from a 
>> previous version of Django or if it's an important bug in a new feature.
>
>
> ... so I guess the ship has sailed on this idea?  :(
>
> On Wednesday, February 11, 2015 at 3:27:35 AM UTC-5, Daniel Hawkins wrote:
>>
>> Yes please!  Since contrib.auth.models.User.email is an EmailField, that 
>> change will require everyone to run a migration, right?  Then we might as 
>> well change the character limit on the username field at the same time, 
>> no?  And any other defaults that might be less-than-reasonable?
>>
>> I was going to update the longerusername package by adding a Django 1.7 
>> migration, but it seems I can't alter fields on the User model from 
>> within another app's migrations in Django 1.7.  This was possible with 
>> South, but it appears to be impossible with Django migrations (except 
>> perhaps with raw SQL, which seems like a bad idea).  So now I *have to* 
>> create a custom user model just so I can migrate to Django 1.7 (which I 
>> *have 
>> to* do in order to continue getting security releases after 1.8 is 
>> released).
>>
>> According to the docs, setting a custom user model after you've already 
>> run initial migrations is not supported (
>> https://docs.djangoproject.com/en/1.7/topics/auth/customizing/#substituting-a-custom-user-model).
>>  
>>  So, for anyone without a custom user model, who is already running on 
>> Django 1.7 in production, who would like to have usernames longer than 30 
>> characters, there is no way to make that happen.
>>
>>
>> On Friday, February 6, 2015 at 8:10:02 PM UTC-5, Collin Anderson wrote:
>>>
>>> Hi All,
>>>
>>> I was reminded by:
>>> Allow shadowing of abstract fields 
>>> https://groups.google.com/d/msg/django-developers/6zUfnElOIks/8uwXji559EsJ
>>> and https://code.djangoproject.com/ticket/24288 (Custom User Models for 
>>> small tweaks).
>>>
>>> Could we reopen https://code.djangoproject.com/ticket/20846 
>>> <https://www.google.com/url?q=https%3A%2F%2Fcode.djangoproject.com%2Fticket%2F20846&sa=D&sntz=1&usg=AFQjCNFmuXGuuIzUh9RG7XCoJFVq-z7m2g>
>>>  
>>> and increase User.username max_length to 254?
>>>
>>> Personally, that's the only thing I've ever needed to change about my 
>>> User class. I just need it long enough to hold email addresses. I've seen 
>>> many other people wanting the same thing.
>>>
>>> In 1.8 we migrated the length of EmailField from 75 to 254, so it should 
>>> be almost™ as easy to change the username field.
>>>
>>> If needed, we could keep the 30-character limit on UserCreationForm and 
>>> UserChangeForm for backwards compatibility. The limit in the database is 
>>> the real killer :) Though, consistency is also nice.
>>>
>>> Thanks,
>>> Collin
>>>
>>>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to 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/9663cfe8-933f-4720-b24d-0cd6aec7fb3b%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Django Admin new look

[Collin Anderson]

Re theming layer: In theory (if you use collectstatic :) it should be 
possible to include an "app" that overrides the css files. I believe it the 
custom app would need to be placed above django.contrib.admin in 
INSTALLED_APPS. Or you can even override the files by putting them in a 
STATICFILES_DIRS. 

On Wednesday, March 4, 2015 at 6:38:08 PM UTC-5, Curtis Maloney wrote:
>
> Looks pretty slick, but brings with it all the hassles of the past 
> attempts to re-skin admin: it breaks legacy custom pages.
>
> I wish we could standardise a theming layer for admin... allow legacy 
> templates, or switching to new, clean, themable templates...
>
> Perhaps this could be integrated with the work to break down admin into a 
> collection of CBGV?
>
> ... mostly thinking out aloud here :)
>
> --
> Curtis
>
> On 3 March 2015 at 18:57, elky > wrote:
>
>> Hi guys,
>>
>> I just made big front-end work on Django admin to make it look like new 
>> Django site - modern and clean.
>>
>> I think it's user friendly now and not so scary for users. Need your 
>> opinion, guys.
>>
>> See screenshots attached.
>>
>> Just thinking what to do next - publish my own app or make pull request.
>>
>> Thanks,
>> Alex
>>
>> -- 
>> You received this message because you are subscribed to the Google 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/d3419ee7-2118-41ff-863e-55f4c05c43d1%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/808c4f2a-298a-44b1-ab00-e765b3e404f3%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Suggestion: add default "registration/login.html" to django.contrib.auth

[Collin Anderson]

Could be as simple as: {% csrf_token %}{{ form }}

On Tuesday, March 3, 2015 at 9:32:48 AM UTC-5, Ilya Kazakevich wrote:
>
> I agree: adding template from example is good idea! And I believe it will 
> be used at least by newbies who just study Django auth system and by people 
> who just need prototype. Providing default is better than copy/pasting 
> example from docs.
>
> On Tuesday, March 3, 2015 at 5:26:10 PM UTC+3, Marc Tamlyn wrote:
>>
>> I can see the merit of including our documented example as an actual 
>> template as a starting point. It's unlikely to be used exactly as is very 
>> often but it reduces getting started friction for some users - "huh this 
>> view doesn't work, better go read the docs"
>>
>> I'd perhaps be inclined to include it without styles even.
>>
>> Marc
>>
>> On 3 March 2015 at 14:22, Ilya Kazakevich  wrote:
>>
>>> I do not think admin templates should used. But something very simple 
>>> and dumb (that looks similar to browser HTTP auth window). Here is example: 
>>> http://pastebin.com/nnX36RB6
>>> Css should be moved to static files, of course, to make this template 
>>> cleaner and slightly more customizable. 
>>>
>>> Imagine I need to create working solution as fast as I can. I really do 
>>> not care about good UI now, because I need only a prototype to show it to 
>>> my customer. I will not spent time creating nice login page: I just simply 
>>> copy/paste template from Django documentation. And login page from contrib 
>>> is great aid here. I will probably change login page UI later, but it is 
>>> minor issue and priority is low. Many people in Intranet solutions 
>>> (portals, CRMs and so on) are happy with browser HTTP auth window. They 
>>> really do not care about how ugly is it.
>>>
>>>
>>>
>>>
>>> On Tuesday, March 3, 2015 at 4:36:52 PM UTC+3, Tim Graham wrote:

 The admin templates extend "admin/base_site.html" and rely on the 
 presence of specific template blocks so I don't think it's appropriate for 
 those dependencies to be added to contrib.auth. I'm curious to see what 
 content you would propose for a default template. Typically I've seen 
 login 
 templates that extend from a project's base template so it inherits all 
 the 
 project specific styles, JavaScript, etc. I'm not sure a default template 
 would actually be used much in practice.

 On Tuesday, March 3, 2015 at 8:18:39 AM UTC-5, Tino de Bruijn wrote:
>
> Yeah, or default to admin/login.html. The admin ships with all 
> necessary "registration" templates, but for some reason only the 
> login.html 
> is included in the admin directory.
>
> On Tue, Mar 3, 2015 at 2:05 PM, Ilya Kazakevich  
> wrote:
>
>> Hello,
>>
>> When I use Django auth, I need to provide login.html myself. But 
>> Django encourages applications to have default templates which can be 
>> overwritten by user (via filesystem.Loader, for example). 
>> I suggest to provide default login.html with simple HTML form. User 
>> may always overwrite it.
>>
>> -- 
>> You received this message because you are subscribed to the Google 
>> Groups "Django developers (Contributions to Django itself)" group.
>> To unsubscribe from this group and stop receiving emails from it, 
>> send an email to django-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/9487d6c7-8ee2-4a64-aae6-
>> 9a05574c1464%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-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/aae4454c-7823-41cc-aaf2-914eb7b7c95f%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

Re: Changes to django.db.models.fields.Field API

[Collin Anderson]

Hi,

If it's not too much work, creating pull requests could help give some 
context and show a bit more of the impact of your proposed changes. Some 
days I think I'm better at reading Python than English :)

value_from_object maybe should be value_from_instance or 
get_instance_value, as in, pick this field's value off of the model 
instance. "Field.get_field_value" sounds redundant.

Re: value_from_object and save_form_data: looking at some code I wrote 5 
years ago that has mostly been untouched, renaming these would break my 
code, but they are undocumented after all. I agree that the two go hand in 
hand. I'd almost rather rename value_from_object to get_form_data, just so 
it's clear what's going on. :)
While we're on the subject: it would be great if formfields also had a way 
to override this getting and setting :) ("No, I want the _object_ not the 
integer from the FK" :)

Re: _get_cache_name(), using "name" makes more sense to me than "attname", 
but I'm curious more about this "field.name not necessarily unique" change 
:).

Thanks,
Collin

On Monday, March 2, 2015 at 12:37:37 AM UTC-5, Thomas Stephenson wrote:
>
> I was wondering whether there would be support for changes to some of the 
> methods on the field API...
>
> 1. Rename `Field._get_val_from_obj` and `Field.value_from_object` methods
>
> These two methods do exactly the same thing (except one returns a default 
> value if available). In addition, the 'value_from_object' is confusingly 
> named, as it performs a completely different function than 
> `value_to_string` and `to_python`, but is named similarly.
>
> Both of these methods should be deprecated and a new method 
> `Field.get_field_value(model_instance, use_default=True)` should be added. 
> If `use_default` is provided and `True`, then the implementation should 
> redirect to `field.get_default()`, otherwise an AttributeError would be 
> raised.
>
> 2. Rename `Field.save_form_data`
>
> `Field.save_form_data()` should be renamed to `Field.get_field_value()` 
> for symmetry with `Field.get_field_value()`.
>  
> 3. `Field._get_cache_name()` and should use field.attname.
>
> I'm planning to submit a PR in the next couple of days that makes `
> field.name` not necessarily unique. All non-hidden fields will still be 
> unique, so it won't cause a problem with the `model._meta.get_field()` API, 
> but it will cause problems if fields can overwrite each others cached 
> values. This should not be a breaking change, since _get_cache_name is an 
> implementation detail.
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to 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/6d6bad97-647c-4a8c-ba83-b567b9094d82%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: User.username max_length 254

[Collin Anderson]

Hi All,

I made a pull request. https://github.com/django/django/pull/4250/files

I wish I would have thought of this two months ago, but I think it's too 
big of a change to get into 1.8 this late. I personally don't want to 
potentially have the release delayed because of possible issues with this 
change.

Collin

On Friday, March 6, 2015 at 10:01:28 AM UTC-5, Chris Foresman wrote:
>
> Yeah, this is the point I was trying to make. I absolutely get your point 
> about the impact to user, though, Josh. It just seems worth doing since 
> this is an LTS release.
>
> On Friday, February 27, 2015 at 5:41:12 PM UTC-6, Daniel Hawkins wrote:
>>
>> I'd bet an extremely large portion of those users don't absolutely have 
>>> to have an increased username field. They've gone this long without it.
>>>
>> They (we) have gone this long, not because we didn't need it, but because 
>> we didn't think of it in the very beginning, and after that it was too 
>> late.  The portion of users this would affect is exactly the same as the 
>> set that is affected by the change in max_length on the User.email field, 
>> which is already part of 1.8.  Given that fact, I don't see this as a very 
>> big violation of the alpha/beta testing process.
>>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to 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/42dd32f4-c06c-42e4-86f5-ab024b6ae0a7%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Password validation in Django revisited

[Collin Anderson]

Hi Erik,

This nice, though I'd like it even more if it didn't introduce another 
setting. :) Having it on the backend would solve that problem for me I 
think.

Also, this may be obvious, but more specific error messages would be nice, 
like "password is too simliar to username".

Collin

On Monday, March 9, 2015 at 5:43:36 PM UTC-4, Aymeric Augustin wrote:
>
> Hi Erik, 
>
> Great work! 
>
> Did you consider tying validators to authentication backends? I admit it 
> sounds like a bad idea and most likely it is, but since different backends 
> may have different security requirements, I'd like to make sure we aren't 
> missing something. 
>
> Assuming help_text is HTML, you may improve it by building it as follows: 
>
> Your password must match the following requirements: 
>  
> validator 1's requirements 
> ... 
>  
>
> This version looks slightly worse when there's only one validator. However 
> I expect most sites will use at least two or three validators: minimum 
> length, character classes (lower/upper/figures), not a common password (we 
> should ship a static blacklist of the top 100 most common passwords, 
> there's tons of research on this). 
>
> In order to prevent reuse of old passwords, you need to add another method 
> to the validator class that is called after the password is successfully 
> changed. Otherwise, if the user submits a password change form and the new 
> password goes through the validators successfully but the submission fails 
> for some other reason (e.g. the current password is wrong), then the user 
> can't re-submit the same new password, even though they never used it. 
>
> -- 
> Aymeric. 
>
> > Le 8 mars 2015 à 15:47, Erik Romijn > 
> a écrit : 
> > 
> > Hello all, 
> > 
> > I've taken another stab at 16860[1]: having a password validation/policy 
> in Django. I've made an initial simple PR[2] to show the approach I'd like 
> to use - no tests or documentation yet, the example validators are not very 
> nice, possibly bad naming, etc. But this should be sufficient to show how I 
> would like to tackle this. There's quite a few decisions to take, 
> influencing the later possibilities, which I'll try to outline below. 
> > 
> > Users choosing awful passwords is a serious security issue. Although 
> password validation can only go so far - especially to the extent that we 
> can implement in Django itself - to me it seems part of our responsibility 
> in helping Django developers to build safer websites. 
> > 
> > First, let me briefly describe my approach: we add a new setting to 
> define zero or more password validator classes. Optionally, a class can be 
> provided with custom arguments to it's constructor. Each validator class 
> has a help_text() method and a validate(password, user) method. The former 
> produces a translatable sentence to be included in the form field's help 
> text. The validate method validates a certain password, optionally taking 
> the context of a user into account and passes its judgement on the 
> password. If a validator considers a password insufficient, it raises a 
> ValidationError. 
> > 
> > This is tied to the validation and form field setup in SetPasswordForm 
> and AdminPasswordChangeForm. An obvious choice seems to be to tie this to 
> User.set_password(). However, I intentionally did not include that step, as 
> I feel this validation should primarily take place on the user frontend 
> site with forms. This mirrors the way we typically handle this in Django. 
> Should someone feel different, and want to tie this to set_password() as 
> well, this is possible with a custom user object. Tying this validation 
> into any other place is also trivial: just adding a single line. 
> > 
> > I decided not to go for standard Django validators, as I felt this would 
> offer insufficient flexibility and configurability - as was already raised 
> in previous discussions on this issue. 
> > 
> > In the ticket, Shai described a few particular goals for this feature: 
> > 
> > - Informing the user of the various password requirements: this is 
> possible by each validator providing a description, which can be dependent 
> on it's configuration, of it's requirements. Independent sentences from 
> different validators are now concatenated, an approach which will not 
> always yield the prettiest language. 
> > - Allowing policies to chain together smoothly: multiple validators can 
> be run sequentially, stopping after the first failure. 
> > - Provide flexibility for complex requirements (some may include their 
> own models): this is entirely possible within the design. 
> > - Backwards compatibility: the default setting is to have no validators, 
> which means no change and no modifications in help text. I do suggest we 
> include some reasonable defaults in the standard project template. 
> > - Javascript validation assistance or HTML5 support: not implemented 
> currently, but this could be added in a similar way as help texts. 
> >

Re: Django Admin New Look

[Collin Anderson]

That looks beautiful! I can see all of the improvement from last time too!

I'd personally prefer slightly less vertical padding, but otherwise I think 
it's awesome!

Thanks!
Collin

On Wednesday, March 11, 2015 at 4:20:31 PM UTC-4, elky wrote:
>
> Hi everyone,
>
> I reworked my previous attempt 
>  of stylizing django admin 
> and now it looks more like original in terms of color scheme. See 
> attachments.
>
> For those who want to play with new theme I created an app which is *very* 
> simple to install, see here: https://github.com/elky/django-flat-theme. 
> Feel free to criticize - I'll appreciate any feedback. 
>
> Thank you
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To 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/39a95762-a0c0-443e-af86-0cac2bcf446c%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

inspectdb database defaults

[Collin Anderson]

Hi All,

We recently added database introspection of defaults for purposes of 
testing migrations.

https://github.com/django/django/commit/75303b01a9cc900eebf1f27ba0bc6508334242fc

I would find it useful to have inspectdb attempt to use those defaults when 
generating models. (My use case is running inspectdb on a WordPress 
database which has a bunch of database defaults.)

Rough proof of concept: https://github.com/django/django/pull/4030

Though Tim says: "Translating database level defaults into model field 
defaults isn't functionally equivalent and given that Django doesn't 
translate the model field default option into a database level default, I 
think it would be inconsistent to do a conversion in the other direction."

Collin

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to 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/11972cea-2565-4940-abe6-8cdec8f40a1e%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: GSOC-2015, Newbie, Want to contribute to Django development and also try my hand in GSOC

[Collin Anderson]

Hi,

Welcome!

If you haven't yet, check out the contributing docs. 
https://docs.djangoproject.com/en/dev/internals/contributing/

I also recommend hanging around the #django-dev irc channel.

Collin

On Thursday, March 12, 2015 at 7:23:42 AM UTC-4, Saurabh Jain wrote:
>
> Hello,
>  My name is Saurabh Jain, currently pursuing bachelors degree in 
> Computer Science. I want to contribute to the development of Django. I have 
> worked upon Django as user but have no experience related to its 
> development. Can anyone please help me to get started with it ? I know that 
> its too late to start now for GSOC 2015, but still I would like to 
> contribute to the organisation no matter whether I get selected or not.
>
> Thanks   
>

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

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

[Collin Anderson]

Hi All,

I am free of 2.6 websites myself (and nearly free of 2.x completely), but I 
think this makes sense and I'm certainly in favor of community-maintained 
longer support periods of django versions, assuming people want to do it :)

Two thoughts:

- This doesn't _need_ to happen through Django officially, but doing it 
this way has the advantage of receiving pre-notify and the having some of 
Django's blessing gives more confidence to anyone using it.

- I'm not saying anyone wants this, but I could also see the possibility of 
volunteers wanting to continue 1.4's support on 2.6 and 2.7 only (dropping 
2.5 support).

If it helps, I have the historical Python support in table form:
https://gist.github.com/collinanderson/3597ec51a7d2f1092eb5

Collin

On Thursday, March 19, 2015 at 6:59:59 PM UTC-4, James Bennett wrote:
>
> There's been some recent discussion in a django-users thread[1] about
> the impending end-of-life of Django 1.6, which in turn will mean
> end-of-life for Django supported on Python 2.6. In addition, the
> end-of-life of the current LTS release, Django 1.4, will mean
> end-of-life for Django supported on Python 2.5. The following is a
> draft of a proposal based on ideas raised in that thread; it should be
> considered pre-DEP status, to be elevated to a DEP submission if there
> is sufficient support.
>
>
> Abstract
> 
>
> The support process for older versions of Django is changed, as
> follows:
>
> * Official support for older versions of Django from the Django core
>   team will continue to end at the scheduled times (i.e., upon release
>   of a new minor version for non-LTS releases, at end of advertised
>   support lifetime for LTS releases).
>
> * Unofficial support, by persons willing to volunteer their time, will
>   be permitted through a secondary code repository existing solely to
>   provide this support.
>
> * As the official end-of-life of each Django version approaches, the
>   Django core team will solicit proposals and volunteers to provide
>   unofficial support for that version past its official end-of-life,
>   and select maintainer(s) from amongst those volunteers. This support
>   will be known as "community maintenance".
>
>
> Rationale
> -
>
> For the past five years, Django has been in the process of deprecating
> support for older 2.x release of Python, as part of a plan to move
> Django toward, first, compatibility with both Python 2 and Python 3
> (completed as of Django 1.6), and ultimately with only Python 3 (in a
> future, to-be-determined, release).
>
> The timeline for this was as follows:
>
> * May 2010: Django 1.2 instituted a minimum Python version of 2.4.
>
> * March 2011: Django 1.3 was the final release to support Python 2.4.
>
> * March 2012: Django 1.4 (LTS) raised the minimum Python version to
>   2.5, and was the final release to support Python 2.5.
>
> * February 2013: Django 1.5 raised the minimum Python version to 2.6.
>
> * November 2013: Django 1.6 was the final release to support Python
>   2.6.
>
> * September 2014: Django 1.7 raised the minimum Python version to 2.7.
>
> * Late Q1/early Q2 2015: Django 1.4 and Django 1.6 will reach
>   end-of-life (the former on a scheduled date, the latter upon the
>   release of Django 1.8).
>
> While this process was necessary to achieve at least a minimum of
> Python 2.6 (the lowest version enabling compatibility with Python 2
> and Python 3 in a single codebase) and ultimately a minimum of Python
> 2.7 (the only Python 2.x release still receiving upstream security
> support), and while moving Django in the direction of Python 3 is an
> absolute necessity for the future of the framework, this has had an
> effect on some users of Django who are effectively locked in to now-
> or soon-to-be-unsupported versions of Python by their choice of
> operating system and associated support contract.
>
> In particular, the impending end-of-life of Django 1.6, the final
> release which supported Python 2.6, is poised to cut off support for
> users of products like Red Hat Enterprise Linux, who may be locked to
> Python 2.6 and thus unable to use a supported version of Django past
> 1.6 end-of-life (these users continue to receive security support for
> Python itself from the operating-system vendor, who provides such
> support on their behalf even after official upstream support has
> ended; no such support appears to be provided, at this time, for
> Django).
>
> Although these users are not a majority of Django's users, they are
> still a significant group, and simply ending their ability to use
> Django is likely to be an unacceptable option. But the Django core
> team cannot and will not extend the official support lifetimes of
> older Django releases; the additional maintenance burden is beyond
> that which can be borne, and would impede the future development of
> Django.
>
> This is not the first time in Django's history that a significant
> minority of users have been affected by backwa

Re: improving debug logging in development

[Collin Anderson]

Hi All,

A little off topic, but here's what I do to generate "yellow" html 
tracebacks in production behind the scenes:

from django.views import debug
html = debug.ExceptionReporter(request, is_email=False, *sys.exc_info()).
get_traceback_html()

Though, I do that within the got_request_exception signal; not sure if it 
would work in the logging framework.

Collin

On Thursday, March 26, 2015 at 5:58:43 AM UTC-4, HM wrote:
>
> What about the yellow 500 error-page when in debug-mode? I'd like to have 
> a copy of the complete thing *somewhere* now that what's sent by email is 
> sanitized. Cloning a running system, turning DEBUG on and attempting to 
> trigger the same error isn't always easy. Is the 500-data loggable at all?
>
> On 24 March 2015 at 03:18, Aron Griffis  > wrote:
>
>> On Mon, 2015-03-23 at 19:16 -0600, Carl Meyer wrote:
>> > And it still seems to me that it's bad for Django's default config to
>> > set `level: ERROR` and `propagate: False` on the django.request and
>> > django.security loggers, as that prevents those logs from propagating to
>> > higher-level handlers someone may want to install.
>>
>> My fix for this has been the following snippet in settings.py:
>>
>> # The DEFAULT_LOGGING dict is unhelpful and resides even with
>> # disable_existing_loggers=True. This prevents propagation to the root
>> # logger for loggers defined in DEFAULT_LOGGING.
>> from django.utils.log import DEFAULT_LOGGING
>> DEFAULT_LOGGING['loggers'] = {}
>>
>> -Aron
>>
>> --
>> You received this message because you are subscribed to the Google 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/1427163497.27346.3.camel%40arongriffis.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/9d3d774b-edf3-4716-a79c-072b2313fff8%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: django-admin.py shebang

[Collin Anderson]

Hi Stan,

In the source, it's looks like it's been using #!/usr/bin/env python for 
almost 10 years:
https://github.com/django/django/blame/master/django/bin/django-admin.py

My quick guess is that gets modified when installing. Did you use the newer 
version of python to install django?

Collin

On Wednesday, April 1, 2015 at 7:46:34 AM UTC-4, Stan wrote:
>
> Hi devs,
>
> Is there a good reason for having the shebang line in django-admin.py at 
> #!/usr/bin/python
> "instead" of #!/usr/bin/env python ?
>
> My problem is I have a newer version of Python installed in 
> */usr/local/opt/* declared in my PATH 
> that I want to test but the hardcoded path to /usr/bin/python ignore the 
> PATH value.
>
> I know that virtualenv is the way to go...
>
> Thanks !
>
> --
> Stan
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to 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/0d9b4be9-acf6-4258-a6bd-3aa8e89a0836%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: django-admin.py shebang

[Collin Anderson]

Hi Stan,

If possible, I'd recommend (somehow) getting a pip built against your 
/usr/local/bin/python, then "/usr/local/bin/pip install django" should do 
what you want.

Collin

On Wednesday, April 1, 2015 at 11:28:33 AM UTC-4, Stan wrote:
>
>
>
> On Wednesday, April 1, 2015 at 4:15:25 PM UTC+2, Markus Holtermann wrote:
>>
>> Hi Stan, 
>>
>> how did you install Django? As a system package via the system's package 
>> manager or via pip. If its the system package manager, please raise that 
>> bug in the bug tracker of your Linux distribution. If the answer is "via 
>> pip", from where? PyPI or something obscure? 
>>
>
> A classical pip install Django command without --mirrors or --use-mirrors 
> modifier.
>
> I did some --upgrade, but the first installation is not 10 years old (2 
> maybe).
>
>  
> Pip is a Debian package (1.1.3)
>
> [$ whereis django-admin
> django-admin: /usr/local/bin/django-admin.py /usr/local/bin/django-admin
> $ cat /usr/local/bin/django-admin
> #!/usr/bin/python
> # EASY-INSTALL-ENTRY-SCRIPT: 
> 'Django==1.7.4','console_scripts','django-admin'
> __requires__ = 'Django==1.7.4'
> import sys
> from pkg_resources import load_entry_point
>
> if __name__ == '__main__':
> sys.exit(
> load_entry_point('Django==1.7.4', 'console_scripts', 
> 'django-admin')()
> )
> $ cat /usr/local/bin/django-admin.py 
> #!/usr/bin/python
> from django.core import management
>
> if __name__ == "__main__":
> management.execute_from_command_line()
>
>
>
>
>> As Collin already wrote, Django uses "/usr/bin/env python" for years. 
>>
>> /Markus 
>>
>>
>> On April 1, 2015 3:58:13 PM GMT+02:00, Collin Anderson <
>> cmawe...@gmail.com> wrote: 
>> >Hi Stan, 
>> > 
>> >In the source, it's looks like it's been using #!/usr/bin/env python 
>> >for 
>> >almost 10 years: 
>> >https://github.com/django/django/blame/master/django/bin/django-admin.py 
>> > 
>> >My quick guess is that gets modified when installing. Did you use the 
>> >newer 
>> >version of python to install django? 
>> > 
>> >Collin 
>> > 
>> >On Wednesday, April 1, 2015 at 7:46:34 AM UTC-4, Stan wrote: 
>> >> 
>> >> Hi devs, 
>> >> 
>> >> Is there a good reason for having the shebang line in django-admin.py 
>> >at 
>> >> #!/usr/bin/python 
>> >> "instead" of #!/usr/bin/env python ? 
>> >> 
>> >> My problem is I have a newer version of Python installed in 
>> >> */usr/local/opt/* declared in my PATH 
>> >> that I want to test but the hardcoded path to /usr/bin/python ignore 
>> >the 
>> >> PATH value. 
>> >> 
>> >> I know that virtualenv is the way to go... 
>> >> 
>> >> Thanks ! 
>> >> 
>> >> -- 
>> >> Stan 
>> >> 
>>
>>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to 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/170c7dfd-ecc3-4a6a-8c4f-9ceec79518c1%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Fate of sql* management commands

[Collin Anderson]

And the auto-generated in-memory migrations should work for tests too, 
right?

On Friday, April 3, 2015 at 2:34:23 PM UTC-4, Andrew Godwin wrote:
>
> >
>> > An alternative would be to ignore migrations files, regenerate a fresh
>> > set of migrations, and dump the corresponding SQL.
>>
>> I think this approach would be much preferable to using the totally
>> separate legacy code path. Presented as a tool for debugging migrations
>> issues, and with the appropriate documentation notes about RunSQL etc, I
>> think it would be a useful addition.
>>
>
> This is in fact what I was suggesting when I said "tie the autodetector 
> into the SQL writer directly in-memory". It would do 99% of what people 
> want, and more than the old one did.
>
> Andrew
>

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

Re: ModelManager behaviour for Proxy Models

[Collin Anderson]

Hi Mahmud,

I personally really like the technique of having a "type" column in the 
base model. It allows you to query across all types but still get the 
correct subclass.

However, I think the manager is a good place to handle this. You could have 
a manager that looks something like:

objects = SubClassManager(type_field='type')

And then, you would override the iterator() method to make it (find and) 
return the correct type.

But, it's probably not useful enough to warrant including in Django itself.

Collin

On Tuesday, March 31, 2015 at 9:53:01 AM UTC-4, mahmudul islam wrote:
>
> I am not sure about the current development branch but last time I 
> checked, performing query on proxy models by default considers all the 
> objects of the parent/base class. If anyone is to consider only the objects 
> of that class, he has to implement a custom modelmanager for that and use 
> it. In most of my projects I use proxy models and I always have to create 
> this ModelManager. 
>
> My suggestion is - Can we put a new config option 'disciminitator' 
> property in the class Meta of django.db.models.Model, so that whenever a 
> user creates a proxy model, he has to mention this property and this will 
> be the a column in that table and the class name will be saved in that 
> column automatically when saving or updating objects.  And when doing query 
> with proxy models, this columns will be automatically added in the filter 
> so that developers will not need to create a custom ModelManager for their 
> proxy model.
>
>
> Please waiting for others feedback.
>
> Best,
> Mahmud
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to 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/07383e36-48c4-4087-9232-802d62a5345e%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Django Admin New Look

[Collin Anderson]

There's a ticket about icons here: 
https://code.djangoproject.com/ticket/20597

On Tuesday, April 7, 2015 at 11:16:42 AM UTC-4, elky wrote:
>
> Hi everyone. As you can see there is less activity now in this thread. 
> With the latest 0.9.3 release I just think CSS work is over until anyone 
> report a bug or suggestion to improvement.
>
> There is big interest from the community:
> - 1736 downloads in the last month from PyPi 
> 
> - 334 unique visitors of the repo 
>  and 117 stars
>
> People actively use this theme so it's time to think what do to next.
>
> I would like to make Pull Request in Django 1.9 branch when it starts - 
> but I need feedback and suggestions before. Please share your thoughts, 
> guys.
>
> I manually found interesting discussion here 
> . Few 
> words on flat icons - I think it requires markup change but if people 
> really want to see flat icons I suggest to use one of the popular icon font 
> library (like I suggested in October 
> ).
>  
> Any thoughts?
>
> Thanks,
> Alex
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to 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/0e2a071a-6240-47e5-8d85-9dd11acbd087%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: 1.9 release planning

[Collin Anderson]

On Tuesday, April 7, 2015 at 2:31:08 PM UTC-4, Asif Saifuddin wrote:
>
> How about
>
> a 8 month release cycle and having a LTS in every two years and supporting 
> the old LTS atleast 3 years from the release date? there will be 3 version 
> between two LTS.
>

Interesting. I like the idea of having predictable release dates.

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to 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/33609d33-edc9-4ec1-a324-cdcad74a51f5%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: django site framework bug, site name swaps back and forth each request

[Collin Anderson]

Ahh, yes, that sounds like the warning box here:

https://docs.djangoproject.com/en/1.8/howto/deployment/wsgi/modwsgi/#basic-configuration

On Sunday, 19 April 2015 03:03:44 UTC-4, Florian Apolloner wrote:
>
>  Hi,
>
> this is certainly a bug in your code or deployment via mod_wsgi (eg the 
> two projects are in the same python process).
>
> Cheers,
> Florian
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to 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/a4ba07fb-e03c-4c38-9ecc-e9799dc5f679%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: CSRF_COOKIE_HTTPONLY is misleading and not useful

[Collin Anderson]

Though it could still ajax-in the token from a page that does have it, 
right?

On Sunday, April 19, 2015 at 3:42:14 AM UTC-4, Marc Tamlyn wrote:
>
> I'm not a security expert, but one thing I could suggest is that this 
> setting does mean that only javascript on a page with a POST form can 
> access the CSRF token. Depending on the nature of your site, this could be 
> a significant proportion of pages.
>
> On 17 April 2015 at 21:22, Gavin Wahl > 
> wrote:
>
>> Ticket #15808 added the CSRF_COOKIE_HTTPONLY setting to set the
>> HttpOnly attribute on the csrftoken cookie. The HttpOnly attribute is
>> intended to prevent accessing a cookie through the DOM interface, only
>> sending it over HTTP. This improves security for session cookies
>> because it prevents XSS attacks from accessing the session id.
>>
>> The CSRF token is used through the DOM though, by embedding it in the
>> HTML of a form, so it's always accesible through JavaScript anyway.
>> The docs even suggest how to negate the effect of the setting:
>>
>> > This can help prevent malicious JavaScript from bypassing CSRF 
>> protection. If you enable this and need to send the value of the CSRF token 
>> with Ajax requests, your JavaScript will need to pull the value from a 
>> hidden CSRF token form input on the page instead of from the cookie.
>>
>> The first sentence isn't actually true. HttpOnly can't prevent
>> JavaScript from obtaining the csrftoken, because the csrftoken has to
>> be in the DOM anyway. The second sentence suggests doing something
>> that completely negates the effect of the setting, so why use it at
>> all?
>>
>> I understand that this setting may exist only to satisfy misguided
>> security scanners and not to actually improve security. If that's the
>> case, the implication that this setting improves security should be
>> removed from the docs.
>>
>> --
>> You received this message because you are subscribed to the Google 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/CACPudh1Nn-Cz5hJivvTVcfD%3DSSB2E9ZC2s-2mnje88kARKjBfA%40mail.gmail.com
>> .
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>

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

Re: django site framework bug, site name swaps back and forth each request

[Collin Anderson]

Try it without setdefault or use daemon mode :)

The "standard" configuration has this exact problem, which there's a
warning in the docs and why daemon mode is recommended.

On Sunday, April 19, 2015, Joe  wrote:

> @Florian What do you mean the projects are in the same python process?
>
> This is a standard implementation of the sites framework above, which
> leads me to believe there is a bug in django 1.7
>
> On Sunday, April 19, 2015 at 12:03:44 AM UTC-7, Florian Apolloner wrote:
>>
>>  Hi,
>>
>> this is certainly a bug in your code or deployment via mod_wsgi (eg the
>> two projects are in the same python process).
>>
>> Cheers,
>> Florian
>>
>  --
> You received this message because you are subscribed to the Google Groups
> "Django developers (Contributions to 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/dd19d815-224e-4102-9656-e3f493878e2c%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/CAFO84S6D3bCLmwQVe-zcBkONEL7fFYVpxK6EV0Vx7VDaiNJ1Rg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: django site framework bug, site name swaps back and forth each request

[Collin Anderson]

(Multiple config files doesn't mean multiple processes. Daemon mode is the
only way to get a separate process per site.)

On Sunday, April 19, 2015, Joe  wrote:

> @Florian What do you mean the projects are in the same python process?
>
> This is a standard implementation of the sites framework above, which
> leads me to believe there is a bug in django 1.7
>
> On Sunday, April 19, 2015 at 12:03:44 AM UTC-7, Florian Apolloner wrote:
>>
>>  Hi,
>>
>> this is certainly a bug in your code or deployment via mod_wsgi (eg the
>> two projects are in the same python process).
>>
>> Cheers,
>> Florian
>>
>  --
> You received this message because you are subscribed to the Google Groups
> "Django developers (Contributions to 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/dd19d815-224e-4102-9656-e3f493878e2c%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/CAFO84S6oxZhbT%2BUEJvTAOFK8WDjyzxd-to4vDGdh6V44JEGg1Q%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: User.username max_length 254

[Collin Anderson]

Hi All,

I'm pretty busy right now and don't currently have the time and motivation 
to finish this username max_length 254 change. If anyone wants to finish it 
up, the PR is nearly complete; it just needs better instructions on how to 
keep the limit at 30 characters for anyone who doesn't want the behavior to 
change.

https://github.com/django/django/pull/4250/files

My excuse :)
There's been some re-organization at work over the last month and I'm now 
basically running a one-man web development business, so it's been pretty 
busy. :) I'm also no longer responsible for the project that needed this 
change the most, hence the loss of motivation on this one. :)

Thanks,
Collin

On Friday, March 6, 2015 at 7:05:28 PM UTC-5, Collin Anderson wrote:
>
> Hi All,
>
> I made a pull request. https://github.com/django/django/pull/4250/files 
> <https://www.google.com/url?q=https%3A%2F%2Fgithub.com%2Fdjango%2Fdjango%2Fpull%2F4250%2Ffiles&sa=D&sntz=1&usg=AFQjCNFzh84jYL-zW9p-upWtCXMSgGKaqA>
>
> I wish I would have thought of this two months ago, but I think it's too 
> big of a change to get into 1.8 this late. I personally don't want to 
> potentially have the release delayed because of possible issues with this 
> change.
>
> Collin
>
> On Friday, March 6, 2015 at 10:01:28 AM UTC-5, Chris Foresman wrote:
>>
>> Yeah, this is the point I was trying to make. I absolutely get your point 
>> about the impact to user, though, Josh. It just seems worth doing since 
>> this is an LTS release.
>>
>> On Friday, February 27, 2015 at 5:41:12 PM UTC-6, Daniel Hawkins wrote:
>>>
>>> I'd bet an extremely large portion of those users don't absolutely have 
>>>> to have an increased username field. They've gone this long without it.
>>>>
>>> They (we) have gone this long, not because we didn't need it, but 
>>> because we didn't think of it in the very beginning, and after that it was 
>>> too late.  The portion of users this would affect is exactly the same as 
>>> the set that is affected by the change in max_length on the User.email 
>>> field, which is already part of 1.8.  Given that fact, I don't see this as 
>>> a very big violation of the alpha/beta testing process.
>>>
>>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to 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/969d691d-1d70-4a89-8a13-242ac4becb63%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Rename *SSL* settings to *TLS*

[Collin Anderson]

I don't think it's really worth changing, but if anything, I'd recommend 
HTTPS rather than TLS, as that doesn't care about the underlying protocol 
which may change again in the future. Or maybe go with PROXY_SCHEME_HEADER 
or something.

On Friday, May 1, 2015 at 12:23:32 PM UTC-4, Hugo Osvaldo Barrera wrote:
>
> After searching through the documentation for a few TLS related settings, 
> I 
> failed to find anything. A while later, I found them as *SSL*. 
>
> I'd like to suggest renaming settings that mention SSL to TLS, to reflect 
> that 
> the former is now deprecated. 
>
>eg: SECURE_PROXY_SSL_HEADER -> SECURE_PROXY_TLS_HEADER 
>
> This should improve the ability for new users to find these settings, and 
> reflect current practices (eg: that SSL has been completely deprecated in 
> favour of TLS). 
>
> Any opinions or complaints to this? 
>
> -- 
> Hugo Osvaldo Barrera 
> A: Because we read from top to bottom, left to right. 
> Q: Why should I start my reply below the quoted text? 
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to 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/f17dcfa9-ad15-4fb7-9efc-c54053636e4e%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Redirect loop detection in test client is incorrect

[Collin Anderson]

If it helps, I believe Chrome and Firefox have a limit of 20, and Internet 
Explorer have a limit of 10.

On Friday, May 1, 2015 at 2:27:57 PM UTC-4, Mounir Messelmeni wrote:
>
> We've already the max total redirects counts it's 20
>
> if len(redirect_chain) > 20:
> # Such a lengthy chain likely also means a loop, but one with
> # a growing path, changing view, or changing query argument;
> # 20 is the value of "network.http.redirection-limit" from Firefox.
> raise RedirectCycleError("Too many redirects.", last_response=response)
>
>
>
> On Friday, May 1, 2015 at 8:24:48 PM UTC+2, Mounir Messelmeni wrote:
>>
>> I think 10 is already too much, it about redirecting to the same page N 
>> times. Page1 to Page, Page2 to Page3 and Page3 to the Page1: N=2 redirects 
>> to the Page1.
>> Do you think 10 times make senses? In my opinion it's too much and the 
>> need to raise an error to make developers know about something wrong in 
>> their redirects else they can override it for an extreme purpose.
>>
>> On Friday, May 1, 2015 at 7:54:44 PM UTC+2, Tim Graham wrote:
>>>
>>> Is there any disadvantage to making it some "large" number like 10? In 
>>> that case it probably wouldn't need to be configurable. The additional time 
>>> to do 10 loops instead of 2 is probably trivial (and it's an unexpected 
>>> condition anyway).
>>>
>>> On Friday, May 1, 2015 at 1:36:32 PM UTC-4, Mounir Messelmeni wrote:

 This is related to the ticket #24713, I'm trying to fix this issue and 
 I was thinking about using a variable to know how much time a single url 
 can be repeated on the redirects.
 Is two time sufficient or we will have another case that need 3 times.
 If you agree using a variable is it okay to pass it like the follow on 
 the get/post/head/trace/put method of the test client (max_page_redirect) 
 and make it by default 2 or store it on the settings ?

 def put(self, path, data='', content_type='application/octet-stream',
 follow=False, max_page_redirect=2,
 secure=False, **extra):
 """
 Send a resource to the server using PUT.
 """
 response = super(Client, self).put(path, data=data,
content_type=content_type,
secure=secure, **extra)
 if follow:
 response = self._handle_redirects(response, 
 max_page_redirect,
   **extra)
 return response




-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to 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/da3552dc-bd01-4f78-850e-240277fa01d5%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Proposal: Manually login without authenticate

[Collin Anderson]

One advantage of authenticate() is that it isn't coupled to a request and 
is roughly stateless. Maybe an authenticate_and_login() would be nice. :)

On Friday, May 22, 2015 at 12:21:15 PM UTC-4, James Brewer wrote:
>
> Hey Paulo,
>
> As you mentioned, the raw password should still be present in the form, 
> along with the username. You can use these as parameters for 
> `authenticate()`.
>
> More to your original point, I would be interested in knowing why 
> `authenticate()` and `login()` are separate methods. There is no 
> information on this in the docs (that I could find). Is there a use case 
> where you want to authenticate a user without logging them in?
>
> On Fri, May 22, 2015 at 8:57 AM, Paulo Gabriel Poiati  > wrote:
>
>> Maybe this is not the perfect example because we have the plain password 
>> in the form. Another one is if a backoffice user can log as any user of the 
>> system.
>>
>> On Fri, May 22, 2015 at 12:53 PM Paulo Gabriel Poiati <
>> paulog...@gmail.com > wrote:
>>
>>> Of course Tim,
>>>
>>> One instance is if you need to login the user after registration:
>>>
>>> class RegistrationView(CreateView):
>>> ...
>>> def form_valid(self, form):
>>> user = form.save()
>>> login(self.request, user)
>>> # redirect
>>>
>>>
>>> I don't have the user password because it's an one way hash and thus I 
>>> can't call `authenticate`. The only solution I can think is hacking the 
>>> auth system (setting the backend manually in the user model).
>>>
>>>
>>> On Fri, May 22, 2015 at 12:44 PM Tim Graham >> > wrote:
>>>
 Could you elaborate on what use case you are trying to solve?


 On Friday, May 22, 2015 at 11:36:21 AM UTC-4, poiati wrote:
>
> Hello guys,
>
> I want to discuss the current login workflow in django. As it is we 
> need to call `authenticate` before `login` because we need to set the 
> authentication backend in the user model. We can use login without 
> authenticate if we set the backend attr manually, but this need some 
> implementation knowledge of how authentication backends works.
>
> *PROPOSAL*
>
> *django.contrib.auth.login*
> Only set the backend in the http session if the user has the attr.
>
> request.session[SESSION_KEY] = user._meta.pk.value_to_string(user)
> request.session[HASH_SESSION_KEY] = session_auth_hashif hasattr(user, 
> 'backend'):
> request.session[BACKEND_SESSION_KEY] = user.backend
>
>
> *django.contrib.auth.get_user*
>
> If the backend is not set iterate over all the backends in 
> `settings.AUTHENTICATION_BACKENDS` and return the first found.
>
>
> I can think in two drawbacks of this implementation but as far as my 
> knowledge goes neither of them is a big deal.
>
>
> - Performance, in the worst case we are trying all the backends this can 
> take some time depending on the backend provider.
>
>
> - Two backends can share the same user identifier and thus we will be 
> using the first declared in the settings.
>
>
> What do you guys think?
>
>
> Thanks,
>
> Paulo Poiati.
>
>
>
>
>
>
>  -- 
 You received this message because you are subscribed to the Google 
 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/fbbd5579-a5e9-4370-8943-75204f334016%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-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/CABqSV%3D%2B5Vr%2B-JC2_yXdzwUpj9Y%2B1XwNOKf3_Fhc5h%3Dw4kuK%2BpQ%40mail.gmail.com
>>  
>> 
>> .
>>
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>

-- 
You received this message because you are subscribed t

Re: Idea: Better support for javascript heavy sites

[Collin Anderson]

Hi Emil,

I also like "server sent events" (EventSource). They get through proxies 
much more reliably than WebSockets. :)

"You would start the process separately, add a script tag to your page, and 
all clients that connected to the page would be connected to the process. 
Now Django could push messages through that process as part of the 
request-response cycle, and all clients would be notified. Other processes 
(a cron job?) could do the same."

Have you thought about how to scale this across multiple machines?

Thanks,
Collin


On Saturday, May 30, 2015 at 12:51:33 PM UTC-4, Emil Stenström wrote:
>
> Hi! 
>
> A couple of weeks ago I held a presentation on PyCon Sweden 2015 with 
> the title "Why Django Sucks". The idea was to follow in the footsteps of 
> great conference talks like these: 
> https://www.youtube.com/playlist?list=PLGYrvlVoAdf9j3v_teol3s7hl8gkUd8E2 
>
> These talks are great because they encourage people to take an outside, 
> critical, perspective of Django and where it's going. 
>
> My talk was well received, with many both interested and skeptical 
> questions afterwards. Unfortunately, the final video was missing the 
> sound, so the camera crew is working on fixing that now. I'll post it to 
> this thread as soon as I get it. Meanwhile, here's a text summary: 
>
> --- 
>
> The theme for my talk was that Django's bad support for Javascript heavy 
> sites. Everyone is using javascript for their sites nowadays. Problem 
> is, Django (and large parts if the Django community) has long had a 
> approach to Javascript that can be summed up with Simon Willison's reply 
> to someone asking for AJAX support in 2005: 
>
> "For me "Ajax support" really is pure marketing fluff - as far as I'm 
> concerned EVERY web framework supports Ajax unless it does something 
> truly moronic like refuse to let you output documents that don't have 
> the standard header/footer template." 
> Source: http://bit.ly/django2005 
>
> The problem with this mindset (I'm not picking at Simon from 10 years 
> ago) is that the web as large is moving towards MORE javascript, with 
> live notifications, live updating templates, and reusable template 
> components. And these are hard to implement in Django as things work 
> today. I see this is the biggest competitive disadvantage Django has 
> going forward. 
>
> So, what specific features am I proposing? I will get to a specific set 
> of features soon. But first I want to make clear that a completely 
> different set of features could get us to the same goal. That is: it's 
> possible to agree on the broader goal for Django, and disagree on my 
> specific set of features. If you don't agree on the features, I would 
> love to see your proposed feature list. 
>
> Just to give one alternate path: In that old thread from 2005, Jacob 
> Kaplan-Moss suggested exposing the ORM through Javascript with an RPC API: 
> https://groups.google.com/d/msg/django-developers/XmKfVxyuyAU/lkp6N1HTzG4J 
>
> Jacobs suggestion is interesting, but I have three other features that I 
> would like to discuss. I think they would greatly ease building 
> javascript heavy sites with Django. 
>
> *I will split the specific suggestions into three different e-mail 
> threads, so we can discuss them separately*. 
>
> Here's a short intro to them: 
>
> 1. Template Components 
> React.js popularized the notion that in front-end development, code 
> organization should be based on interface components, not split up into 
> HTML, Javascript and CSS. It's simply a different way to organize the 
> code for your front-end, that I strongly think Django should make 
> easier. (read more in separate thread) 
>
> 2. Support a client side template language 
> The multiple template engine work has made it possible to switch out 
> Django Templates with another engine. One of the most powerful things 
> this enables is to use a template language that is executable both on 
> the server and client. This means you can do the same kind of live 
> updates to your page that the Meteor.js people are doing, and just 
> re-render parts of the DOM as a direct result of a database update. 
> (read more in separate thread) 
>
> 3. Support Server-Sent Events 
> If you want a snappy user experience, polling isn't enough. There are 
> two major ways to get out of the request-response cycle. Namely: 
> websockets and server-sent events. Server-Sent Events have a much 
> simpler protocol, and could be implemented with asyncio (no external 
> dependencies except for backwards compatibility) in a performant way. It 
> would be a great reason to choose Django over other frameworks. (read 
> more in separate thread) 
>
> --- 
>
> This is not a "request for features". I am in no way saying that I think 
> you should build things for me. Instead I'm willing to work on  them 
> together with anyone interested, if these are features that the core 
> team would be interested in. 
>
> But first I would like to see if you: 
> 1. Agree on

Re: 1.9 release planning

[Collin Anderson]

1.8 - April 2015 (LTS): Dropped features deprecated in 1.6 [1.6 no longer 
supported].
1.9 - Dec. 2015: Drop features deprecated in 1.7 [1.7 no longer supported].
2.0 - Aug. 2016: No features dropped.
2.1 - April 2017 (LTS): Drop features deprecated in 1.8, 1.9 [1.9 no longer 
supported, third party apps can update to support 2.0 as a minimum version; 
1.8 users should use an old version of the third-party app for the ~1 year 
until 1.8 is unsupported].
2.2 - Dec. 2017: Drop features deprecated in 2.0 [2.0 no longer supported].

This is awesome.

So why not to have 2.0 drop features features deprecated in 1.8? If the 
replacement pattern/feature is available in 1.8, the 3rd party app should 
be able to use the new feature to stay compatible, right? If anything I'd 
like to see us hold off on dropping features deprecated in 1.9 until after 
the LTS to help people migrate between LTSs.

Thanks,
Collin


On Monday, June 1, 2015 at 9:20:07 AM UTC-4, Tim Graham wrote:
>
> I put together a draft proposal in the form of a potential 
> djangoproject.com blog post. I've enabled commenting in case you have 
> minor cosmetic comments, but please keep discussion about the content of 
> the proposal itself on this mailing list. Also, please let me know of any 
> additional questions or complaints that you'd like to see addressed in the 
> last section.
>
> The overview is:
> * New major release every 8 months
> * New long-term support release every 2 years. LTS releases continue to be 
> supported with security updates for 3 years.
> * Adjust the deprecation policy to make it easier for third-party apps to 
> support all versions back to the last LTS.
>
>
> https://docs.google.com/document/d/1bC6A8qc4skCmlagOnp8U7ddgyC-1XxXCBTlgrW690i0/edit?usp=sharing
>
> On Tuesday, April 7, 2015 at 3:20:55 PM UTC-4, Collin Anderson wrote:
>>
>> On Tuesday, April 7, 2015 at 2:31:08 PM UTC-4, Asif Saifuddin wrote:
>>>
>>> How about
>>>
>>> a 8 month release cycle and having a LTS in every two years and 
>>> supporting the old LTS atleast 3 years from the release date? there will be 
>>> 3 version between two LTS.
>>>
>>
>> Interesting. I like the idea of having predictable release dates.
>>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to 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/74456b73-2405-4484-8182-6f880f998752%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: 1.9 release planning

[Collin Anderson]

I see. I missed the "first upgrade Django to the last release before the 
next 
LTS (e.g. upgrade 1.8->1.9->2.0), then upgrade your dependencies to the 
newer version that supports both 2.0 and 2.1, and then finally upgrade 
to 2.1." part.

Thanks,
Collin

On Monday, June 1, 2015 at 11:02:01 AM UTC-4, Tim Graham wrote:
>
> If we dropped 1.8 deprecated features in 2.0, then it would require 
> libraries to add conditional code to support both the old and new ways of 
> doing something. The idea is that a third-party app wouldn't need to make 
> any updates (except those needed to accommodate for backwards incompatible 
> changes) until the next LTS release.
>
> The idea is *not* to suggest apps should try to support two LTS releases. 
> Making that easy on Django's end would require keeping deprecated features 
> in Django significantly longer than this proposal. See Carl's post in the 
> thread where we discussed the deprecation cycle changes: 
> https://groups.google.com/d/msg/django-developers/qCjfOu-FPxQ/hccAcVChHMkJ
>
> On Monday, June 1, 2015 at 10:20:13 AM UTC-4, Collin Anderson wrote:
>>
>> 1.8 - April 2015 (LTS): Dropped features deprecated in 1.6 [1.6 no longer 
>> supported].
>> 1.9 - Dec. 2015: Drop features deprecated in 1.7 [1.7 no longer 
>> supported].
>> 2.0 - Aug. 2016: No features dropped.
>> 2.1 - April 2017 (LTS): Drop features deprecated in 1.8, 1.9 [1.9 no 
>> longer supported, third party apps can update to support 2.0 as a minimum 
>> version; 1.8 users should use an old version of the third-party app for the 
>> ~1 year until 1.8 is unsupported].
>> 2.2 - Dec. 2017: Drop features deprecated in 2.0 [2.0 no longer 
>> supported].
>>
>> This is awesome.
>>
>> So why not to have 2.0 drop features features deprecated in 1.8? If the 
>> replacement pattern/feature is available in 1.8, the 3rd party app should 
>> be able to use the new feature to stay compatible, right? If anything I'd 
>> like to see us hold off on dropping features deprecated in 1.9 until after 
>> the LTS to help people migrate between LTSs.
>>
>> Thanks,
>> Collin
>>
>>
>> On Monday, June 1, 2015 at 9:20:07 AM UTC-4, Tim Graham wrote:
>>>
>>> I put together a draft proposal in the form of a potential 
>>> djangoproject.com blog post. I've enabled commenting in case you have 
>>> minor cosmetic comments, but please keep discussion about the content of 
>>> the proposal itself on this mailing list. Also, please let me know of any 
>>> additional questions or complaints that you'd like to see addressed in the 
>>> last section.
>>>
>>> The overview is:
>>> * New major release every 8 months
>>> * New long-term support release every 2 years. LTS releases continue to 
>>> be supported with security updates for 3 years.
>>> * Adjust the deprecation policy to make it easier for third-party apps 
>>> to support all versions back to the last LTS.
>>>
>>>
>>> https://docs.google.com/document/d/1bC6A8qc4skCmlagOnp8U7ddgyC-1XxXCBTlgrW690i0/edit?usp=sharing
>>>
>>> On Tuesday, April 7, 2015 at 3:20:55 PM UTC-4, Collin Anderson wrote:
>>>>
>>>> On Tuesday, April 7, 2015 at 2:31:08 PM UTC-4, Asif Saifuddin wrote:
>>>>>
>>>>> How about
>>>>>
>>>>> a 8 month release cycle and having a LTS in every two years and 
>>>>> supporting the old LTS atleast 3 years from the release date? there will 
>>>>> be 
>>>>> 3 version between two LTS.
>>>>>
>>>>
>>>> Interesting. I like the idea of having predictable release dates.
>>>>
>>>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to 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/2c2a867b-c9fd-4bb0-98fd-e2f740a76f9f%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Form assets and static file storage

[Collin Anderson]

Hi Dom,

Yeah, it looks like the admin_static is simply uses the staticfiles tag if 
staticfiles is installed, otherwise falls back to the core static? The only 
reason why it admin_static exists is because the admin can't rely on 
staticfiles being installed, right? Maybe pulling the the staticfiles tag 
into builtins would help?

Collin

On Tuesday, June 9, 2015 at 4:51:50 PM UTC-4, Dominic Rodger wrote:
>
> I recently came across a problem when using ManifestStaticFilesStorage on 
> an app with form media, which the documentation doesn't seem to address. 
> I'm posting here rather that on django-users, since I think we ought to at 
> least document how to fix it, or preferably come up with a better way of 
> solving it.
>
> The app I was using is django-image-cropping, which specifies the media 
> for a widget like this (see image_cropping/widgets.py#L60 
> 
> ):
>
> def _media(self):
> js = [
> "image_cropping/js/jquery.Jcrop.min.js",
> "image_cropping/image_cropping.js",
> ]
>
> css = {'all': ("image_cropping/css/jquery.Jcrop.min.css",
>"image_cropping/css/image_cropping.css",)}
> return forms.Media(css=css, js=js)
>
> media = property(_media)
>
> When rendered to HTML, it generates a static path (i.e. STATIC_URL is 
> prepended), but doesn't correctly generate paths to minified content, so 
> you get 404s. django.contrib.admin has worked around this - by using the 
> admin_static template tag (see 
> django/contrib/admin/templatetags/admin_static.py#L10 
> ).
>  
> I fixed up django-image-cropping by porting that workaround to the app 
> itself (see PR 
> ), but 
> it feels like it might be worth documenting how people should be handling 
> this in their apps. I'm thinking of something along the lines of making the 
> code in admin_static.py less admin specific (so far as I can see, it 
> doesn't actually have anything to do with django.contrib.admin) - perhaps 
> exposing the functionality in django.utils, and then having the templatetag 
> admin_static use that function.
>
> If I've missed something, my apologies, but I couldn't find any tickets 
> related to this. It seems like something others would have come across 
> already, so again, apologies if there's already a ticket for this, or if 
> I've gone about this in a braindead way.
>
> If patches/tickets need writing, I'd be happy to get stuck in - just 
> wanted some clarity that I'm not crazy first :)
>
> Dom
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to 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/3dc311ab-aec2-4ae1-b6a8-6501828c383b%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: 1.9 release planning

[Collin Anderson]

Hi All,

Here are some thoughts in reply to some of the comments in the 
django-compat thread. I don't stick to the LTSs myself, but I've helped 
maintain apps that have 1.4 compatibility.

On Tuesday, June 9, 2015 at 7:05:45 PM UTC-4, Loïc Bistuer wrote:
>
> 1.8 (LTS): No features dropped. 
> 1.9: Dropped features deprecated in 1.4, 1.5, 1.6, 1.7 
> 2.0: No features dropped. 
> 2.1 (LTS): No features dropped. 
> 2.2: Dropped features deprecated in 1.8, 1.9, 2.0 
>

I'd propose something slightly different, that's very close to our current 
deprecation timeline:
1.8 (LTS): No features dropped.
1.9: Dropped features deprecated in 1.5, 1.6, 1.7
2.0: Dropped features deprecated in 1.8
2.1 (LTS): No features dropped. 
2.2: Dropped features deprecated in 1.9, 2.0
2.3: Dropped features deprecated in 2.1

Seems to me features deprecated in an LTS are fair game to disappear in the 
next LTS. This allows us to remove "dotted paths in reverse() and url()" 
because that's deprecated in 1.8.

If we can guarantee compatibility between LTSs, I think that would be a 
huge win, at the cost of extending the removal of some deprecated features 
by one release (8 months). 

Collin

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to 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/586e0962-f73f-40b5-9113-8a703f9afd68%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: 1.9 release planning

[Collin Anderson]

On Friday, May 8, 2015 at 12:12:37 PM UTC-4, Carl Meyer wrote:
>
> And there is a significant added maintenance cost to my proposal 
> compared to yours. Dropping deprecated APIs in the release after an LTS 
> means we still have to support those APIs for three more years (possibly 
> for four or five years after they were first deprecated). Dropping them 
> _in_ the LTS release shortens that window drastically.


If we release every 8 months, that means we normally support deprecated 
features for 2 years. If we maintained LTS compatibility, then, yes, that 
would mean "supporting" the APIs for more than 5 years after deprecation. 
But to be clear, most of that time it's only security support for those 
APIs, and the APIs are long gone from master. Right?

Thanks,
Collin


On Wednesday, June 10, 2015 at 1:37:30 PM UTC-4, Collin Anderson wrote:
>
> Hi All,
>
> Here are some thoughts in reply to some of the comments in the 
> django-compat thread. I don't stick to the LTSs myself, but I've helped 
> maintain apps that have 1.4 compatibility.
>
> On Tuesday, June 9, 2015 at 7:05:45 PM UTC-4, Loïc Bistuer wrote:
>>
>> 1.8 (LTS): No features dropped. 
>> 1.9: Dropped features deprecated in 1.4, 1.5, 1.6, 1.7 
>> 2.0: No features dropped. 
>> 2.1 (LTS): No features dropped. 
>> 2.2: Dropped features deprecated in 1.8, 1.9, 2.0 
>>
>
> I'd propose something slightly different, that's very close to our current 
> deprecation timeline:
> 1.8 (LTS): No features dropped.
> 1.9: Dropped features deprecated in 1.5, 1.6, 1.7
> 2.0: Dropped features deprecated in 1.8
> 2.1 (LTS): No features dropped. 
> 2.2: Dropped features deprecated in 1.9, 2.0
> 2.3: Dropped features deprecated in 2.1
>
> Seems to me features deprecated in an LTS are fair game to disappear in 
> the next LTS. This allows us to remove "dotted paths in reverse() and 
> url()" because that's deprecated in 1.8.
>
> If we can guarantee compatibility between LTSs, I think that would be a 
> huge win, at the cost of extending the removal of some deprecated features 
> by one release (8 months). 
>
> Collin
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to 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/d3fabc7e-6811-4a85-96c4-fdc651e366cf%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: 1.9 release planning

[Collin Anderson]

Hi Tim,

What I mean is we could still make it easy to support both LTS releases, 
even if we drop features deprecated in 1.8 before the next LTS according to 
the normal release schedule. Right? Because apps wouldn't need to use those 
deprecated features to support both 1.8 and 2.1. We could drop them in 2.0 
like normal?

I'm trying to lessen the increased maintenance burden of Loic's proposal 
while still making it possible to easily support both LTS releases.

> For "maintenance costs" I am not worried about supported deprecated APIs 
in old releases, only how long they stay around in master as that could be 
a barrier to innovation.
Right, so the cost would be an extra 8 months before removing features 
deprecated in 1.9 from master.

Thanks,
Collin

On Wednesday, June 10, 2015 at 2:09:13 PM UTC-4, Tim Graham wrote:
>
> Collin, I'm not following your reasoning about why dropping features 
> deprecated in one LTS (e.g. 1.8) in the next LTS (e.g. 2.1; I think you 
> made a typo in your timeline putting it next to 2.0?) will make it possible 
> to easily support both LTS releases? That's the purpose of Loic's proposal 
> I believe.
>
> For "maintenance costs" I am not worried about supported deprecated APIs 
> in old releases, only how long they stay around in master as that could be 
> a barrier to innovation.
>
> On Wednesday, June 10, 2015 at 1:54:53 PM UTC-4, Collin Anderson wrote:
>>
>> On Friday, May 8, 2015 at 12:12:37 PM UTC-4, Carl Meyer wrote:
>>>
>>> And there is a significant added maintenance cost to my proposal 
>>> compared to yours. Dropping deprecated APIs in the release after an LTS 
>>> means we still have to support those APIs for three more years (possibly 
>>> for four or five years after they were first deprecated). Dropping them 
>>> _in_ the LTS release shortens that window drastically.
>>
>>
>> If we release every 8 months, that means we normally support deprecated 
>> features for 2 years. If we maintained LTS compatibility, then, yes, that 
>> would mean "supporting" the APIs for more than 5 years after deprecation. 
>> But to be clear, most of that time it's only security support for those 
>> APIs, and the APIs are long gone from master. Right?
>>
>> Thanks,
>> Collin
>>
>>
>> On Wednesday, June 10, 2015 at 1:37:30 PM UTC-4, Collin Anderson wrote:
>>>
>>> Hi All,
>>>
>>> Here are some thoughts in reply to some of the comments in the 
>>> django-compat thread. I don't stick to the LTSs myself, but I've helped 
>>> maintain apps that have 1.4 compatibility.
>>>
>>> On Tuesday, June 9, 2015 at 7:05:45 PM UTC-4, Loïc Bistuer wrote:
>>>>
>>>> 1.8 (LTS): No features dropped. 
>>>> 1.9: Dropped features deprecated in 1.4, 1.5, 1.6, 1.7 
>>>> 2.0: No features dropped. 
>>>> 2.1 (LTS): No features dropped. 
>>>> 2.2: Dropped features deprecated in 1.8, 1.9, 2.0 
>>>>
>>>
>>> I'd propose something slightly different, that's very close to our 
>>> current deprecation timeline:
>>> 1.8 (LTS): No features dropped.
>>> 1.9: Dropped features deprecated in 1.5, 1.6, 1.7
>>> 2.0: Dropped features deprecated in 1.8
>>> 2.1 (LTS): No features dropped. 
>>> 2.2: Dropped features deprecated in 1.9, 2.0
>>> 2.3: Dropped features deprecated in 2.1
>>>
>>> Seems to me features deprecated in an LTS are fair game to disappear in 
>>> the next LTS. This allows us to remove "dotted paths in reverse() and 
>>> url()" because that's deprecated in 1.8.
>>>
>>> If we can guarantee compatibility between LTSs, I think that would be a 
>>> huge win, at the cost of extending the removal of some deprecated features 
>>> by one release (8 months). 
>>>
>>> Collin
>>>
>>>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to 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/512e9895-7216-4e0d-95dc-8c506c6646dd%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: 1.9 release planning

[Collin Anderson]

Hi Matt,

I was thinking about this too and it came up on IRC today. I think if we 
were to strictly go with something like semver, we'd end up with a 
numbering scheme like 2.0, 2.1 (LTS), 3.0, 4.0, 4.1 (LTS), 5.0, etc, 
because features can be removed in between LTSs (assuming they're marked as 
deprecated in the previous LTS).

Collin

On Thursday, June 11, 2015 at 9:31:08 PM UTC-4, Matt Austin wrote:
>
> On 11 June 2015 at 01:37, Collin Anderson  > wrote: 
> > 
> > I'd propose something slightly different, that's very close to our 
> current 
> > deprecation timeline: 
> > 1.8 (LTS): No features dropped. 
> > 1.9: Dropped features deprecated in 1.5, 1.6, 1.7 
> > 2.0: Dropped features deprecated in 1.8 
> > 2.1 (LTS): No features dropped. 
> > 2.2: Dropped features deprecated in 1.9, 2.0 
> > 2.3: Dropped features deprecated in 2.1 
> > 
> > Seems to me features deprecated in an LTS are fair game to disappear in 
> the 
> > next LTS. This allows us to remove "dotted paths in reverse() and url()" 
> > because that's deprecated in 1.8. 
> > 
> > If we can guarantee compatibility between LTSs, I think that would be a 
> huge 
> > win, at the cost of extending the removal of some deprecated features by 
> one 
> > release (8 months). 
> > 
>
> Hi everyone, 
>
> Sorry to stick my nose in, but thought I might throw a potential 
> spanner-in-the works with this release discussion, in regard to 
> version naming. 
>
> I understand that the current version system doesn't have too much 
> inherent meaning, and that 2.0 will come after 1.9 'just so we don't 
> stay on 1.x forever'. 
>
> With a more structured release plan, and LTS releases, would it be 
> worth considering LTS releases as 'major' version numbers, with 
> regular releases and 'minor' version releases? It would be easier to 
> identify LTS releases at a glance, and might provide more meaning to 
> the versioning scheme? 
>
> Feel free to shut this idea down if it's going to open a can-of-worms :) 
>
>
> Cheers, 
>
> -- 
> Matt 
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to 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/43108c2b-e8f0-4d69-bb70-da3ac4c516ca%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: how long to support Python 3.3?

[Collin Anderson]

Some more data points (to support removing 3.3 support):

I believe old versions of RHEL were the reason people needed 2.6 support. 
Unlike 2.6, I believe RHEL has never supported Python 3 except through 
"Software Collections", and the Python33 software collection EOL is Oct 
2016 (before 1.8 support ends). There is also now a Python 3.4 software 
collection.
https://access.redhat.com/support/policy/updates/rhscl

Looking at recent PyPI data gathered by Donald: 
https://caremad.io/2015/04/a-year-of-pypi-downloads/
It looks like 3.3 has less usage than Python2.6 in the Django world.
https://caremad.io/images/a-year-of-pypi-downloads/django-stacked-py-pct.png
(It also looks like 3.x usage has more than doubled over the last year. :)

On Saturday, June 13, 2015 at 7:00:55 PM UTC-4, Tim Graham wrote:
>
> Django 1.8 was the last version to support Python 3.2, which has its 
> security updates end February 2016. That means Python 3.2 users can 
> continue getting Django security updates for about 2 years after Python 
> security updates end. I am wondering if we should instead try to better 
> align the end of Python support with the end of Django support? (By the 
> way, Django 1.4 supports Python 2.5 which had its security updates end Oct 
> 2011 and since we had trouble configuring Jenkins with Python 2.5, we broke 
> compatibility a couple times in recent security releases -- now I run the 
> tests locally as needed).
>
> Let's take Python 3.3 as an example. Security updates for Python 3.3 are 
> scheduled to end in September 2017. Django 1.8 supports 3.3 and will 
> receive updates until April 2018. Given anyone using 3.3 is covered by the 
> LTS, I'm inclined to drop 3.3 support now (in Django 1.9). Alternatively, 
> the next two major releases of Django will be supported until April 2017 
> and December 2017. 
>
> I don't find Django support for 3.3 to be a big burden, but there are 
> occasional issues such as new features in 3.4 that are missing and need to 
> be backported for 3.3 (today I ran into a pull request with a need for 
> glob.escape(), so we needed a backport that works on Python 2 and Python 
> 3.3). The other consideration is that Python 3.5 will be released in 
> September, so we'd be back to 3 versions of Python 3 for Jenkins to test 
> against.
>
> Are there any users of Python 3.3 out there who find that there are big 
> obstacles to upgrading to 3.4?
>
> I think it's useful to plan ahead a bit to try to avoid cases such as the 
> enterprise users who are now stuck on Python 2.6 and Django 1.6.
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to 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/b9ab444e-b152-4675-9fce-cd7192dd89dc%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: 1.9 release planning

[Collin Anderson]

I also like the gdoc as it is. (1.8 LTS, 1.9, 2.0, 2.1 LTS, 3.0, 3.1, 3.2 
LTS, 4.0, etc.) LTS is the final of a major version number, and we 
sacrifice a little bit of strict semver, but it give some nice meaning to 
the version numbers.

On Tuesday, June 16, 2015 at 12:22:44 PM UTC-4, Carl Meyer wrote:
>
> Thanks Loïc, 
>
> On 06/16/2015 01:15 AM, Loïc Bistuer wrote: 
> > I've attempted to summarize the history of this thread. Note that I 
> > marked as +1 any generally positive feedback towards a given 
> > proposal, please correct if you feel misrepresented. 
> > 
> [snip] 
> > 
> > # Third iteration: 
> > 
> > 5/ Switching to Semantic Versioning 
> > 
> > Donald mentioned SemVer on IRC a few days ago. Since then various 
> > proposal were made to reconcile it with our release policy. So far 
> > Collin, Carl, Loïc, Tim, and Josh have expressed positive feedback to 
> > various proposals in that direction but I don't think we have yet 
> > reached consensus on a specific one. Tim updated the Google doc to 
> > reflect my latest proposal, so including me that's 2 formal +1 for 
> > it, but I'd say we should wait for at least a couple more votes 
> > before taking it to the technical board. 
> > 
> > Refs: - http://semver.org/ - Carl's analysis 
> > 
> https://groups.google.com/d/msg/django-developers/MTvOPDNQXLI/Ojov2QBROg8J 
> > 
> > 
> - Ryan's proposals 
> https://groups.google.com/d/msg/django-developers/MTvOPDNQXLI/lBLWrhKJ6DIJ 
> > - Loïc's proposal 
> > 
> https://groups.google.com/d/msg/django-developers/MTvOPDNQXLI/y2QbPVzSs6cJ 
>
> FWIW, I am also +1 on your proposal, as currently documented in the 
> Google doc. 
>
> I was trying to come up with a proposal where LTS == major release for 
> the sake of argument, since it seemed like that was intuitive to at 
> least some people, but it's not worth the required lengthening of 
> deprecation paths. Your proposal is much better. (And it does make some 
> intuitive sense for the _last_ minor release in a major series to be LTS 
> rather than the first). 
>
> 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/ebc7b0ae-27aa-4848-a6b5-9cec4b374895%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: 1.9 release planning

[Collin Anderson]

People import the warning in order to silence them, right?

On Monday, June 22, 2015 at 1:19:51 PM UTC-4, Markus Holtermann wrote:
>
> +1 -- Going with 1.8, 1.9, 1.10, 1.11 (LTS), 2.0 sounds like a solid 
> plan. I don't think any of the (Pending)DeprecationWarnings are much of 
> a public API. I've never seen them in the wild. 
>
> /Markus 
>
> On Mon, Jun 22, 2015 at 11:20:52AM -0400, Michael Manfre wrote: 
> >+1. I really don't like the idea of 2.x being odd. 
> > 
> >On Mon, Jun 22, 2015 at 10:33 AM, Loïc Bistuer  > 
> >wrote: 
> > 
> >> Just when we thought we had a winner... I'd like to make a final 
> proposal. 
> >> 
> >> Instead of delaying adoption of SemVer to 3.0 we could do so in 2.0 by 
> >> introducing the 1.10 and 1.11LTS releases. 
> >> 
> >> The upside is that the new policy applies right away and we avoid the 
> >> oddball 2.0 and 2.1 releases. 
> >> 
> >> It's much less invasive than the previous idea of renaming 1.9 to 2.0, 
> but 
> >> it still requires renaming PendingDeprecationWarnings in 1.8, and both 
> >> warnings in 1.9. 
> >> 
> >> What do you think? 
> >> 
> >> -- 
> >> Loïc 
> >> 
> >> > On Jun 17, 2015, at 08:47, Josh Smeaton  > wrote: 
> >> > 
> >> > I'm also +1 on the proposal as it stands, and neutral on when the 
> semver 
> >> versioning should begin. 
> >> > 
> >> > On Wednesday, 17 June 2015 05:03:47 UTC+10, Michael Manfre wrote: 
> >> > I'm +1 on the Google doc proposal and like Markus, I support 
> relabeling 
> >> 1.9 to 2.0 to line the versions up with the new paradigm without the 
> X.1 
> >> LTS oddball. 
> >> > 
> >> > Regards, 
> >> > Michael Manfre 
> >> > 
> >> > On Tue, Jun 16, 2015 at 12:34 PM, Collin Anderson  
>
> >> wrote: 
> >> > I also like the gdoc as it is. (1.8 LTS, 1.9, 2.0, 2.1 LTS, 3.0, 3.1, 
> >> 3.2 LTS, 4.0, etc.) LTS is the final of a major version number, and we 
> >> sacrifice a little bit of strict semver, but it give some nice meaning 
> to 
> >> the version numbers. 
> >> > 
> >> > 
> >> > On Tuesday, June 16, 2015 at 12:22:44 PM UTC-4, Carl Meyer wrote: 
> >> > Thanks Loïc, 
> >> > 
> >> > On 06/16/2015 01:15 AM, Loïc Bistuer wrote: 
> >> > > I've attempted to summarize the history of this thread. Note that I 
> >> > > marked as +1 any generally positive feedback towards a given 
> >> > > proposal, please correct if you feel misrepresented. 
> >> > > 
> >> > [snip] 
> >> > > 
> >> > > # Third iteration: 
> >> > > 
> >> > > 5/ Switching to Semantic Versioning 
> >> > > 
> >> > > Donald mentioned SemVer on IRC a few days ago. Since then various 
> >> > > proposal were made to reconcile it with our release policy. So far 
> >> > > Collin, Carl, Loïc, Tim, and Josh have expressed positive feedback 
> to 
> >> > > various proposals in that direction but I don't think we have yet 
> >> > > reached consensus on a specific one. Tim updated the Google doc to 
> >> > > reflect my latest proposal, so including me that's 2 formal +1 for 
> >> > > it, but I'd say we should wait for at least a couple more votes 
> >> > > before taking it to the technical board. 
> >> > > 
> >> > > Refs: - http://semver.org/ - Carl's analysis 
> >> > > 
> >> 
> https://groups.google.com/d/msg/django-developers/MTvOPDNQXLI/Ojov2QBROg8J 
> >> > > 
> >> > > 
> >> > - Ryan's proposals 
> >> > 
> >> 
> https://groups.google.com/d/msg/django-developers/MTvOPDNQXLI/lBLWrhKJ6DIJ 
> >> > > - Loïc's proposal 
> >> > > 
> >> 
> https://groups.google.com/d/msg/django-developers/MTvOPDNQXLI/y2QbPVzSs6cJ 
> >> > 
> >> > FWIW, I am also +1 on your proposal, as currently documented in the 
> >> > Google doc. 
> >> > 
> >> > I was trying to come up with a proposal where LTS == major release 
> for 
> >> > the sake of argument, since it seemed like that was intuitive to at 
> >> > least some people, but it's not worth the required lengthening of 
> >> > deprecation paths. Your propo

Re: [django.contrib.postgres] Would this be accepted and how hard would it be to do?

[Collin Anderson]

I think XMLField was removed because the security of xml parsing and 
validating is hard to get right.

On Sunday, June 28, 2015 at 7:51:22 PM UTC-4, Russell Keith-Magee wrote:
>
>
> On Mon, Jun 29, 2015 at 7:32 AM, Josh Smeaton  > wrote:
>
>> I'm not quite up to date on XML in databases (I've never had to use XML 
>> in a database), but don't the majority of core backends support XML in some 
>> way? If so, I'd probably like to see an attempt to build out XML support 
>> such that all/most core databases could benefit from the new feature, 
>> rather than being locked away in contrib.postgres.
>>
>  
> Heh... 
>
>
> https://github.com/django/django/blob/stable/1.3.x/django/db/models/fields/__init__.py#L1135
>
> So, to answer your questions:
>>
>> Is this a project that; 
>> a) would be accepted - Probably, if someone were to implement it and 
>> drive it until quality was acceptable
>> b) would be fairly straight forward and - I'm not sure how 
>> straightforward it would be. The addition of Lookups and Transforms will 
>> help tremendously though.
>> c) would be useful to the wider community? - Not for me personally, but 
>> I'm sure there'd be others that would find good use for XML support. 
>> Hopefully we can get some more feedback to accurately determine that though.
>>
>
> Broadly, I agree with Josh. 
>
> Given that we have contrib.postgres, we should be aiming at 100% coverage 
> of PostgreSQL features in core (not saying that is possible or likely, but 
> it's an aspirational goal). 
>
> In cases where it is plausible to implement a feature for all backends, we 
> should aim to do that. 
>
> However, I don't think we should be cross platform at all costs. It would 
> be possible to implement XMLField as a light layer over TextField (hey - we 
> used to do exactly this), but if that's the only way to implement it, I 
> don't think we should implement it at all. I'm not in favour of 
> implementing known-to-be-slow design patterns for core features. Unless 
> SQLite and MySQL offer a native XML data type, with reasonably rich query 
> syntax, then I don't think a cross-platform is desirable.
>
> Yours,
> Russ Magee %-)
>
>

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

Re: @csrf_protect annoying on django.contrib.auth.views.login

[Collin Anderson]

Hi,

This is the best reason I could find:
http://security.stackexchange.com/questions/62769/must-login-and-logout-action-have-csrf-protection

One thing that's going on here is that the csrftoken changes every time 
someone logs in, so the old login page now has a stale token. The changing 
csrf token has bitten me a bunch of times. I've gotten around it by using 
javascript to correct the token when submitting the form.

$(document).on('submit', 'form[method=post]', function() { 
  $(this.csrfmiddlewaretoken).val(document.cookie.match(
'csrftoken=([a-zA-Z0-9]{32})')[1])
})

Collin

On Wednesday, July 1, 2015 at 7:13:42 PM UTC-4, md...@pdx.edu wrote:
>
> Is there a reason django.contrib.auth.views.login should be decorated 
> with csrf_protect? It results in annoying behavior, in the following 
> scenario:
>
> In a browser window (Window1), go to the login page.
> In another browser window (Window2), go to the login page, and actually 
> login, then logout.
> Back in Window1, fill in your credentials, and try to login. You get a 403.
>
> It seems like django.contrib.auth.views.login should be decorated with 
> csrf_exempt instead. Are there any major security implications?
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to 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/629c1649-9e4c-4bdf-bebf-8f7a2e1624b9%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Inheritance in admin classes

[Collin Anderson]

Hi All,

It seems to me this is just how class inheritance works in Python. Nothing 
special in Django here, it just might not be intuitive.

I do think deepcopy has too much overhead to warrant a deepcopy by default 
in Django for everyone, but it may help you to use it in your code.

Collin

On Thursday, July 2, 2015 at 6:46:37 AM UTC-4, Jani Tiainen wrote:
>
> Hi, 
>
> I had my fun when I tried to add more inline stuff to a Admin form, and I 
> ended up doing thiskind of stuff: 
>
>
> https://janimagik.wordpress.com/2015/05/05/django-admin-and-inline-chaining/ 
>
> I guess problem is how Django admin uses metaclass to do some magic behind 
> the scenes. 
>
> On Thu, 2 Jul 2015 03:30:59 -0700 (PDT) 
> kny...@knyg.ht  wrote: 
>
> > I think it could be - if not the exact same issue - one that would be 
> fixed 
> > by the same patch. My specific use case is something like this: 
> > 
> > class MyUserAdmin(UserAdmin): 
> > def get_fieldsets(self, request, obj=None): 
> > fieldsets = super().get_fieldsets(request, obj) 
> > fieldsets[0][1]['fields'] = list(fieldsets[0][1]['fields']) 
> > fieldsets[0][1]['fields'].append('category') 
> > 
> > which is already pretty ugly, but needs uglifying further: 
> > 
> > class MyUserAdmin(UserAdmin): 
> > def get_fieldsets(self, request, obj=None): 
> > fieldsets = super().get_fieldsets(request, obj) 
> > fieldsets[0][1]['fields'] = list(fieldsets[0][1]['fields']) 
> > 
> > if 'category' not in fieldsets[0][1]['fields'][-1]: 
> > fieldsets[0][1]['fields'].append('category') 
> > 
> > Logically, they could be the same issue, but I haven't dug in to see if 
> > this is the case. Is it really the case that the overhead of deepcopy() 
> is 
> > too much here? 
> > 
> > 
> > On Thursday, July 2, 2015 at 2:33:24 AM UTC+1, Tim Graham wrote: 
> > > 
> > > Could it be https://code.djangoproject.com/ticket/22828 ? 
> > > 
> > > On Wednesday, July 1, 2015 at 5:32:48 PM UTC-4, kny...@knyg.ht wrote: 
> > >> 
> > >> Hello all, 
> > >> 
> > >> So, I was talking to kezabelle on IRC some months back about a 
> problem I 
> > >> was having, and finally remembered to post something. 
> > >> 
> > >> If I inherit from an admin class, and override something like 
> > >> get_fields(), I was getting back duplicates of fields if I used 
> super() to 
> > >> get the existing fields and add to them. And if I reload the page, I 
> would 
> > >> get more and more fields until I restarted the dev server. Something 
> about 
> > >> ModelAdmin being one instance per process. It seems very 
> counter-intuitive 
> > >> to me, and I was wondering if anyone was considering fixing this? I'm 
> under 
> > >> the impression it might be some work to do. 
> > >> 
> > >> Cheers, 
> > >> Tom 
> > >> 
> > > 
> > 
> > -- 
> > You received this message because you are subscribed to the Google 
> Groups "Django developers  (Contributions to Django itself)" group. 
> > To unsubscribe from this group and stop receiving emails from it, send 
> an email to django-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/bd375dce-428f-4ca3-a2bc-2533f47134db%40googlegroups.com.
>  
>
> > For more options, visit https://groups.google.com/d/optout. 
>
>
> -- 
> Jani Tiainen 
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to 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/db1880d0-7a90-44df-87bd-b6de558b2f0c%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Django 1.9 - JSONField

[Collin Anderson]

Sounds good to me, though I think we should wait until there's actually 
native JSON support in one of the other databases. MariaDB has "dynamic 
columns" which I think is more similar to Postgres's hstore.

On Wednesday, July 8, 2015 at 4:38:42 AM UTC-4, Григорий Крамаренко wrote:
>
> +1
> I'm waiting too and hope for a positive decision.
>
> вторник, 7 июля 2015 г., 23:57:37 UTC+10 пользователь lza...@ucs.br 
> написал:
>>
>>
>> Hi all,
>>
>> I'd like to know why this feature will be only available on postgres and 
>> not as a Field for any database, like this product? This Field would be 
>> very usefull for many users I think.
>>
>> https://github.com/bradjasper/django-jsonfield
>>
>>
>> https://docs.djangoproject.com/en/dev/releases/1.9/#django-contrib-postgres
>>
>> By.
>>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to 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/a8ed3fae-b657-4ade-91cf-33f339e534c5%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: User.username max_length 254

[Collin Anderson]

Hi Anders,

I think we need to make it as easy as possible for people to add back the 
30-character restriction if they want, especially in the admin. Really good 
documentation of what to do should be good enough I hope, but we need to 
make sure it's easy and there aren't too many side-effects.

Thanks,
Collin

On Thursday, July 9, 2015 at 9:49:42 AM UTC-4, Anders Petersson wrote:
>
> Hey, I would like to see this get into 1.9,
>
> Can anyone suggest whats needed to merge 
> https://github.com/django/django/pull/4250 ?
>
> On Tuesday, June 2, 2015 at 3:18:35 AM UTC+2, Ryan Floyd wrote:
>>
>> I solved this in a very hacky way, without touching any django code. I'll 
>> probably break the forms
>>
>> 1. Create an empty migration (python manage.py makemigrations --name 
>> extend_username_field --empty [app_name])
>> 2. Inside the migration, add:
>> ```
>> operations = [
>> migrations.RunSQL('ALTER TABLE auth_user ALTER COLUMN username TYPE 
>> varchar(254);')
>> ]
>> ```
>>
>> Works so far, but haven't really tested it extensively
>>
>> -Ryan
>>
>> On Wednesday, April 22, 2015 at 10:26:31 AM UTC-5, Micah Hausler wrote:
>>>
>>> I actually migrated my site to 1.7 and added a custom user model very 
>>> easily. Here's a gist with the code, 
>>> https://gist.github.com/micahhausler/63636f26cc87bb966218, but 
>>> essentially all I had to do was add a new user app, copy the Django 
>>> AbstractUser code, and set the db_table to 'auth_user'.
>>>
>>>
>>> class User(AbstractBaseUser, PermissionsMixin):
>>>  
>>> objects = UserManager()
>>>  
>>> class Meta:
>>> db_table = 'auth_user'
>>>
>>>
>>>
>>> Does anyone think this method could be worth adding to the Django 
>>> documentation? I'd be happy to open a ticket/write the docs. The only side 
>>> effect would be that if someone were using content-types for auth_user 
>>> objects, that would need to be migrated.
>>>  
>>> Micah Hausler
>>>
>>>
>>> On Friday, February 6, 2015 at 8:10:02 PM UTC-5, Collin Anderson wrote:
>>>>
>>>> Hi All,
>>>>
>>>> I was reminded by:
>>>> Allow shadowing of abstract fields 
>>>> https://groups.google.com/d/msg/django-developers/6zUfnElOIks/8uwXji559EsJ
>>>> and https://code.djangoproject.com/ticket/24288 (Custom User Models 
>>>> for small tweaks).
>>>>
>>>> Could we reopen https://code.djangoproject.com/ticket/20846 and 
>>>> increase User.username max_length to 254?
>>>>
>>>> Personally, that's the only thing I've ever needed to change about my 
>>>> User class. I just need it long enough to hold email addresses. I've seen 
>>>> many other people wanting the same thing.
>>>>
>>>> In 1.8 we migrated the length of EmailField from 75 to 254, so it 
>>>> should be almost™ as easy to change the username field.
>>>>
>>>> If needed, we could keep the 30-character limit on UserCreationForm and 
>>>> UserChangeForm for backwards compatibility. The limit in the database is 
>>>> the real killer :) Though, consistency is also nice.
>>>>
>>>> Thanks,
>>>> Collin
>>>>
>>>>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to 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/15a1d811-261f-4ca0-b8f6-8282a5de40bd%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Renaming the postgresql_psycopg2 backend

[Collin Anderson]

We definitely should make sure postgresql_psycopg2 still works as expected. 
As a data point, Heroku uses "postgres" instead of "postgresql" in their 
DATABASE_URL scheme. Maybe we could support all three? :)

On Wednesday, July 15, 2015 at 9:17:30 AM UTC-4, Baptiste Mispelon wrote:
>
> Hi everyone, 
>
> After starting a new project recently and failing three times to type 
> the name of the postgres backend correctly, I was wondering if there's 
> really any value in keeping around this strange name. 
>
>  From what I understand, it's a historical artifact from a time when 
> there was more than one postgres backend. 
>
>
> Could we at least make it an alias of a more simply named "postgresql" 
> backend? 
>
>
> Thanks, 
> Baptiste 
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to 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/3ab4f912-fc25-4859-bd8d-5651e2c68e93%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Why Django is making migrations for external apps?

[Collin Anderson]

For choices, I've sometimes had my migrations import the correct choices 
from the live model in order to avoid needing to create extra migrations 
every time they change.

On Wednesday, July 15, 2015 at 7:10:39 PM UTC-4, Andrew Godwin wrote:
>
> Hi Marcin,
>
> Django persists every single field attribute change, no matter what it is 
> - this was a deliberate decision as we didn't want to declare certain 
> attributes as "not important for schema" (for example, a subclass of 
> ChoiceField might use an enum column type for the choices and so need that 
> change).
>
> That said, this is definitely a common problem and I'm starting to think 
> we should revisit it - specifically, have field classes themselves say 
> which attributes are not worth making changes for (perhaps combined with 
> greater control by fields over how their schema gets made). This isn't 
> currently possible though.
>
> Also, yes, Django doesn't see unpacked .egg files as any different than 
> anything else (they're just directories after all) - we have no way of 
> telling which apps are yours and which are external, really. This should 
> only happen if the external app already has a migrations directory, so the 
> app in question should probably try and present a consistent choices list 
> to the migration system in the meantime if you want to avoid this. There's 
> no other real fix for this right now.
>
> Andrew
>
> On Wed, Jul 15, 2015 at 5:53 PM, Marcin Nowak  > wrote:
>
>> Hi Andrew,
>>
>> I think I've found it. This reusable app uses a kind of dynamic choices 
>> (based on settings or somethin' else) and Django detetcs field definition 
>> change (choices attr).
>>
>> So the question is - should Django detect change of choices attribute 
>> even if database schema is not really altered?
>> And the original question modified - should Django generate migration 
>> file inside of an egg when runtime configuration or settings are changing?
>>
>> BR,
>> Marcin
>>
>>
>>
>> On Thursday, July 16, 2015 at 12:07:52 AM UTC+2, Andrew Godwin wrote:
>>>
>>> Hi Marcin,
>>>
>>> Django will only make migrations for external apps that already have 
>>> "migrations" directories and have model changes - it shouldn't make new 
>>> migrations unless you've actually changed the models in those reuseable 
>>> apps. Are you sure you're not specifying the names of those apps on the 
>>> makemigrations command line? Are you using something like --noinput?
>>>
>>> Andrew
>>>
>>> On Wed, Jul 15, 2015 at 3:16 PM, Marcin Nowak  
>>> wrote:
>>>
 Hello,

 I'm working on a project which is based on Django`s internal migrations.
 Sometimes when switching between branches (not sure for 100%), Django 
 complains about changes in my models.

 When `makemigrations` command is executed Django generates migrations 
 in external (reusable) app placed in egg. And this is *strange*, I think.
 I don't want to modify any external app, and I don't want to depend on 
 temporary migrations created only on my local machine.

 Why Django is creating migrations for external apps, especially placed 
 in eggs? 
 Migrations should be handled and created only for apps within the 
 project, and read-only for others. 

 What do you think?
 How I can workaround this issue?

 (Django 1.7.8)


 Best Regards,
 Marcin

 -- 
 You received this message because you are subscribed to the Google 
 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/77b46084-ffa1-43a0-ae2d-206f868cbaa5%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-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/81e00a02-95fa-451d-aa24-1e4bd592f511%40googlegroups.com
>>  
>> 
>> .
>>
>> For more options, visit ht

Re: Why Django is making migrations for external apps?

[Collin Anderson]

Ahh, yes, that's a good example of what I was thinking of:
https://github.com/pennersr/django-allauth/blob/fb2851fe333f303faab28e9633b6cf1b0ddbbe98/allauth/socialaccount/migrations/0001_initial.py#L39

On Wednesday, July 15, 2015 at 8:17:33 PM UTC-4, Marcin Nowak wrote:
>
> Please also review that case: 
> https://github.com/pennersr/django-allauth/blob/master/allauth/socialaccount/models.py#L40
>
> On Thursday, July 16, 2015 at 2:03:07 AM UTC+2, Tim Graham wrote:
>>
>> Andrew, do you think having the autodetector not "resolve" settings to 
>> their values and instead include that as references in auto-generated 
>> migrations is something we should try to implement?
>>
>> If so, let's suggest that solution on 
>> https://code.djangoproject.com/ticket/24648
>>
>> On Wednesday, July 15, 2015 at 7:58:02 PM UTC-4, Andrew Godwin wrote:
>>>
>>> Hi Marcin,
>>>
>>> Having migrations per-app is kind of a key part of the way the design 
>>> works, but as for the rest of it, you're free to just write migrations 
>>> yourself and ignore makemigrations - the format is intended to be 
>>> human-writable.
>>>
>>> We also deliberately separated the schema editing backends from the 
>>> migration code itself, so you're free to develop your own migration 
>>> solution that overrides some of the logic of how Django works without 
>>> having to re-implement all of the SQL abstraction, but I will tell you that 
>>> in my experience the solution we have now is the one that works the best 
>>> for most people (South did indeed use to have a form of semi-manual 
>>> picking).
>>>
>>> Dependencies also make things more complex - my attempts to try and 
>>> communicate interdependent changes to human in textual/graphic form were 
>>> unsuccessful, hence the current method of just doing everything for you as 
>>> best we can.
>>>
>>> As for a short-term fix, Collin's idea of importing the choices into the 
>>> migration to stop it detecting more changes sounds like a decent temporary 
>>> fix.
>>>
>>> Andrew
>>>
>>> On Wed, Jul 15, 2015 at 4:46 PM, Marcin Nowak  
>>> wrote:
>>>
 Thanks for clarification, Andrew. I understand it. 

 The real solution (for me) is not to do anything "automagically". In my 
 "dream" I see migrations whose can be "picked" manually (or semi-manually 
 via "pickmigrations ") into my project, whenever I want. No 
 autochecks, no automigration for anything, only bunch of helpers (i.e. 
 change-detector. picker). Real/valid/selected/picked migrations should be 
 "imported" as a project-wide changesets without splitting by apps (no 
 dependency problem, easier conflicts resolve), and migrations in reusable 
 apps should be provided as a resource(s) to pick/import. 

 I would like to spent some time while creating stable and solid 
 migrations in my project instead of searching workarounds for runtime 
 issues.
 But this means a big architecture change and I know that is improssible 
 to do for years...

 Thanks again.
 Marcin


 On Thursday, July 16, 2015 at 1:10:39 AM UTC+2, Andrew Godwin wrote:
>
> Hi Marcin,
>
> Django persists every single field attribute change, no matter what it 
> is - this was a deliberate decision as we didn't want to declare certain 
> attributes as "not important for schema" (for example, a subclass of 
> ChoiceField might use an enum column type for the choices and so need 
> that 
> change).
>
> That said, this is definitely a common problem and I'm starting to 
> think we should revisit it - specifically, have field classes themselves 
> say which attributes are not worth making changes for (perhaps combined 
> with greater control by fields over how their schema gets made). This 
> isn't 
> currently possible though.
>
> Also, yes, Django doesn't see unpacked .egg files as any different 
> than anything else (they're just directories after all) - we have no way 
> of 
> telling which apps are yours and which are external, really. This should 
> only happen if the external app already has a migrations directory, so 
> the 
> app in question should probably try and present a consistent choices list 
> to the migration system in the meantime if you want to avoid this. 
> There's 
> no other real fix for this right now.
>
> Andrew
>
> On Wed, Jul 15, 2015 at 5:53 PM, Marcin Nowak  
> wrote:
>
>> Hi Andrew,
>>
>> I think I've found it. This reusable app uses a kind of dynamic 
>> choices (based on settings or somethin' else) and Django detetcs field 
>> definition change (choices attr).
>>
>> So the question is - should Django detect change of choices attribute 
>> even if database schema is not really altered?
>> And the original question modified - should Django generate migration 
>> file inside of an egg when runtime config

Re: A modest proposal - more blocks in admin templates

[Collin Anderson]

The documentation could give better backwards compatibility guarantees.

On Friday, July 24, 2015, Tim Graham  wrote:

> There is at least one ticket about adding more blocks to the admin
> templates: https://code.djangoproject.com/ticket/14810
>
> You can browse the "contrib.admin" component in Trac to find related
> issues:
> https://code.djangoproject.com/query?status=assigned&status=new&component=contrib.admin&stage=Accepted&page=2&col=id&col=summary&col=status&col=owner&col=type&col=version&desc=1&order=id
>
> I am not sure how much value documentation would be as it seems if you are
> overriding the template, you will probably need to look at the whole thing
> anyway.
>
> On Friday, July 24, 2015 at 5:35:28 AM UTC-4, Andy Baker wrote:
>>
>> Happy to do some work on this but wanted to get some feedback first.
>>
>> Loose methodology:
>>
>> 1. Skim the most popular admin extensions that exist on django-packages
>> etc
>> 2. Look out for places where they've had to copy entire admin templates
>> to only override a small part
>> 3. Add new {% blocks%}  into the original templates where there appears
>> to be a demonstrable need.
>>
>> Additionally - would there be some value in a new page in the docs
>> listing admin templates and their respective blocks?
>>
>  --
> You received this message because you are subscribed to the Google Groups
> "Django developers (Contributions to 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/2ecc568c-0aa9-4a67-af31-f8c877699c92%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/CAFO84S5BYL%3DCQLB876zwMkqQvk35RHTOzNczf_A7grSgBsmUGQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: @staff_member_required handling of non-staff users

[Collin Anderson]

I like the behavior of showing the login screen if they don't have 
permission. It's simple and pretty friendly. The new hint is helpful too.

On Tuesday, July 28, 2015 at 4:16:58 PM UTC-4, Carl Meyer wrote:
>
> On 07/28/2015 12:36 PM, Tim Graham wrote: 
> > We received a ticket [1] noting that when a non-staff user tries to 
> > access an admin page, they will be redirected to the admin login page 
> > with no explanation. A pull request [2] proposes to add this message to 
> > login page if a user is authenticated, "While you are authenticated as 
> > {{ username }}, you are unfortunately not authorized to access this page 
> > -- would you care to re-login?" -- the thinking being that any 
> > authenticated user viewing the login page will have reached it via such 
> > a redirect. (Logged in staff users cannot view the login page because 
> > they are redirected back to the admin index page if they try to access 
> it). 
>
> This solution seems reasonable to me. 
>
> > I think it's a bit odd for the @staff_member_required to redirect 
> > non-staff users to the login page (which is a side effect of using the 
> > user_passes_test() function) as if many users have two separate "staff" 
> > and "non-staff" accounts. 
>
> I think that probably varies quite a bit by project. There are certainly 
> projects (especially on staging sites where a lot of testing occurs that 
> sometimes requires multiple accounts) where I do have multiple accounts, 
> one staff and others not, and I've used the re-login ability. 
>
> > Instead I propose to raise PermissionDenied so 
> > that developers can use handler403 to customize the behavior. 
>
> I guess this should be somewhat practical now that we have 
>
> https://github.com/django/django/commit/70779d9c1cab77791c73b72e8a63f60184d8f2b0
>  
> -- without that it would be hard to distinguish one type of 403 from 
> another. 
>
> It feels a bit ugly to me in the cases where you want to return 
> something other than a 403 (e.g. the 302 that is returned currently) 
> that you'd have to do that via `handler403`. And you'd still have the 
> `got_request_exception` signal sent, even though you are choosing to 
> handle it in a non-exceptional fashion. 
>
> > What are your thoughts on this issue? 
>
> I think the proposed PR for a UX hint is a good improvement on the 
> status quo, regardless. 
>
> In theory I like the idea of being able to customize what happens when a 
> `staff_member_required` check fails. For that matter, I'd like it if 
> `user_passes_test` itself were more customizable, so it could be 
> configured to return either a redirect, a 403, or a 404. 
>
> I am not convinced that `handler403` is the right place to do this 
> customization. To me that seems like the place to customize your 403 
> responses, not to make policy decisions that may result in returning 
> something that isn't a 403 at all. 
>
> The obvious place for this type of customization to happen is in an 
> optional parameter to `@staff_member_required`. The problem in the admin 
> is that the decorator is applied internally, not by the developer. 
> Perhaps an `AdminSite` attribute? 
>
> Carl 
>
> > [1] https://code.djangoproject.com/ticket/25163 
> > [2] https://github.com/django/django/pull/5044 
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to 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/84d74c82-3328-478f-8210-c5be481a5be8%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: future of QuerySet.extra()?

[Collin Anderson]

I wonder if there's a way in the docs we can deprecate it as in "we don't 
recommend you use it", but not actually schedule it for removal.

On Friday, July 31, 2015 at 2:01:20 PM UTC-4, Marc Tamlyn wrote:
>
> I don't know about unmaintained, but I think there's a consensus that 
> .extra() has a horrible API and we should do away with it eventually. That 
> said I think there are still enough things that can't be done without it at 
> present. A lot fewer now we have expressions, but still some.
>
> I'd be happy to put a moratorium on improving it, but we can't deprecate 
> it yet.
>
> On 31 July 2015 at 18:58, Tim Graham > 
> wrote:
>
>> In light of the new expressions API, the idea of deprecating 
>> QuerySet.extra() has been informally discussed in IRC and elsewhere. I 
>> wonder if there is consensus to mark extra() as "unmaintained" and to 
>> suggest filing feature requests for functionality that can be performed 
>> through extra() but not through other existing QuerySet methods? There are 
>> at least several tickets (examples below) of edge cases that don't work 
>> with extra(). It seems like a waste of time to leave these tickets as 
>> accepted and to triage new issues with extra() if they won't be fixed.
>>
>> https://code.djangoproject.com/ticket/24142
>> https://code.djangoproject.com/ticket/19434
>> https://code.djangoproject.com/ticket/12890
>>
>> -- 
>> You received this message because you are subscribed to the Google 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/6e1be326-3b17-49ca-accf-03eec5ad41ef%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/3d575638-a365-4257-8f46-dcf65a69c03c%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Field.get_flatchoices seems to never get used

[Collin Anderson]

That looks right to me.

On Sun, Aug 2, 2015 at 11:51 AM, Andy Baker  wrote:

> I'll file a ticket but I wanted a quick sanity check first.
>
> In db.models.fields.Field there is a method called get_flatchoices (as
> well as _get_flatchoices which is turned into a property).
>
> I've searched the source for 'get_flatchoices' and it's never called.
> There doesn't appear to be any mention of it except in a few ancient
> tickets.
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django developers (Contributions to 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/6ba31eda-8f84-490a-8dce-0448452c9510%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/CAFO84S7z%3DkXwpKTritdBt9gQPSYXpr_MktMBU-jkdBVV%3D3sZ2g%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Ticket #25236: Remove ifequal from the template language

[Collin Anderson]

Hi All,

I really like the "don't use this on new code, but there's no rush in 
replacing it" category. I think that's really important to have that in a 
project that's this old. I think it would be great to minimize the amount 
required changes that need to be done.

Thanks,
Collin

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to 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/2ddf20f1-af1a-47c1-b07c-669818846b53%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Future of the development server's auto-reloading

[Collin Anderson]

This all makes sense to me, but it would be nice if it worked out of the 
box, especially for the purposes of the tutorial. :)

On Saturday, August 8, 2015 at 5:53:32 PM UTC-4, Aymeric Augustin wrote:
>
> Hello,
>
> While writing some horrific code [1] related to the development server’s 
> auto-reloading, I realized that its design is fundamentally flawed and I 
> think that we should reconsider it.
>
> The current implementation walks through the list of all imported Python 
> modules, attempts to figure out which file they come from and builds a list 
> of these files. Then it watches all these files for changes by checking if 
> their mtime changed every second or, since 1.7, with inotify on Linux. I 
> tried to do it with kqueue on BSD (read: OS X) but I failed. This stuff is 
> hard.
>
> In addition to the source of imported Python modules, the autoreloader 
> watches .mo files in order to catch translation changes and source files 
> for modules that failed to import — it extracts them from exception 
> tracebacks. This shows the limits of basing the list on imported Python 
> modules. Even with such hacks, the auto-reloader will never handle all 
> cases. Two examples:
>
> - It doesn’t survive a syntax error in the settings module. I have reasons 
> to believe that this would be extremely messy to fix.
> - If a module reads a configuration file on disk at startup and caches it, 
> the auto-reloader doesn’t detect changes to that file.
>
> So we’re stuck with cases where the development server doesn’t reload. I 
> can’t say they’re edge cases; who never made a typo in a settings file? 
> People who run tutorials report that it’s a very common cause of 
> frustration for beginners.
>
> It's also wasteful. There’s little need to watch every file of every 
> dependency in the virtualenv for changes.
>
> I think it would be much better to remove the auto-reloading logic from 
> Django and have an external process watch the current working directory for 
> changes. (When virtualenv is considered appropriate for people with exactly 
> 0 days of Django experience under their belt, I think we can require a 
> dependency for the development server’s auto-reloading.)
>
> The behavior would be much easier to describe: if you change something in 
> your source tree, it reloads automatically; if you change something 
> somewhere else, you must reload manually. It would also be quite easy to 
> customize with a standard include / exclude mechanism to select which files 
> should be watched.
>
> We aren’t in the business of writing production web servers, neither are 
> we in the business of writing a filesystem watcher :-) Watchman [2] appears 
> to be a robust solution. However I would prefer a pure-Python 
> implementation that could easily be installed in a virtualenv. Does someone 
> have experience in this area?
>
> I’m not making a concrete proposal as I haven’t studied the details. It 
> this point I’d just like to hear what you think of the general concept.
>
> Thanks!
>
> -- 
> Aymeric.
>
> [1] https://github.com/django/django/pull/5106
> [2] https://github.com/facebook/watchman
> [3] 
> http://tutorial.djangogirls.org/en/django_installation/index.html#virtual-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 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/d6a28f53-2327-4c03-9d85-f57209fd24d5%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Django ORM query syntax enhancement

[Collin Anderson]

Just a quick thought: I could imagine some newbies could get confused by 
the python-like syntax and try to do:

Equal(P.user.get_full_name(), 'Bob Someone')

I don't think it's not a huge deal, but worth noting.

On Tuesday, August 18, 2015 at 8:00:17 AM UTC-4, Alexey Zankevich wrote:
>
> Hi all,
>
> Thanks for detailed response. I thought over the described expressions/
> transforms patches and here are my thoughts about the best way to
> implement simplified lookups.
>
> Firstly, I want to describe which properties of the new syntax seem to be
> important:
>
> 1. Using Python operators to do basic lookups as it's a natural way in 
> Python
> for that.
>
> 2. Syntax should be minimalistic for basic lookups, the use of that 
> approach
> will be more noticeable on multiple filter conditions. In other words, next
> syntax is better:
>
> >>> GameSession.objects.filter(Q.user.profile.last_login.date() == 
> datetime.now().date)
>
> than this one
>
> >>> GameSession.objects.filter(E(F.user.profile.last_login).date() == 
> datetime.now().date)
>
> as it requires additional calls, which makes expressions less readable.
>
> 3. I definitely like the idea of having explicit classes for lookups and
> transforms and think it's worth to bundle dotted query syntax with the 
> patch.
> Explicit classes will separate functionality and simplify functions 
> signature
> checks.
>
> I suggest a mixed approach, with next properties.
>
> 1. We will have a separate class to define query paths (let's call it P, we
> can still use F as "field", but having F as multipurpose class may confuse
> users, as well as implementation may become more complicated). And it will 
> be
> the only purpose of the class. Below I'll reference it as "P" no matter we 
> call
> it in future.
>
> 2. Any transforms and lookups will take query string or P class, as well as
> existing methods "select_related", "prefetch_related" and "order_by". The
> simplest implementation will be overriding __str__ method of the path class
> to generate related strings.
>
> >>> path = P.user.last_login_date
> >>> GameSession.objects.all().order_by(path)[:10]
>
> >>> print(path)
> user__last_login_date
>
> 3. Implement transforms and lookups as classes or functions (not bound to 
> P class):
>
> >>> GameSession.objects.filter(Unaccent(P.user.location.name) == "Cote 
> d'Ivoire")
>
> It will simplify cases with parametrized transforms (ex. mentioned 
> collate('fi')).
> Also eliminate fields collision with util functions like "date", which may 
> be a
> so-called field.
>
> 4. Below is a table describing accepted passed and returned parameters:
>
> +---+---+--+
> |  Class/Function   |Allowed Param Types| Comparison Operators |
> +---+---+--+
> | Transform | str, P, Transform, Lookup | Return lookup|
> | Lookup| str, P, Transform | Raise exception  |
> | P |   | Return lookup|
> | .order_by | str, P|  |
> | .select_related   | str, P|  |
> | .prefetch_related | str, P, Prefetch  |  |
> +---+---+--+
>
>
> Samples:
>
> >>> P.user.name == 'Bob'
> Equal('user__name', 'Bob')
>
> >>> Unaccent(P.user.name)
> Unaccent('user__name')
>
> >>> Collate(P.user.name, 'fi')
> Collate('user__name', 'fi')
>
> >>> Unaccent(P.user.name) == 'Bob'
> Equal(Unaccent('user__name'), 'Bob')
>
> >>> Equal(P.user.name, 'Bob') == 'Bob'
> Traceback (most recent call last):
>   File "", line 1, in 
> Exception: Lookups comparison is not allowed
>
> >>> Contains(P.user.name, 'Bo')  # lookup
> >>> Date(P.user.last_login_date, datetime.now().date)  # transform
>
>
> Questions to discuss and possible pitfalls:
>
> 1. Handling descended ordering in order_by
>
> >>> path = P.user.last_login_date
> >>> -path
> '-user__last_login_date'
>
> or even
>
> >>> -p
> NegP('user__last_login_date')
>
> Is it possible path subtraction is required in future by any reason? In 
> that
> case the given approach will be inconvenient. Or may be better to just let
> users to format desc ordering themselves?
>
> >>> '-{}'.format(path)
>
> 2. Don't think it's a big deal, but users might do next thing:
>
> >>> path = P.user.last_login_date
> >>> GameSession.objects.filter(path=today)
> Traceback (most recent call last):
>   File "", line 1, in 
> FieldError: Cannot resolve keyword 'path' into field.
>
> At least need to mention it in documentation
>
> 3. Classes vs factory functions:
>
> >>> Equal(P.user.name, 'Bob')
> Equal('user__name', 'Bob')
>
> vs
>
> >>> equal(P.user.name, 'Bob')
> Equal('user__name', 'Bob')
>
>
> If you are fine with described syntax I can start with DEP.
>
> Regards,
> Alexey
>
> On Monday, August 17, 2015 at 12:26:45 P

Re: Django Admin New Look

[Collin Anderson]

To be clear: jQuery 1.x and 2.x are the exact same except for IE < 9 
compatibility. jQuery v1.11.3 and v2.1.4, released simultaneously, _are_ 
the latest version of jQuery. It's not like "1.11.x" is an "old" release 
series. 1.x and 2.x have the exact same features and API and are 100% 
compatible with each other. The _only_ difference is that v2.1.4 is 
slightly smaller because it doesn't have shims to support IE6-8 (and a few 
other old browsers).

The only advantage to switching to 2.x is a slightly smaller file size, 
meaning a slightly quicker load time.

In a few months, they'll switch to 3.x, breaking some backwards 
compatibility, and instead of 2.x and 1.x, they'll have "jQuery" and 
"jQuery Compat" with the same version numbers. That should make this more 
clear.
http://blog.jquery.com/2015/07/13/jquery-3-0-and-jquery-compat-3-0-alpha-versions-released/

I personally suggest staying with jQuery Compat (1.x) through this next LTS 
cycle. The file size is really not that much, and it shouldn't be any extra 
work to maintain.
https://mathiasbynens.be/demo/jquery-size

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to 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/84b76673-7d30-4758-9537-9144c045bb2a%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: templates block prepend and append

[Collin Anderson]

Hi Jun,

I think this might do what you want:

{% block js %}{{ block.super }}  {% endblock %}

But, like the original poster said, please use django-users list for things
like this.

Thanks,
Collin


On Mon, Aug 24, 2015 at 2:25 AM, Amin Jun 
wrote:

> I liked his suggestion, I don't know if I'm using template tags correctly,
> but I'm writing a template tag {% load_comment comment_manager %} ,
> "load_comment" renders a file "comments.html" and also needs a file
> "comment.js" and in any page that has comments, I have to add "comment.js"
> manually to my {% block js %}.
> it was better if i could put something like this in my "comments.html"
> file
>
> {% append_block js %}
> < script src="..." >
> {% end_append_block %}
>
> Best regards
>
> Jun
>
> On Friday, May 20, 2011 at 9:20:22 PM UTC+4:30, Matt wrote:
>>
>> This should solve my problems, therefore my question is no longer valid.
>>
>> I missed that in the documentation.
>>
>> Probably I should ask at django-users first.
>>
>> Although
>>
>> {% extends "admin/index.html" after "blockname" %}
>>
>> would be a nice shorthand.
>>
>> or
>>
>> {% from "admin/index.html" import "blockname" %}
>>
>> to import only one block from a template file.
>>
>> --
>> Matt Harasymczuk
>> http://www.matt.harasymczuk.pl
>>
> --
> You received this message because you are subscribed to the Google Groups
> "Django developers (Contributions to 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/3e77b96d-c187-406a-8d08-140958dac251%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/CAFO84S4TiAeuvdiJyTFK9Cz8h%2B98L68fVnWEjdk912zLymqqWQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

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

[Collin Anderson]

I propose adding a check on UserCreationForm (used by the admin). The
current implementation relies on the model fields unique=True check which
is case-sensitive (except on mysql).

Whenever I've made a login form, I've always used or made a copy of or at
least studied UserCreationForm. I think if we had a nice walk through of
how to create your own form which included the iexact hint, I think that
would also help solve this problem.

On Sun, Aug 30, 2015 at 6:43 AM, Florian Apolloner 
wrote:

>
>
> On Saturday, August 29, 2015 at 9:59:30 PM UTC+2, Tim Graham wrote:
>>
>> The suggested change is to not allow a new user if there's a
>> username__iexact match.
>>
>
> Yes, but as change to what? To the admin interface? this will only cover
> admin usage. To a full_clean of the user model [This is often not used
> anyways]? I am somewhat against that…
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django developers (Contributions to 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/650405a3-c860-4d84-be94-5b6a6c779aa2%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/CAFO84S6yF4dyY8ZiLwDu5D_0ffT6Qe%3D1NoRMwD1GccsNtPc4qw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Django Admin New Look

[Collin Anderson]

That looks right to me. More specifically (from the attic/magic-removal
branch):
Added css and some of those html classes:
https://github.com/django/django/commit/84b7590ba6e566186bba975e57b0686dd53927ca
Removed html classes, but not css:
https://github.com/django/django/commit/738d9af1e8e38b0289b7dfa7c8a5413f5d0e20d1

On Fri, Sep 4, 2015 at 5:35 AM, elky  wrote:

> Does anybody know where this CSS code (
> https://github.com/elky/django/commit/36c1decd2f18c3af947546ea3b8eaeaecd2762ba)
> uses? I didn't find any mention of these CSS classes in the project.
>
> The first mention of these styles came from this 9 years old commit -
> https://github.com/django/django/commit/f69cf70ed813a8cd7e1f963a14ae39103e8d5265
> I did checkout to this state and didn't find any mention of these classes
> in backend or JS. So I think this code is really unused. Correct me if I'm
> 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/59b2377d-bc7f-4465-9588-2641746ac466%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/CAFO84S7mh39QHe6__aF-c1_J8rBLaMa-RNibzENzLjJOyUM2Mw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Methodology for increasing the number of PBKDF2 iterations

[Collin Anderson]

Is there an external library for Python < 2.7.8? I know we don't officially
support the system version of python in RHEL/CentOS and Ubuntu, but I bet
we could get away with requiring a dependency for those old versions of
Python in new versions of Django.

On Mon, Sep 21, 2015 at 10:30 AM, Tim Graham  wrote:

> Django 1.8 is the last version to support Python 3.2 and 3.3, so I believe
> we could assume Python 2.7.8+ and 3.4+ as of Django 1.9. While we only
> *officially* support the latest release of each Python series, explicitly
> dropping support for < Python 2.7.8 might not be acceptable, however, it
> seems like it would resolve the asymmetry and allow us to more aggressively
> increase the number of iterations?
>
> On Sunday, September 20, 2015 at 7:30:11 PM UTC-4, Donald Stufft wrote:
>>
>> On September 20, 2015 at 7:26:09 PM, Alex Gaynor (alex@gmail.com)
>> wrote:
>> > > Unfortunately 24k iterations is behind where we'd want to be
>> > (~100k iterations, or a factor of 4, last I checked).
>>
>> If I remember, a key thing was we wanted the PBKDF2 iterations to be much
>> higher than they were because they hadn't kept up with improvements (or
>> adjusted at all at) but we didn't want to just jump from some low amount
>> (20k?)
>> straight to 100k in one release. The 25% number was, if I recall, an
>> attempt
>> to move us to that point over time, so it was purposely chosen to be
>> faster
>> than CPU increases because if it was equal to that we'd never catch up to
>> where
>> we should be.
>>
>> -
>> Donald Stufft
>> PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372
>> DCFA
>>
>>
>> --
> You received this message because you are subscribed to the Google Groups
> "Django developers (Contributions to 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/1bddac0d-7c3d-4c3f-aeae-d954a19496a8%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/CAFO84S7NcnAkRurHJdOpQz8iXLgciqrZyTjMe2MqLN_%3DpNa%2BFA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Making max_length argument optional

[Collin Anderson]

If anyone's curious, the mysql situation is as crazy as you might expect. :)

The max is only determined only by the total row size (65,535 bytes) and
the index size (767 bytes default).

Mysql defaults to only allowing 3-byte (no emoji) unicode characters, so
65,535/3=21,845 max across the entire row (the sum of all of the maxes of
all char/varchar columns), and each indexed field only gets 767/3=255
characters by default.

If you change to 4-byte unicode characters, (which you should, but django
doesn't really help you out #18392), your max_lengths can add up to
65,535/4=16,383 characters, and if you want the field to be indexed, you
only get 191 characters (using the default index size). It's possible to
only index the first 767/4=191 characters of the field, but django doesn't
really support that.

Basically, 255 works pretty well by default, allowing 65,535/3/255=85
3-byte fields per row, and indexes just work if you stick to the default
settings.

https://dev.mysql.com/doc/refman/5.0/en/char.html
https://code.djangoproject.com/ticket/18392


On Tue, Sep 22, 2015 at 1:56 AM, Aymeric Augustin <
aymeric.augus...@polytechnique.org> wrote:

> Hi Shai,
>
> On 22 sept. 2015, at 04:22, Shai Berger  wrote:
>
> > I'd solve the "need to specify" issue by setting a default that is
> > intentionally smaller than the smallest (core) backend limitation, say
> 128.
>
> I would pick the highest value supported by all core backends (probably 255
> for MySQL, unless there’s something about indexes and multi-byte encodings
> that I forget) in order to minimize the need to increase it.
>
> If we go for a lower value, I suggest to pick something totally arbitrary
> like
> 100 to make it clear that it isn't a technical limitation.
>
> > I"d make an "unlimited length text field" a new type of field,
> explicitly not
> > supported on MySql and Oracle; and I'd suggest that it can live outside
> core
> > for a while. so we may get an impression of how popular it really is.
>
> The main use case seems to be “VARCHAR() on PostgreSQL”. What about
> defining a
> slight variant of CharField in django.contrib.postgres that merely makes
> the
> max_length argument default to None?
>
> --
> 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/17C37814-E6A8-4E27-B590-BF9FFF42CB20%40polytechnique.org
> .
> For more options, visit https://groups.google.com/d/optout.
>

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

Re: moving the class-based View base class out of django.views.generic?

[Collin Anderson]

Could we have permanent backward-compatible (no deprecation timeline)
shims? I'm -0 if not because it's yet-another thing that everyone needs to
change when upgrading.

On Tue, Sep 22, 2015 at 11:23 AM, Marc Tamlyn  wrote:

> The idea has been discussed before and was rejected as needless code churn
> if I remember correctly. I'm afraid I can't remember when or where this
> discussion happened, it could have been an in person one at a sprint, I
> can't immediately find a record on this mailing list. Perhaps the fact it's
> come up again makes it more significant (and we can always keep the import
> shim).
>
> FWIW, I am +0, I can see the reasoning but in my opinion we have worse
> import paths (conf.urls and core.urlresolvers anyone?)
>
>
>
> On 22 September 2015 at 15:58, Tom Christie 
> wrote:
>
>> Yup, I think that's a good proposal.
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "Django developers (Contributions to 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/61cbcc8c-08d9-42af-83d5-4a8ee3d79dac%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/CAMwjO1ERvJxM1Zj%3DpOJRTX4zY3dqWg_PBYQ-5vQCPCuP-9i8iw%40mail.gmail.com
> 
> .
>
> For more options, visit https://groups.google.com/d/optout.
>

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

Re: simplifying the install page

[Collin Anderson]

Yeah, I bet we could get rid of the entire "Installing an official
release manually" section, as I assume we don't actually want to
recommend that. Also, the "Installing the development version" section
outlines a more manual way already.

It makes sense to me to tell people to "install virtualenv" rather
than to "install pip".

We could might want to link to virtualenv's instructions for
installing itself. They show a way of downloading and using virtualenv
without root, which some beginners (I'm thinking college students)
might not have.
https://virtualenv.pypa.io/en/latest/installation.html

It's worth noting too, that although newer versions of python include
pip and venv, some distros have decided not to install pip and venv by
default.

On Fri, Sep 25, 2015 at 1:07 PM, Daniele Procida  wrote:
> On Fri, Sep 25, 2015, Tim Graham  wrote:
>
>>The install page mentions several different ways to install Django, from
>>pip install (recommended), to `setup.py install`, to symlinking the Django
>>checkout in your site-packages. Do you see any reason to keep the latter
>>methods instead of recommending pip all the time?
>>
>>https://docs.djangoproject.com/en/1.8/topics/install/
>
> I can't see any good reason to keep symlink method, but maybe I am missing 
> something.
>
> I'd prefer to see the use of virtualenv built-in to the process from the very 
> start, and a quickstart version of the instructions as the first thing that 
> people see:
>
> virtualenv django-virtualenv
> source django-virtualenv/bin/activate
> pip install django
>
> I know that's not so simple, and that Windows users need to do something a 
> bit different, but at least seeing something that simple near the top of the 
> document would be a promise that installation *can* be that easy.
>
> Daniele
>
> --
> You received this message because you are subscribed to the Google Groups 
> "Django developers  (Contributions to 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/20150925170726.2021833171%40mail.wservices.ch.
> 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/CAFO84S7ejDMLkkNZvX0j9ubLPStuVP%3D%3DiWNajb6f78P5e-ANow%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Static type checking for public API

[Collin Anderson]

Hi John,

I think we need to wait until we drop Python 2.x support to be able to do 
this, as 2.x won't accept this syntax. Does that sound right?

Thanks,
Collin

On Sunday, October 11, 2015 at 9:22:17 AM UTC-4, John Michael Lafayette 
wrote:
>
>  Python now has static type checking. All you do is follow function 
> parameters with ": paramType" and add "-> returnType" before the colon at 
> the end of the function declaration and auto-complete will work on the 
> return value in IntelliJ. Can you add the function parameter types and 
> return types to all the functions in the public API? 
>
> > So like change this... 
> > def func(param): 
> > 
> > To this... 
> > def func(param: int) -> str: 
>
> That way when I call a function, the static type checker will make sure I 
> pass in the right type.

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to 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/81f6b5a2-14a2-4a7a-82c4-74d3016ff59f%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: #25582: Add a way to build URLs with query strings

[Collin Anderson]

If it helps, I have a similar need in the template. My case requires 
adding, removing, or replacing one of the arguments on the fly:

In templates, I often need to change _one_ key of a GET request on the fly. 
My use case is a "filter by" sidebar on the same page as a "sort by" and 
"number per page". (Example: http://comcenter.com/category/BC020/ ).

I currently use a simple custom template tag:
@register.simple_tag
def make_query(params, key=None, value=None):
from django.utils.http import urlencode
if key:
params = params.copy()
if value:
params[key] = value
else:
params.pop(key, None)
return '?' + urlencode(params, True) if params else '.'

For previous/next pages, I simply use:


For more complicated things, in the view I collect all of the valid params 
and pass them to the template. (I don't keep the "page" key in "params", 
because I want that to reset when filtering or sorting.)



I can remove keys like so:
Show All

On Friday, October 23, 2015 at 3:41:42 AM UTC-4, guettli wrote:
>
> From  https://code.djangoproject.com/ticket/25582
>
>  {{{
>
> It is a common question on stackoverflow and other places:
>
> How to reverse() to url including GET parameters? Example: 
> .../myview?foo=bar
>
> ​
> http://stackoverflow.com/questions/9585491/how-do-i-pass-get-parameters-using-django-urlresolvers-reverse
>
> ​http://stackoverflow.com/a/27641445/633961
>
> It would be very nice if django could implement a short-cut which provides
> this.
> It would be useful for python code and template, too.
> }}}
>
> {{{
> If we do add it, it likely needs a discussion on the DevelopersMailingList 
>  to figure out 
> what the API should look like. See also #10941 
>  which asks for a template 
> tag for creating query strings in templates.
> }}}
>
> 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/8aa2a092-8fee-43b1-ac9a-ab628b35e90c%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

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

[Collin Anderson]

I also agree. And to be clear, we're talking about UserCreationForm, right? 
Or where specifically would we implement this? (What part of Django do you 
use that doesn't check this?)

On Monday, October 26, 2015 at 2:04:24 PM UTC-4, bliy...@rentlytics.com 
wrote:
>
> > -1 on changing the check of usernames at login to case-insensitive
> > +1 with preventing the creation of new usernames
>
> Ditto
>
> On Thursday, October 22, 2015 at 9:33:02 AM UTC-7, mtnpaul wrote:
>>
>> Yeah, I was referring to the post by Daniel at the start of the thread, 
>> not Reid's comment.
>>
>> I would be -1 on changing the check of usernames at login to 
>> case-insensitive. But I would be +1 with preventing the creation of new 
>> usernames which would match existing usernames in a case-insensitive manner.
>>
>> On Wed, Oct 21, 2015 at 3:39 PM, Shai Berger  wrote:
>>
>>> Hi,
>>>
>>> On Thursday 22 October 2015 00:01:24 Paul Egges wrote:
>>> > Perhaps I'm missing something, but this would not change current users,
>>> > only the creation of new users. It seems that logins would still be 
>>> case
>>> > sensitive.
>>>
>>> Not the way Reid presented it:
>>>
>>> > > Le mercredi 21 octobre 2015 15:44:55 UTC-4, Reid Ransom a écrit :
>>> > >> Is it reasonable to consider changing the default for usernames to 
>>> be
>>> > >> case-insensitive in 2.0?
>>>
>>> I think, though, it would be easy enough for us to provide a new, case-
>>> insensitive base class for users, and change the recommendations in our
>>> documentation to tell users to inherit that rather than the current
>>> AbstractBaseUser and AbstractUser. We could also write a simple 
>>> management
>>> command to validate lower-case uniquness and turn all usernames to 
>>> lowercase,
>>> as preparation for changing the login and registration logic.
>>>
>>> These could all be done outside of core, and perhaps they should be -- 
>>> the
>>> only point I see for including them in core is the risk that, as a 
>>> developer,
>>> if core doesn't make you think about it from the get-go, by the time you
>>> decide to make the change you may be stuck with conflicting (lower-case 
>>> equal)
>>> usernames in your database. But frankly, I would guess that this problem 
>>> does
>>> not really occur very often; that for most sites, if they decide to 
>>> switch to
>>> case-insensitive usernames, there would be no problem.
>>>
>>> Regretfully, we can't just switch Django to do that, because of the few 
>>> sites
>>> who will have a problem, and no clear upgrade path.
>>>
>>> Shai.
>>>
>>
>>

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

Re: Provide a way to pass kwargs when initializing the storage class

[Collin Anderson]

Ooooh. I think I like it. The syntax could be a bit confusing, but I think 
I like it. :)

On Saturday, November 7, 2015 at 12:16:05 PM UTC+1, Aymeric Augustin wrote:
>
> Hello,
>
> Currently the DEFAULT_FILE_STORAGE and STATICFILES_STORAGE settings 
> contain a dotted Python path to the storage class. The class is 
> instantiated without any arguments.
>
>
> ** Problem **
>
> This leads to three annoyances.
>
> 1) Third-party libraries like django-storages(-redux) need to provide a 
> setting for every value that could be required to configure the storage. 
> This additional level of indirection is annoying.
>
> If you’re skeptical, look at 
> https://github.com/jschneier/django-storages/blob/f2880b16b57a36b241a54932255e1a852c0e0ac7/storages/backends/s3boto.py#L204
> .
>
> 2) Compounding this problem, third-party libraries that want to use a 
> Django storage backend, but likely not the default one, have no convenient 
> way for the user to configure the storage.
>
> Having settings such as `MY_THIRD_PARTY_APP__AWS_ACCESS_KEY_ID` etc. for 
> every possible storage-related setting sounds unreasonable.
>
> (This is the problem I’m facing right now with one of my libraries.)
>
> 3) The standard pattern for working around these problems is 
> boilerplate-ish:
>
> my_config = {foo: bar}
>
> class ConfiguredStorageClass(GenericStorageClass):
> def __init__(self, *args, **kwargs):
> kwargs.update(my_config)
> super().__init__(*args, **kwargs)
>
> DEFAULT_FILE_STORAGE = 'path.to.ConfiguredStorageClass'
>
>
> ** Proposed solution **
>
> To solve this problem, I would like the DEFAULT_FILE_STORAGE and 
> STATICFILES_STORAGE settings to accept an additional format: a 2-uple of 
> (dotted Python path to class, init_kwargs).
>
> This would allow simplifying the example above to:
>
> DEFAULT_FILE_STORAGE = ‘path.to.GenericStorageClass’, {foo: bar}
>
>
> ** Variants **
>
> We could go a bit further support 2-uples with args, 2-uples with kwargs, 
> and 3-uples with args and kwargs. I didn’t propose it because I’m not sure 
> this possibility adds much value. Arguments can be passed as kwargs even if 
> the init method expects them positionally.
>
> We could support setting DEFAULT_FILE_STORAGE and STATICFILES_STORAGE to 
> an already initialized instance of a storage class. I’m against this idea 
> because settings should remain primitive Python values whenever possible.
>
> We could introduce DEFAULT_FILE_STORAGE_INIT_KWARGS and 
> STATICFILES_STORAGE_INIT_KWARGS. Well. Perhaps not :-)
>
>
> What do you think?
>
> -- 
> 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/1925ceb5-9855-4eba-944b-3841ad11fb56%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: startproject values for STATICFILES_DIRS and TEMPLATES

[Collin Anderson]

I wouldn't mind having these in the project template. They're already the 
example values in the docs. It could make it slightly easier for beginners.

STATICFILES_DIRS = [os.path.join(BASE_DIR, 'static')]

TEMPLATES = [
{
'BACKEND': 'django.template.backends.django.DjangoTemplates',
'DIRS': [os.path.join(BASE_DIR, 'templates')],
'APP_DIRS': True,
}
]


On Saturday, 7 November 2015 22:16:26 UTC-5, René Fleschenberg wrote:
>
> Hi, 
>
> It is quite common to configure TEMPLATES and STATICFILES_DIRS such that 
> you 
> can override the templates and static files of installed apps from some 
> central location. 
>
> Maybe startproject should actually generate settings to do this by 
> default? 
>
> STATICFILES_DIRS = ( 
> os.path.join(BASE_DIR, 'static'), 
> ) 
>
> Or maybe: 
>
> STATICFILES_DIRS = ( 
> os.path.join(BASE_DIR, 'mysite', 'static'), 
> ) 
>
> In my experience, this is a real pain point for beginners, and doing this 
> shouldn't hurt anyone. What do you think? 
>
> Also, do you think that templates and static files should be treated 
> differently in this regard? The docs currently suggest such a 
> configuration 
> for static files, but not for templates. I'd argue that it's more 
> important 
> for templates, but it cannot harm to do it for both. 
>
> -- 
> René Fleschenberg 
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to 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/afa6d398-394e-4995-8b07-1c2f98f779d5%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Support `manage.py shell -c 'run_code_as_django()'`?

[Collin Anderson]

I would use this feature. It would be nice for calling a simple function.

Though if we didn't add the feature it would be nice to document the text 
piping option.

The one downside of the piping is you get a little bit of garbage in the 
output, especially when iPython is installed.

On Tuesday, 10 November 2015 00:09:27 UTC-5, Zach Borboa wrote:
>
> I've used
>
> cat script.py | python manage.py shell
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to 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/00c51a06-5487-4e24-9fdd-039476c54493%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Proposal: add new template tag "age"

[Collin Anderson]

Also, doing this from the backend seems like sub-par way to do it. I would 
recommend implementing this in javascript, so it can auto-update over time 
if you leave the window open.

On Tuesday, 10 November 2015 14:57:57 UTC-5, jamie wrote:
>
> On Tue, 2015-11-10 at 18:50 +, Marc Tamlyn wrote: 
>
> > Agreed, this does not belong on core. In particular the formatting of 
> > a duration varies widely depending on the expected age range, 
> > languages and site context. Naturaltime is one implementation, the 
> > specific case you seem to be hinting at is a count of years, which is 
> > definitely too particular for Django inclusion. would make a perfect 
> > third party app though! 
>
> Further, age (for people, at least) is measured in different ways 
> around the world. See for example https://en.wikipedia.org/wiki/East_As 
> ian_age_reckoning 
>
> Jamie 
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to 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/8b553520-4836-4c05-a514-0155afd119ac%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Feature proposal: Target API version

[Collin Anderson]

Hi,

"It would also make it theoretically possible for the latest stable version 
to support the 
last LTS version from the same code tree".

Have you seen the latest changes to the deprecation policy? We hope we've 
done exactly that (having the latest version of Django support code that 
was written for the last LTS.)
https://docs.djangoproject.com/en/dev/internals/release-process/#deprecation-policy

Collin


On Thursday, November 12, 2015 at 7:48:28 AM UTC-5, Patryk Zawadzki wrote:
>
> Hello everyone, 
>
> I have spent quite a while thinking about this and am still not sure 
> what the best approach would be or even if there are enough benefits 
> to justify the change. 
>
> If you've ever worked with compiled code, you're probably familiar 
> with ABI versioning in dynamic libraries. This is somewhat similar. 
>
>
> The idea is to allow a project to specify that is _assumes_ Django to 
> behave like a particular version or release. It could do so by 
> specifying a TARGET_DJANGO_VERSION (better name needed) setting that 
> is a valid semantic version tuple. 
>
> Example: 
>
> TARGET_DJANGO_VERSION = (1, 8, 6) 
>
> New projects would start with the variable set to whatever Django 
> version was used to create them. If the variable is not set, Django 
> could raise an ImproperlyConfiguredError telling the user what to put 
> in the settings file or it could simply issue a warning and assume the 
> current version. 
>
>
> Now what that gives us: 
>
> * Django version Y could outright tell you that the project that 
> targets version X is not compatible and point you to the *relevant* 
> upgrade instructions (since we know both the old and the new version). 
>
> * Setting the target version to a higher value could turn deprecation 
> warnings to exceptions for all features deprecated in the target 
> version and earlier (which could make future-proofing your code 
> easier). 
>
> * Django could introduce A/B feature switches that introduce 
> backwards-incompatible behaviour if a high-enough target version is 
> specified without breaking existing projects. It would also make it 
> theoretically possible for the latest stable version to support the 
> last LTS version from the same code tree (although it would probably 
> require an enormous legacy/compat module). 
>
>
> Is that something that was discussed in the past? Does it make any sense? 
>
> Cheers, 
>
> -- 
> Patryk Zawadzki 
> I solve problems. 
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to 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/26073e01-8517-4ee2-bdf1-c81c9503a88e%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.