Re: Feature Request: Allow Serialize Foreign Keys as Ids

[Curtis Maloney]

On Sat, 5 Aug 2023, at 06:47, Ryan Gartin wrote:
> You are correct state_id is not a field on the model, state is, and using 
> “state” in the field lists works.
> 
> I would like to propose that if  ‘state_id’ is a valid property on the 
> queryset (and in the database) that is should be serialized.

I think the main limitation you're hitting here is the core serializers in 
Django are really primarily only tuned for generating fixtures; This is why 
pretty much every REST API framework for Django has had its own version of the 
idea.

The built in ones are simply not flexible enough.

IMHO the serializer is the most important part of any REST / API framework.

> While I understand that this is my personal preference I think it is 
> reasonable to request that if QuerySet.state_id returns a valid value then it 
> should also be capable of being serialized as well. 
Way back in the mid 2000s I did my own sub-classes of the core Serializers to 
allow this sort of thing. Since then I've tried maybe half a dozen REST API 
libs (including writing my own), and none of them used core serializers.

That's not to say your idea is without merit. I think if you give it an 
afternoon's digging you could add an option to the django core serializers to 
list non-field attributes to include.

--
Curtis
> 
> On Thursday, August 3, 2023 at 9:46:27 PM UTC-4 Curtis Maloney wrote:
>> __
>> Hi Mike,
>> 
>> On Fri, 4 Aug 2023, at 06:03, Ryan Gartin wrote:
>>> I came across this issue calling the following and FK fields with _id are 
>>> ignored:
>>> serialize('json', , fields=['title', 'state_id']). 
>> 
>> I think the problem you've run into here is "state_id" is not a Field on 
>> your model; it's where the raw PK value for your ForeignKey is stored.
>> 
>> I've just double checked the code for serialize, and I'm pretty sure the 
>> default behavior for a ForeignKey field _is_ _already_ to output the PK 
>> value.
>> 
>> What happens in your code if you put "state" instead of "state_id" in the 
>> field list?
>> 
>> --
>> Curtis

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/d9e79eb8-aeea-48b1-9837-7e97614e%40app.fastmail.com.

Re: Feature Request: Allow Serialize Foreign Keys as Ids

[Curtis Maloney]

Hi Mike,

On Fri, 4 Aug 2023, at 06:03, Ryan Gartin wrote:
> I came across this issue calling the following and FK fields with _id are 
> ignored:
> serialize('json', , fields=['title', 'state_id']). 

I think the problem you've run into here is "state_id" is not a Field on your 
model; it's where the raw PK value for your ForeignKey is stored.

I've just double checked the code for serialize, and I'm pretty sure the 
default behavior for a ForeignKey field _is_ _already_ to output the PK value.

What happens in your code if you put "state" instead of "state_id" in the field 
list?

--
Curtis

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/99bd4b70-9f98-4f9d-a3d5-23c5d965b223%40app.fastmail.com.

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

[Curtis Maloney]

Does the Forum allow me to get email notifications / summaries?

If not, it will mean I disconnect with that part of the community.

--
Curtis

On Thu, 4 May 2023, at 15:19, Arthur Rio wrote:
> Yes please!
> 
> 
> 
> On May 3, 2023 at 11:19:12 PM, jure.erznoz...@gmail.com 
> (jure.erznoz...@gmail.com) wrote:
> 
>> 
>> +1
>>  
>> *From:* django-developers@googlegroups.com 
>>  *On Behalf Of *natali...@gmail.com
>> *Sent:* sreda, 03. maj 2023 20:10
>> *To:* Django developers (Contributions to Django itself) 
>> 
>> *Subject:* Re: Can we move the activity on this list to the Forum now?
>>  
>> Hello everyone!
>>  
>> I was wondering if we could make a decision about this topic. On the one 
>> hand, and as far as I understand, the forum is the preferred channel of 
>> communication. On the other hand, having multiple channels of communication 
>> can spread important discussions too thin, making it difficult to have 
>> productive conversations in one place.
>>  
>> As a newcomer to the contributing community, I can attest that the current 
>> situation causes some confusion. IMHO, the same applies to the chat options: 
>> there is IRC and the Discord server (though perhaps I should start a new 
>> forum topic about that in order to keep decisions separated).
>>  
>> In summary, I'm +1 to "move on-mass (all few of us :) over there"!
>>  
>> Thank you!
>> Natalia.
>> On Thursday, January 26, 2023 at 10:07:36 AM UTC-3 Alex Krupp wrote:
>>> I just submitted a proposal to create a Discourse plugin to improve the 
>>> accuracy of their inbound email parsing. This would enable two things:
>>>  • Folks who prefer to live in their inbox could continue to do so and 
>>> contribute by just replying to emails. Discourse currently has 
>>> reply-by-email, but it often mangles formatting and/or entirely deletes 
>>> text. Once these issues are fixed, folks who like the current experience 
>>> would be able to just pretend the forum doesn't exist and continue having 
>>> the same experience as they currently have with Google Groups.
>>>  • Right now importing the archives from Google Groups into Discourse isn't 
>>> realistic for the same reasons; some messages will import correctly, but 
>>> others will be mangled or missing text. This would also be made possible.
>>> If this is something you care about (positively or negatively), here is the 
>>> exploratory proposal:
>>>  
>>> https://meta.discourse.org/t/proposed-plugin-to-improve-reply-by-email-accuracy/252944
>>>  
>>> Any feedback and/or testing would be much appreciated! Right now Discourse 
>>> recognizes that this is a problem and is interested in solving it, but 
>>> getting it prioritized will require folks to A) speak up saying they want 
>>> it done B) test the underlying API to verify that it actually solves the 
>>> problem.
>>>  
>>> Alex
>>>  
>>> On Fri, Jan 20, 2023 at 2:24 AM Carlton Gibson  wrote:
 OK, I've updated the Trac wiki page to point to the forum too. (We use 
 this as a wiki-link in responses to guide folk onwards.) 
  
 The docs have a `|django-developers|` shortcut used in quite a few places 
 so that needs a moment more to review and adjust. 
 (I'll look at it soon-ish... — if no-one beats me to it :) 
  
 Thanks. 
 C
  
 On Thu, 19 Jan 2023 at 18:15, Andrew Godwin  wrote:
> We should at least update those Trac and Triage Workflow docs to point to 
> both, maybe with the Forum first?
>  
> Andrew
>  
> On Thu, Jan 19, 2023, at 12:30 AM, Carlton Gibson wrote:
>> I'm trying to begin new conversations there where I can. 
>>  
>> The main issue is that we're still pointing people here from Trac and 
>> the Triage Workflow docs — so if there's a rough "Yeah, let's do it" we 
>> can adjust practice there. 
>>  
>> I expect there will always be the "How do I start?" posts. The Forum at 
>> least has a pinned post for that. ... 
>>  
>> On Thu, 19 Jan 2023 at 01:04, 'Kye Russell' via Django developers 
>> (Contributions to Django itself)  wrote:
>>> Hi all,
>>>  
>>> I find that the signal-to-noise ratio on this mailing list is (by my 
>>> determination) quite bad around this time of year.
>>>  
>>> Is a move to the forum still on the cards? 
>>>  
>>> Kye
>>> On 6 Dec 2022 at 7:16 AM +0800, Andrew Godwin , 
>>> wrote:
>>>  
 I did some investigation of moving django-users and django-developers 
 to the Forum right after DjangoCon; I wanted to see if we could import 
 all the old posts too, which we probably could, but I'm not entirely 
 sure of the utility of that.
  
 I will say that the forum is a lot easier to moderate - the ability to 
 moderate after a post has gone out, rather than gating all posts 
 behind approval if they're untrusted, is a big step in itself, not to 
 mention the ability to remove sensitive or 

Re: Drop CSRF middleware from the settings template

[Curtis Maloney]

On Mon, 17 Apr 2023, at 04:25, 'Ryan Hiebert' via Django developers  
(Contributions to Django itself) wrote:
> I've recently been working with other new frameworks, particularly Remix. 
> Coming from Django, which has had excellent CSRF for many years, one of my 
> first questions was how to handle CSRF protection. And the response I got 
> lead me to the "Lax" SameSite cookie parameter, and that I really wouldn't 
> need more than that for the session cookie.

I think I missed a detail here.

What problem are you having with using CSRF?

What response did you get?

Was it different to what's in the Django docs here ?
https://docs.djangoproject.com/en/4.2/howto/csrf/#using-csrf-protection-with-ajax

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

Are you implying that all CSRF attacks protected by Django's current machinery 
are entirely mitigated by SameSite=Lax on the _session_ cookiue?

--
Curtis

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/2398009a-928d-444e-888e-ed901f2b55de%40app.fastmail.com.

Re: create database view from another table

[Curtis Maloney]

Hi Mike,

this is not really the correct list for your question - this list is about 
development _of_ Django, not _with_ Django.

That said:
did you consider adding an index for each of the derived values you wanted? 
This can act as an efficient way to keep, effectively, a "cache" of values 
derived from commonly used expressions.

The downside is your queries MUST use the same expression in order for the 
index to be considered.

The practice of wrapping a VIEW in an unmanaged Django Model (i.e. Meta.managed 
= False) is a long established and well tested pattern, though your approach to 
achieving this is novel.

Personally, I would:
- get the SQL Django emits to create the original table using "sqlmigrate"
- alter it to a CREATE VIEW with the additional fields, etc
- clone the Model class definition, add new fields, and set Meta.managed = 
False, and Meta.db_table to the view name.
- run "makemigrations"
- Add a raw SQL migration using the CREATE VIEW statement.
- run "migrate"

On Tue, 7 Feb 2023, at 07:48, Fred Mayer wrote:
> I had a problem and solved it; just want to know if there was another more 
> elegant solution than the one I did.   Please let me know if you know of a 
> better option:
> 
> The issue:  have a date-time column in my specific SQLITE3 table.  wanted to 
> create Year, Month, Day, Hour, Minute, Seconds and a few others like DATE and 
> TIME.  Not practical to clone the database table, so wanted a 'View' against 
> it.
> 
> 2) went to my project folder and brought up the MODELS.py, and cloned the 
> table, and added a *project_Vtablename* table.  (added the "V" in front of 
> the table's name.
> 
> 3) Went thru the "*makemigrations*" option, then the "*migrate*" option.  
> when it successfully finished, I had both the* project_tablename* and 
> *project_Vtablename* tables in the DB.
> 
> 4) then to insert the extra columns, went to SQLITE3,  developed and debugged 
> a *CREATE VIEW **project_Vtablename* statement, with all the additional 
> columns added (Year, Month, etc).  Of course I deleted the 
> *project_Vtablename *before creating it as a VIEW.
> 
> 5) returned to  the VIEWS.py program and copied the IMPORT statement to add 
> the  *project_Vtablename* , and cloned a function that is successfully 
> reading the original - changed all instances of tablename to Vtablename.  AND 
> it WORKS.



> 
> Now, with the *Year *column, i can now much more easily use and understand my 
> SQL filters when parsing a date-time column.
> 
> ...so, is there a _more elegant way_ to install a database VIEW than a method 
> something like the above?  If so, please SHARE IT so I and others can take 
> advantage of it.  
> 

--
Curtis

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/d23bd268-bbb0-410a-b067-6f771332734b%40app.fastmail.com.

Re: ticket 5929

[Curtis Maloney]

On Sun, 8 Jan 2023, at 23:29, Barhamou Hama wrote:
> Hi all, I came across this ticket here 
>  opened 15 years ago that doesn't 
> seem to have been resolved. I decided to work on it. But in 15 years a lot 
> can happen. Is it still relevant? Has there been any progress on this issue?
>  

IIRC there's no current support for this, the closest being GenericForeignKeys, 
which still require their sub-fields defined separately.

There has been posts about supporting joint using multi-field keys 
(https://devblog.kogan.com/blog/custom-relationships-in-django) however, that's 
a rather specific case.

I think it would be a good thing for progress on this issue to happen.

You might also want to check the ticket history for any work on multi-value 
keys.

--
Curtis

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/9f8cb18e-038c-4fe3-8858-6cd23adda769%40app.fastmail.com.

Re: Integrate dj-database-url into Django

[Curtis Maloney]

I recently did a bit of an audit of "settings types" whilst preparing for an 
overhaul of django-classy-settings.

I found you could cover a majority of the common config types if you could 
somehow parse from an environ string the following (which closely aligns with 
django-environ):

+ str
+ int
+ bool
+ list/tuple
+ list/tuple
+ DB Config
+ Cache Config

The complicated ones being DB/Cache configs, and mostly because:
- whilst a basic URL suffices, there are lots of optional and sometimes nested 
options
- sqlite in-memory syntax is "special".

Alternatively, I've been telling myself for a while now I'd add 
django-compatible types to confucius, which uses a type annotations approach to 
env-driven settings.

Both support providing __dir__ and __getattr__ so you can plug them 
"transparently" into your settings.py whilst still benefiting from class 
features.


On Tue, 29 Nov 2022, at 09:20, James Bennett wrote:
> It feels like this needs to be a broader conversation about not just
> changing DATABASES to accept a URL, or integrating a particular
> database-settings project, but to re-think how Django does
> settings-from-environment as a whole.
> 
> When I'm setting up new Django-based projects, django-environ
> (https://pypi.org/project/django-environ/) is now one of the first
> packages I reach for, and it has a much more comprehensive set of
> helpers for configuring Django from environment variables and doing
> appropriate parsing and type casts.
> 
> There also is Pydantic's settings model
> (https://pydantic-docs.helpmanual.io/usage/settings/) which uses type
> annotations to drive parsing/validation/type-casting and defaults to
> reading from environment variables.
> 
> I'd rather see some sort of comprehensive "make settings-from-env
> easier" in Django than one-off pieces like a database URL.
> 
> -- 
> You received this message because you are subscribed to the Google Groups 
> "Django developers  (Contributions to Django itself)" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to django-developers+unsubscr...@googlegroups.com 
> .
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/django-developers/CAL13Cg-cqJi1JanmhN0S3rf1MYME9qH4XJsCEjLdB5wFXEQeAA%40mail.gmail.com.
> 

--
C

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/a2aac2d9-d094-4df3-9b8e-df92ad9e1dc3%40app.fastmail.com.

Re: Model-level validation

[Curtis Maloney]

FWIW +1 from me!

--
C


On Thu, 6 Oct 2022, at 14:11, Aaron Smith wrote:
> It sounds like there is little support for this being the default. But I'd 
> like to propose something that might satisfy the different concerns:
> 
> 1) A `validate` kwarg for `save()`, defaulted to `False`. This maintains 
> backwards compatibility and also moves the validation behavior users coming 
> to Django from other frameworks likely expect, in a more user friendly way 
> than overriding save to call `full_clean()`.
> 
> And/or...
> 
> 2) An optional Django setting (`VALIDATE_MODELS_DEFAULT`?) to change the 
> default behavior to `True`. The `validate` kwarg above would override this 
> per call, allowing unvalidated saves when necessary.
> 
> These changes would be simple, backwards compatible, and give individual 
> projects the choice to make Django behave like other ORMs with regard to 
> validation. This being the Django developers mailing list I should not be 
> surprised that most people here support the status quo, but in my personal 
> experience, having had this conversation with dozens of coworkers over the 
> years - 100% of them expressed a strong desire for Django to do this 
> differently.
> On Wednesday, September 28, 2022 at 9:29:30 PM UTC-7 Aaron Smith wrote:
>> Why doesn't Django validate Models on save()?
>> 
>> I am aware that full_clean() is called when using ModelForms. But most web 
>> app development these days, and every django app I've ever worked with, are 
>> headless APIs. The default behavior is dangerous for the naive developer.
>> 
>> Bringing View-level concepts such as forms or serializers down into celery 
>> tasks and management commands breaks separation of concerns, and having 
>> multiple validation implementations at different layers in the app is 
>> fraught with divergence and unexpected behavior.
>> 
>> It's not right. The data store layer should protect the validity of the data.
> 
> 
> -- 
> You received this message because you are subscribed to the Google Groups 
> "Django developers (Contributions to Django itself)" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to django-developers+unsubscr...@googlegroups.com.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/django-developers/004c2b9b-6e36-4061-b860-17eb7ebee15en%40googlegroups.com
>  
> .

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/0b25292a-4197-451f-926f-f35a527b5d6d%40app.fastmail.com.

Re: Model-level validation

[Curtis Maloney]

On Thu, 29 Sep 2022, at 14:29, Aaron Smith wrote:
> Why doesn't Django validate Models on save()?

The short answer is: backwards compatibility.

Model level validation hasn't always been a thing, with Django initially 
depending primarily on Form validation.

Since it hadn't _always_ been there, it wasn't possible to introduce it, 
enforce it, and not break most apps out there.

There was so much code written that generally assumed it could call `save()` 
and not have to catch validation errors.

For what it's worth, I'm all in favor of making it run on `save()` ... updating 
the documentation and preparing the community is going to be a mammoth task, 
however. A safe course through this will take some very careful planning.

--
C

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/10d789b9-5f10-4823-98e8-0494c8510bf7%40app.fastmail.com.

Re: Configuration of "level" in LOGGING

[Curtis Maloney]

On Tue, 5 Apr 2022, at 09:26, Dan Swain wrote:
> The current Django LOGGING setup requires a string for the "level".  This is 
> not intuitive since the Python logging module defines logging.DEBUG, 
> logging.INFO, etc.  I think one should be able to configure the logging level 
> using {  'level': logging.DEBUG  } rather than being required to use  {  
> 'level': 'DEBUG'  }.

It's worth noting that Django, by default, uses python's own 
`logging.config.dictConfig` to process the LOGGING config object - 
https://docs.python.org/3/library/logging.config.html#logging.config.dictConfig

Since Python 3.2 `setLevel` has supported being passed a string of the name of 
the level: 
https://docs.python.org/3/library/logging.html#logging.Logger.setLevel

So the feature you're referring to is one from Python's stdlib.

Note: there is nothing to stop you from using `logging.DEBUG` if you prefer.

--
Curtis

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/4556994f-4aa8-4512-a31d-b898216a8b74%40www.fastmail.com.

Re: Deprecation of using pk in public ORM API

[Curtis Maloney]

Hello Mike,

On Wed, 26 Jan 2022, at 20:46, Albert wrote:
> 
> Hello all,
> 
> I would like to know your opinion about deprecation of using "pk"
> alias in filters and other places of public ORM API.
> I use Django long time and never use "pk" because in my opinion
> it is misleading.
> I mean, instead:
> Car.objects.filter(pk=1)
> I use
> Car.objects.filter(id=1)
> Insted car.pk I use car.id

AIUI the purpose of the `pk` alias is you can't assume the primary key will 
always be named `id`.

Knowing you can always refer to `pk` allows more generic query construction.

This is used, for example, in the generic views.

> 
> From SQL point of view it doesn't matter because it is always:
> SELECT * FROM car WHERE id=1
> 
> It am not sure if using "pk" gives value to users. Field "pk" is not
> defined by user.

No, but the model's primary key field might be, which is the point.

--
Curtis

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/12cfc479-a288-4a3c-8cc7-bf47fd36db7a%40www.fastmail.com.

Re: Idea

[Curtis Maloney]

Additionally, incorporating DRF [or any other 3rd party lib] into core would 
lock them into Django's release cycle.

As for built-in REST/API features, Django provides `JsonResponse` already, so 
the main piece lacking is de/serialisers.

The built in serializer framework is well suited to generating fixtures, and 
_can_ be bent to serialising your data for APIs, but does not provide any 
solution for validating input.

Our existing input validation solution - Forms - is not so good at handling 
complex or deeply nested data structures.

However, in recent years tools, like pydantic and marshmallow, have begun 
filling this space.

One place we could help everyone is by providing a JSON request-body parsing 
utility.

--
Curtis


On Thu, 16 Sep 2021, at 10:58, Benny wrote:
> There are serializers and dictionaries built into the Django models system 
> that I’ve had zero problems leveraging for building out JSON (or REST-like) 
> objects for endpoint purposes. I personally believe integrating DRF into 
> Django would needlessly bloat it. The two play together perfectly fine if you 
> really need them both.
> 
> I’d recommend digging around in the guts of Django. You’ll find some pretty 
> neat things there!
> 
> Just my 2 cents,
> Benny  
> 
>> On Sep 15, 2021, at 6:36 PM, Michael Urban  wrote:
>> 
>> For YEARS I’ve wanted a REST solution included with Django. DRF hasn’t never 
>> felt like a great fit for Django projects. It’s very Rails-y.
>> 
>> It would be amazing to have an official Django contrib package for REST.
>> 
>> Never going to happen, but needs to be said.
>> 
>> Best,
>> Mike 
>> 
>> On Wed, Sep 15, 2021 at 4:40 PM 'Adam Johnson' via Django developers 
>> (Contributions to Django itself)  wrote:
>>> DRF remains an extension to Django. We don't want Django to depend on it.
>>> 
>>> But you're free to set up a startproject template that includes the 
>>> settings, and use that. 
>>> https://docs.djangoproject.com/en/3.2/ref/django-admin/#cmdoption-startproject-template
>>> 
>>> On Tue, 14 Sept 2021 at 08:44, abdul azeez  wrote:
 Pls can we make django come with django reest framework settings when you 
 start a project 
 
 
 -- 
 You received this message because you are subscribed to the Google Groups 
 "Django developers (Contributions to Django itself)" group.
 To unsubscribe from this group and stop receiving emails from it, send an 
 email to django-developers+unsubscr...@googlegroups.com.
 To view this discussion on the web visit 
 https://groups.google.com/d/msgid/django-developers/b91e5471-23d3-41e2-b5c5-e1f860739fe0n%40googlegroups.com
  
 .
>>> 
>>> 
>>> -- 
>>> You received this message because you are subscribed to the Google Groups 
>>> "Django developers (Contributions to Django itself)" group.
>>> To unsubscribe from this group and stop receiving emails from it, send an 
>>> email to django-developers+unsubscr...@googlegroups.com.
>>> To view this discussion on the web visit 
>>> https://groups.google.com/d/msgid/django-developers/CAMyDDM39FCfnt0-qU2Z1wSaR1j0ZuJwc3xntEDZtWB6Qjz2fYQ%40mail.gmail.com
>>>  
>>> .
>> 
>> 
>> -- 
>> You received this message because you are subscribed to the Google Groups 
>> "Django developers (Contributions to Django itself)" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to django-developers+unsubscr...@googlegroups.com.
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/django-developers/CADyXHNar2-0TqdRi%2ButYwn8qd%2Bh34ZtyoxvuwNQ%3DMSB%2B%2B82NiA%40mail.gmail.com
>>  
>> .
> 
> 
> -- 
> You received this message because you are subscribed to the Google Groups 
> "Django developers (Contributions to Django itself)" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to django-developers+unsubscr...@googlegroups.com.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/django-developers/81908113-FAF5-4DE9-B84F-FCC3DDFF7453%40twosensedesign.com
>  
> .

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

Re: A base compression middleware class

[Curtis Maloney]

Hi Illia,

I like the idea here, and your design looks sensible at first blush, but I feel 
conflicted.

As much as I like the idea of allowing more flexibility and future-proofing 
this middleware,
AIUI the gzip middleware is generally discouraged, as it's typically more 
efficient to have your web server do this work.

I'd be more tempted to deprecate GzipMiddleware in core, and move this feature 
into a 3rd party app.

An additional hook for your interface: a function to test if this compressor 
should be used on this response. For instance, the gzip middleware has a 
minimum size below which it's deemed not worth the effort to try to compress.

--
Curtis


On Tue, 15 Jun 2021, at 04:49, Illia Volochii wrote:
> Hi all,
> 
> There is `GZipMiddleware` that compresses response bodies using gzip.
> https://github.com/django/django/blob/main/django/middleware/gzip.py
> 
> But there are other algorithms supported by browsers (e.g., Brotli).
> At the moment, if somebody wants to add support for any of them in a
> Django project, one has to create a new middleware class redefining
> all the logic processing responses.
> 
> I propose simplifying the process by creating
> `BaseCompressionMiddleware`. Its subclasses would just need to define
> a tuple of supported compressors.
> 
> The tuple elements could be instances of such a data class:
> ```
> @dataclass
> class Compressor:
> name: str
> compress_string_func: Callable[[bytes], bytes]
> compress_sequence_func: Optional[
> Callable[[Iterable[bytes]], Iterator[bytes]]
> ] = None
> 
> def is_accepted_by(self, accept_encoding):
> return bool(re.search(rf'\b{self.name}\b', accept_encoding))
> ```
> 
> 
> And the class could select a compressor using such code:
> ```
> @classmethod
> def select_compressor(cls, request, response):
> ae = request.META.get('HTTP_ACCEPT_ENCODING', '')
> for compressor in cls.compressors:
> if (
> compressor.is_accepted_by(ae)
> and (not response.streaming or compressor.compress_sequence_func)
> ):
> return compressor
> ```
> 
> 
> Note, in the example `compress_string_func` is required and
> `compress_sequence_func` is optional. I think that
> `compress_string_func` would usually be a library function, and
> `compress_sequence_func` would require some custom logic. And we
> should not force users to define the latter.
> 
> `GZipMiddleware` could be changed to
> ```
> gzip_compressor = Compressor(
> name='gzip',
> compress_string_func=compress_string,
> compress_sequence_func=compress_sequence,
> )
> 
> class GZipMiddleware(BaseCompressionMiddleware):
> compressors = (gzip_compressor,)
> ```
> 
> 
> And someone wanting to support both Brotli and gzip could define:
> ```
> import brotli
> from django.middleware.gzip import gzip_compressor
> 
> brotli_compressor = Compressor(
> name='br',
> compress_string_func=brotli.compress,
> )
> 
> class CompressionMiddleware(BaseCompressionMiddleware)
> compressors = (brotli_compressor, gzip_compressor)
> ```
> 
> 
> Please let me know what you think about such an enhancement.
> I will be happy to create a pull request if this is accepted.
> 
> Thanks,
> Illia
> 
> 
> 

> -- 
> You received this message because you are subscribed to the Google Groups 
> "Django developers (Contributions to Django itself)" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to django-developers+unsubscr...@googlegroups.com.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/django-developers/49535d7e-758c-4acf-a9da-831ccfa1d17bn%40googlegroups.com
>  
> .

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/c4cef215-7cae-4c6b-a9b2-7b4785b3a9bf%40www.fastmail.com.

Re: GSOC Proposal : A new AUTH library.

[Curtis Maloney]

Just throwing another idea into the pile whilst we're here.

For a long time I've felt we could more easily support a lot more use cases if 
we separated Authentication from Authorization.

The simplest path for this would be to separate credentials (username, 
password) from the User record.

This would mean then we normalise the idea of separating credentials, and 
having multiple sets for a single user; Each auth backend would know to check 
its own set, be it (username, password), or Twitter oauth token, or whatever.

--
Curtis


On Fri, 9 Apr 2021, at 12:50, NIKHIL MUDDAMSETTY wrote:
> Hello,
> I am Nikhil Muddamsetty and I want to add a new AUTH library with the 
> following features.
> 
> 1 > Custom user model to support phone-number or email or username or a 
> combination of any of these three.
> 
> 2 > Traditional Account signup and login 
> 
> 3 > Email verification for traditional signup.
> 
> 4 > 2-factor authentication using OTP sent to email.
> 
> 4 > Oauth signup and login support (Google, Github & Twitter for now). 
> 
> 5 > Authenticator app login support.
> 
> 6 > Single user model for any kind of signup type (traditional or Oauth).
> 
> 7 > Multiple social accounts linking to the same Django user instance.
> 
> please provide me feedback, if this will be a good proposal. Can this 
> proposal be considered valid under the third category (Work on libraries that 
> supplement or add new features to Django to ease development) and what 
> features should be added (or removed)
> 
> Regrads
> Nikhil Muddamsetty
> 

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/30e22c95-e6b3-4e62-b365-a6b8ca1556ae%40www.fastmail.com.

Re: Let's simplify coding with html

[Curtis Maloney]

I think it's unclear to me what you mean by "support for bootstrap".

Bootstrap is, after all, a CSS library [with some JS tools for complex widgets].

It looks like the syntax example you gave supports specifying classes [and 
likely other attributes] on elements, so using Bootstrap with that is a matter 
of including the CSS file, and adding the classes.

--
Curtis



On Mon, 22 Mar 2021, at 12:50, manasdeep borole wrote:
> Thanks 
> But it seems there is no support for bootstrap (at least not directly)
> Or may be I am missing something
> Please feel free to point out...
> 
> On Mon, Mar 22, 2021 at 1:51 AM Aymeric Augustin 
>  wrote:
>> Hello,
>> 
>> There are several projects providing alternate syntax for generating HTML, 
>> along the lines of your suggestion, and other projects for integrating these 
>> with Django. Here's one such project: 
>> https://github.com/nyaruka/django-hamlpy. I believe we're happy with this 
>> functionality being provided by third-party projects. As a consequence this 
>> doesn't seem likely to be accepted for GSoC.
>> 
>> -- 
>> Aymeric.
>> 
>> 
>> 
>>> On 21 Mar 2021, at 17:08, manasdeep borole  wrote:
>>> 
>>> Hi Everyone,
>>> I know coding could get tough sometimes(experienced it).
>>> But thanks to amazing people like you and per built framework like Django.
>>> At least not everyone has to know everything now.
>>> The Open Source support is amazing as well.
>>> Thanks a lot.
>>> 
>>> Last time while working with html I was annoyed by the syntax. 
>>> You have to deal with so many end tags they tend to confuse you.
>>> eg 
>>> 
>>> NOW...
>>> 
>>> 
>>> 
>>> this is most inner class
>>> 
>>> this is quite outer class
>>> 
>>> this is most outer class
>>> 
>>> 
>>> With Improvement
>>> 
>>> div class='upper':
>>> div class='middle':
>>> div class='lower':
>>> "this is most inner class
>>>  "this is quite outer class"
>>> "this most outer class"
>>> 
>>> advantages:
>>>  1. Python like indentation
>>>  2. simple to read (developer/debugger friendly)
>>>  3. 50% lowers the chances of mistake while coding (most errors happen 
>>> because coders forget end tags with html)
>>>  4. no end tags required
>>>  5. supports python based logic building like use of for, if
>>>  6. programers are free to let computer do the repetitive tasks like logic 
>>> based id for multiple div with similar functionality 
>>>  7. plans to support direct support for bootstrap( working on it)
>>> 
>>> disadvantages:
>>>  1. needs time and effort to build such a system
>>>  2. expert support and guidance may be needed
>>>  3. adoption time and some effort on part of programmers 
>>> If someone could mentor me I am willing to build on this Idea
>>> Actually I have built a basic version.
>>> I understand you would have a lot of requests for GSOC application.
>>> Can someone guide me if this Idea could be made into a GSOC proposal.
>>> If you have any suggestion or ideas to make this project better you are 
>>> most welcome.
>>> Thank you 
>>> For your 'time' and 'consideration'
>>> 
>>> 
>>> 
>>> 
>>> -- 
>>> You received this message because you are subscribed to the Google Groups 
>>> "Django developers (Contributions to Django itself)" group.
>>> To unsubscribe from this group and stop receiving emails from it, send an 
>>> email to django-developers+unsubscr...@googlegroups.com.
>>> To view this discussion on the web visit 
>>> https://groups.google.com/d/msgid/django-developers/024e7422-8242-497c-9a32-f5b67b4fcae3n%40googlegroups.com
>>>  
>>> .
>> 
>> 

>> -- 
>> You received this message because you are subscribed to the Google Groups 
>> "Django developers (Contributions to Django itself)" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to django-developers+unsubscr...@googlegroups.com.
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/django-developers/F7ED4035-51FD-4F64-AB3C-791C57C83B8F%40polytechnique.org
>>  
>> .
> 

> -- 
> You received this message because you are subscribed to the Google Groups 
> "Django developers (Contributions to Django itself)" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to django-developers+unsubscr...@googlegroups.com.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/django-developers/CA%2BFa1GVNOQx79VaHwTOZcBAmvtQKmBOCFTE%3Dfh4k86H1rO7pNQ%40mail.gmail.com
>  
> .

-- 
You received this message because you are subscribed to the 

Re: Feature request: Template tag like stateless component in JSX React

[Curtis Maloney]

On Fri, 29 Jan 2021, at 19:18, Aztec Rabbit wrote:
> Curtis - This is nested block right? what i want is like tag include (can be 
> called more than once) but with children.

Correct. And that's more or less what nested block does;

The difference from include is sniplates takes a template and rips the blocks 
from it, each of which then becomes a macro of sorts.

> 
> Jure - I've read the documentation, can you give me a sample code? I am 
> confused
> 
> Hmmm, but i think this feature is very useful (for card, container, wrapper, 
> and anythink with different content) and each component can be included in 
> other components, thats awesome. I think this feature should be in django 
> core, but, yes, I understand.

I agree that it could be quite useful.

I would suggest first making a sample implementation. This would involve taking 
`do_include` from django/templates/loader_tags.py and making a version that's 
an enclosing block tag (like block)... then exposing the nodelist in the 
context.

--
Curtis

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/a33eb617-6171-4a7d-826a-7ff6a9c1e077%40www.fastmail.com.

Re: Increase default integer keys to 64 bits

[Curtis Maloney]

I recall a discussion some time about about adding a setting to control which 
field to use for the default PK... seems there's some overlap here.

--
C


On Fri, 29 Jan 2021, at 12:42, Christophe Pettus wrote:
> tl;dr: Introduce new field types to handle auto-incremented ID fields, change 
> the PostgreSQL backend to use the preferred syntax
> 
> --
> 
> One of the most common issues my company runs into on Django sites is that 
> models.AutoField defaults to a 32-bit integer (int32).  2^31-1 possible 
> entries is just not that many anymore, and by the time the developers realize 
> this and need to move to a 64 bit integer key, it's too late to do so 
> conveniently, because expanding the field is very painful (in PostgreSQL, at 
> least).
> 
> While models.AutoBigField exists, it's barely mentioned in examples, and is 
> often overlooked.
> 
> Changing AutoField to 64 bits would result in all kinds of breakage; at best, 
> a lot of very unplanned and expensive migrations.
> 
> My proposal is:
> 
> 1. Create two new field types to represent auto-incrementing primary keys.  
> I'd suggest IdentityField and SmallIdentityField for int64 and int32, 
> respectively.
> 
> 2. Change all examples to use SerialField instead of AutoField.
> 
> 3. As a side note, switch the PostgreSQL backend to use the standard 
> "GENERATED BY DEFAULT AS IDENTITY" syntax.  This became available in 
> PostgreSQL version 10, but the previous version (9.6) reaches EOL in November 
> 2021.
> 
> 4. At some point in the future, deprecate AutoField and AutoBigField.
> 
> This would result in new projects getting 64 bit primary keys by default.  I 
> think that's a positive.  For small tables, the size difference hardly 
> matters; for big tables, we have saved a major foot-gun of either integer 
> exhaustion or a very expensive data migration problem.
> 
> --
> 
> Comments?
> 
> --
> -- 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 view this discussion on the web visit 
> https://groups.google.com/d/msgid/django-developers/F4A50AB6-8CC1-4B6E-BD1B-B865F53A645A%40thebuild.com.
> 

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/50ec245f-21a4-4ab9-ac51-55be2c969310%40www.fastmail.com.

Re: Add image and phone_number fields to Django User auth model

[Curtis Maloney]

I second this; I would have moved to having auth.User be abstract, and force 
projects to create their own _always_, except (a) it breaks a lot of history, 
and (b) it breaks the "ready to go out of the box" nature.

It's a small cost at the start of your project, that avoids problems for a 
sizable portion of all projects which end up customising User.

It also makes it more obvious that you _can_ customise user; that it's just 
like any other model.

--
C


On Fri, 29 Jan 2021, at 02:00, Ken Whitesell wrote:
> I can see where you might think that, but I actually believe it should go in 
> the other direction - that the User model should be the absolute _minimum_ of 
> an entity.
> 
> 1. The User model is retrieved with every authenticated request. The more 
> fields in the model, the more data is being handled unnecessarily. (Do you 
> really need the User phone number with every request?)
> 
> 2. If you go in that direction, there's no way you're going to reach a 
> consensus as to what fields should be included, or to make a valid argument 
> against field "X" once field "Y" has been added - ending up with an extremely 
> over-bloated object.
> 
> 3. It's too easy to extend or replace the user model. The process is 
> well-documented. Saying "some developers don't want to" do something doesn't 
> constitute a reason.
> 
> (I'm an extremist in the other direction. I believe that the User model 
> should only consist of the PK, and an "active" flag. All other information 
> can be stored in ancillary tables - but I acknowledge that that's very much a 
> minority position as well.)
> 
> 
> On 1/28/2021 8:25 AM, Muhammad Shehzad wrote:
>> Hey Developers! Some fields should be inside *models.**User* e.g. image, 
>> phone_number. Some developers don't want to extend the auth model. Yes i 
>> know there are some ways to extends the auth model. But i think these fields 
>> should come with *models.**User*
>> -- 
>> You received this message because you are subscribed to the Google Groups 
>> "Django developers (Contributions to Django itself)" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to django-developers+unsubscr...@googlegroups.com.
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/django-developers/da95c74b-413c-41f0-85b5-9bef2320eecfn%40googlegroups.com
>>  
>> .
> 

> 

> -- 
> You received this message because you are subscribed to the Google Groups 
> "Django developers (Contributions to Django itself)" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to django-developers+unsubscr...@googlegroups.com.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/django-developers/d0f5e304-f1f1-19d0-4300-37f3961b270b%40comcast.net
>  
> .

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/a709adc2-1656-4e6c-b8af-9f01805552fa%40www.fastmail.com.

Re: Feature request: Template tag like stateless component in JSX React

[Curtis Maloney]

I did something like this in django-sniplates 

https://sniplates.readthedocs.io/en/latest/tags.html#the-nested-widget-tag

--
C

On Thu, 28 Jan 2021, at 17:33, Aztec Rabbit wrote:
> Hi,
> 
> I think template tag like in JSX is very useful, for example:
> 
> > card.html
> 
> 
>   {{ title }}
>   {{ component.children }}
> 
> 
> > index.html
> 
> {% component './card.html' with title='Foo' %}
>   Bar
> {% endcomponent %}
> 

> -- 
> You received this message because you are subscribed to the Google Groups 
> "Django developers (Contributions to Django itself)" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to django-developers+unsubscr...@googlegroups.com.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/django-developers/ff75ddef-2267-44f5-89f7-9b8ebf1460efn%40googlegroups.com
>  
> .

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/4a8767e0-63a9-4b34-81c7-aea75a67f653%40www.fastmail.com.

Re: Pendolumn

[Curtis Maloney]

Hi, Damiano

I suspect we chatted on IRC yesterday about this...

On Wed, 9 Sep 2020, at 11:01, Damiano Porta wrote:
> Hello everybody!
> Can I use Pendolumn (https://pendulum.eustace.io/) as default datetime 
> library for my models?
> This library is good, it has very intuitive and clean API design. It is 
> relying on the standard library. So, it is basically a "more advanced" 
> datetime.

You can use whatever tools you want in your application.

Where do you see this library in particular providing benefit in your models?

What I understood of your query yesterday [if it were, indeed, you] was you 
were proposing Django used this lib throughout.

If that is the case, you would need to clearly describe what benefits the 
project as a whole would gain by bringing on this dependency that couldn't 
already be managed by a 3rd party package that individual projects could opt to 
use.

--
Curtis

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/30434283-7856-47a9-9720-a3204f084af4%40www.fastmail.com.

Re: Django default input validation accepts special caracters

[Curtis Maloney]

Just my 0.02 $CURRENCY...

Interesting they're limiting the input for a security issue [at least from the 
example] that manifest from not escaping _output_.

Seems related to something I learned early in my web career... about not 
storing values escaped, because you don't know which medium it needs escaping 
for -- e.g. HTML needs different escaping than URLs.

--
Curtis


On Tue, 18 Aug 2020, at 18:35, '1337 Shadow Hacker' via Django developers  
(Contributions to Django itself) wrote:
> Currently, when you order a security audit on a Django project from any of 
> the firms I've seen so far (including my own), all inputs fall short on stuff 
> like:
> 
> "First name input: allows special caracters such as <>/"' which may cause a 
> security issue with further developments done on the same database but 
> outside Django".
> 
> As far as I can imagine, special caracters would be acceptable on inputs that 
> should accept code or some kind of math, which is not the case for most 
> inputs.
> 
> Django should harden default input validation to make it easier for Django 
> projects to get a good grade on security audits, without having to go over 
> all fields to setup basic input validators.
> 

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/b49fc6b2-1a54-4b93-8263-46ad65604407%40www.fastmail.com.

Re: include_block template tag

[Curtis Maloney]

Interesting ideas... and looks similar to some of the features I put into 
Sniplates: https://sniplates.readthedocs.io/en/latest/

If you like we can work on adding this to sniplates, if it's not accepted into 
core.

--
Curtis


On Mon, 17 Aug 2020, at 19:05, Jure Erznožnik wrote:
> While rendering templates we often come into situations where data remains 
> the same, but sometimes we want to render it one way, other times - another.

> Examples:

> a library supporting various CSS frameworks. You would always render panel 
>  title and 
> panel body, but bootstrap does it using one HTML, material uses another.

> you may decide to render a piece of data in a panel, input, table cell, etc.

> analysis:

> There's a huge note with include tag 
>  
> clarifying how include tag is NOT used for purposes listed above. This leads 
> me to believe (but I have not researched it thoroughly) that the question has 
> been asked many times before.

> proposal:

> implement support for passing HTML renders into an included template.

> I see two possible approaches for this:

> Approach 1 template example:

>> {% includeblock template with ... %}
>> {% subblock block1 %}
>>  HTML code
>> {% endsubblock %}
>> {% subblock block2 %}
>>  HTML code
>> {% endsubblock %}
>> {% endincludeblock %}
> block1 and block2 would be blocks defined in template using existing block 
> syntax. I'm not sure if recycling existing block tag would be possible in 
> this context, but I would certainly prefer to avoid new template tag syntax. 
> Basically what this tag would do is first evaluate the subblocks, then 
> override the blocks defined in the template, then render the template.

> Approach 2 template example:

>> {% block block1 as block1_var %}
>>HTML code
>> {% endblock %}
>> {% subblock block2 %}
>>HTML code
>> {% endsubblock %}
>> {% include template with block1=block1_var block2=block2_var %}
> This approach is a bit less structured than the first one, but it requires a 
> lot less modification. Basically it would only add the with parameter to 
> store block render in a variable instead of actually rendering it to output. 
> Possible problem with block inheritance within the template.

> 

> Would either of the above be interesting to include in Django templating code?


> Thanks for your consideration,
> Jure

> 

> --
> You received this message because you are subscribed to the Google Groups 
> "Django developers (Contributions to Django itself)" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to django-developers+unsubscr...@googlegroups.com.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/django-developers/2b317d14-f8e1-c47d-4883-ff06040d1204%40gmail.com
>  
> .

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/5d52e091-9fd9-49da-9e5e-f3a61a22c6e8%40www.fastmail.com.

Re: The blacklist / master issue

[Curtis Maloney]

Just my small contribution to the discussion...

Independent of "social" aspects to the choice of words, the move towards "self 
explanatory terminology" is preferable, IMHO.

As an example, it takes less mental effort or historical context to know what 
an "allow_list" is compared to a "whitelist".

Same argument was involved in changing the terminology we used for replicated 
databases. It made sense then, it makes sense now.

--
Curtis

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/a4ce1855-8974-4eed-9121-99983e8cf742%40www.fastmail.com.

Re: Deprecate HttpRequest.is_ajax

[Curtis Maloney]

On Thu, 21 Nov 2019, at 09:25, Tom Forbes wrote:
> > If Django were to provide a solid API for parsing Accept headers [not as 
> > easy as it sounds] and selecting a preferred response type [based on accept 
> > preference weights] ... would that take care of the bulk of "content 
> > negotiation”?
> 
> > I could imagine a view progressing past the boiler plate [verifying the 
> > target object exists, etc], doing its "work", then checking what response 
> > form to use, and branching there.
> 
> I had a look at how DRF handles parses Accept headers, and it honestly 
> doesn’t look too tricky: 
> https://github.com/encode/django-rest-framework/blob/39876e66070c1d6f97740789d5c6f6a0a3ea06cf/rest_framework/utils/mediatypes.py#L52-L62.
>  The precedence logic is a bit complex, but all in all it’s under ~30 lines 
> of actual implementation code.

Yeah, I expected DRF had this "solved" already. From my own experimentation, 
mapping `cgi.parse_header` over the the "Accept" header value, split by comma, 
gets a usable result; then sort that list by 'q' (defaulting to 1.0) and you 
have your priority.

But knowing that's the right way to parse Accept headers, and asking for match 
or quality measures of your response options, feel like an abstraction Django 
could/should provide.

> But providing the ability to parse accept headers and branch is simple enough 
> to match a lot of the current “is_ajax” usages without too many changes. I 
> don’t see much value in trying to tackle more complex/structured content 
> negotiation handing.

This was my hope - an 80/20 solution that in no way precluded other solutions.

--
C

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/519f9b4e-ad9d-4814-ad6f-c6faff809867%40www.fastmail.com.

Re: Deprecate HttpRequest.is_ajax

[Curtis Maloney]

My reading of this discussion boils down to "if we get rid of is_ajax (a buy-in 
convention nobody can rely on), how do people decide if it's an AJAX call or 
not?". To my mind, the "content negotiation" advocates have it right: HTTP has 
a mechanism for determining what response format is desired.

If Django were to provide a solid API for parsing Accept headers [not as easy 
as it sounds] and selecting a preferred response type [based on accept 
preference weights] ... would that take care of the bulk of "content 
negotiation"?

I could imagine a view progressing past the boiler plate [verifying the target 
object exists, etc], doing its "work", then checking what response form to use, 
and branching there.

--
Curtis


On Wed, 20 Nov 2019, at 21:04, Jure Erznožnik wrote:
> Agree. 

> I understood that the discussion already turned to *"**If it is deprecated, 
> then the question that arises naturally is "What would be the proper/new way 
> of doing it?"**"*. 

> Also, to clarify:

> What I wrote wasn't trying to impose a particular solution. I was just hoping 
> to point out the challenges involved.


> LP,
>  Jure

> On 20/11/2019 02:17, Matemática A3K wrote:
>> 
>> 
>> On Tue, Nov 19, 2019 at 9:20 PM Matemática A3K  
>> wrote:
>>> 
>>> 
>>> On Tue, Nov 19, 2019 at 1:29 PM Jure Erznožnik  
>>> wrote:
 Sorry for barging in like this, but this is actually a problem I have been 
 dealing with quite a bit lately, so:

 In my work I very often have to decide, depending on what's calling, what 
 the rendered output might be. Ultimately I went with DRF and its content 
 negotiation, though even that one - as implemented - sometimes isn't 
 sufficient.

 See, the problem sometimes isn't that you request JSON and then get JSON, 
 request HTML and get HTML.

>>> I think content negotiation is about giving the option to request the 
>>> content in different formats, not rendering different content based on 
>>> which format is requested.
 You also have to cater for exceptions. Maybe a 4xx would return additional 
 objects to insert into the DOM while a 200 would be fine with a JSON or 
 even without data. What about 500?

>>> This (and below) is about how to design a particular API for your needs, I 
>>> think it is out of the scope of the problem discussed. The problem 
>>> discussed is that is_ajax is not a reliable way to determine the origin of 
>>> a request (and then format the content of a response)
>> 
>> (let me try to expand myself a bit so we can refocus)
>> 
>> If it is deprecated, then the question that arises naturally is "What would 
>> be the proper/new way of doing it?" because it is a pattern that have been 
>> applied previously (i.e. 
>> https://docs.djangoproject.com/en/2.2/topics/class-based-views/generic-editing/#ajax-example),
>>  then decorators have been proposed and refactors.
>> 
>> It seems to me that if there is no reliable way of determining it from the 
>> back-end side, then in the end it will be a convention between the front and 
>> the back. This could be a GET parameter, a "ClientWants: JSONOrNothing" 
>> header, or whatever convention you like to make, but not rely on a 
>> convention which seems to be fading out.
>> 
>> You can ensure the actual convention by setting the header manually (as 
>> stated in the is_ajax doc) - as you do with the CSRF token. Another 
>> convention could be better (i.e. "accepts json")
>> 
>> So far, is what the discussion went through to my understanding :)
 

 I'm currently handling this with custom headers and the caller (the 
 browser) tells the server what kind of outputs it can handle in different 
 types of output.

 The server then performs the branching at certain code points, 
 specifically the ones mentioned above. DRF allows me to choose the 
 appropriate renderer. Though I should mention here, that the data is 
 already serialised at that point: sometimes this creates issues for 
 renderers that might desire more information to do their work. Just 
 mentioning that render stages need to be accounted for too. This may not 
 be a problem for core Django as it doesn't have stages.

 Again, sorry, but still hoping this helped in some way.

 


 LP,
  Jure

 

 On 19/11/2019 01:06, Matemática A3K wrote:
> 
> I agree with Adam that it should be deprecated with no replacement.
> 
> The content negotiation is something that should be in but not as a 
> replacement of it, as a general improvement.
> 
> I think there shouldn't be a replacement because "is_ajax" asks whether 
> it came from a ""regular"" browser instead of jQuery and with the content 
> negotiation you ask if the requester accepts a type - which can also lead 
> to errors because the client may also accept other types (no example 
> coming to my mind), and if so, it will lead to undesired behavior.
> 
> The right 

Re: Proposal: security enhancements

[Curtis Maloney]

I think there is certainly a strong case based on "secure by default" to 
include this in core, where it would otherwise face the "it works fine as a 3rd 
party app" barrier to entry.

IMHO it would require, however, that the solutions be sufficiently generic as 
to not enforce an overly restrictive world view.

I, for one, would be very interested to see more details here on what changes 
you propose. Then, at least, we can keep a mailing-list history record of the 
discussion.

--
Curtis


On Tue, 16 Jul 2019, at 12:22, Jonathon Sumner wrote:
> Hi all,
> 
> Sorry for jumping in on an old thread, but I stumbled across James' post 
> after writing a similar wish list. Securityheaders.com (and the Mozilla 
> http-observatory) score an out-of-the-box Django site fairly harshly. With 
> that in mind, me and a colleague put together a very simple package 
> (django-security-headers) to add some headers, package django-csp, self-test 
> against a local http-observatory instance (using django-sslserver), and 
> provide default settings to get a better score.
> 
> I completely agree with Jacob that adding CSP *post facto* can be a 
> minefield, but I think it would promote better practices if Django shipped 
> with secure defaults for CSP, referrer policy, etc. and required the user to 
> turn these settings off for their application.
> 
> Anyway, although I would be a newbie contributor, I would be more than happy 
> to pick up the thread started by James if the senior Django community sees 
> value in it! 
> 
> Cheers,
> Jonathon
> 
> 
> 
> On Tuesday, May 1, 2018 at 11:13:17 AM UTC-4, Jacob Kaplan-Moss wrote:
>> Great ideas, James. I totally agree we shouldn't rest on our laurels, and 
>> love the goal of pushing things forwards. Overall, I'm not sure a DEP is 
>> needed: each of these things is fairly small and tightly scoped, can be 
>> implemented on its own, and provides value independent of the whole. That 
>> seems like a scenario where just a bunch of loosely-related PRs makes the 
>> most sense. Added bonus: many of these things would be fairly easy pickings 
>> for a new contributor. If you wanted, you could delegate/coordinate some of 
>> this, and help us get more folks involved as a bonus.
>> 
>> Some comments on specifics:
>> 
>> On Tue, May 1, 2018 at 12:28 AM, James Bennett  wrote:
>>> Content Security Policy 
>> 
>> CSP is a tricky one. On the one hand, it's a tremendously effective defense 
>> against XSS. But, it's pretty tricky to get right: I've seen several sites 
>> struggle with a proper CSP config for years. It tends to be beyond the grasp 
>> of your classic one- or two-person dev team. When you get it wrong, it 
>> totally hoses your site. 
>> 
>> Most complex sites find they need to operate in report-only mode for a while 
>> and analyze the data before switching to enforce. And that requires a good 
>> reporting/analysis mechanism (something like report-uri.com, or a local 
>> equivalent). 
>> So all that to say: I highly support exploring this more, but it could be 
>> easy to turn CSP into a foot-gun. I don't think it's as easy as just 
>> shipping django-csp and calling it a day; we'd need to make sure it's not 
>> going to cause more problems than it solves.
>> 
>>> Referrer-Policy
>> 
>> +1, this seems like a no-brainer.
>> 
>>> 
>>> Subresource integrity
>> 
>> The jury seems to still be out on the value of SRI (at least, in my corner 
>> of the security community). It has some serious problems with dynamic 
>> assets, and with externally-hosted tools like Google Analytics. I'm not 
>> convinced that the current spec is fully-baked enough for us to support.
>> The admin's a special case since we tightly control what's shipped there; 
>> SRI-for-the-admin would be a nice, if incremental improvement. Preventing 
>> injection attacks in the admin is a very good thing :) 
>> 
>>> 
>>> CORS
>> 
>>  Yup, another no-brainer.
>> 
>>> rel="noopener"
>> 
>> I'm not sure I get this one, might need to see what you come up with to 
>> understand the effect.
>> 
>>> In my magical stretch-goal land, I'd also figure out a way to support
>>> the pyup safety library[8] to scan for a requirements file and any
>>> dependencies in setup.py, and warn if known-insecure versions are
>>> specified.
>> 
>> This seems entirely doable! Of course, grappling with the various options 
>> for dependency management might make this.. less fun 
>> (https://xkcd.com/1987/).
>> 
>> Jacob
> 

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

Re: Python 3.8 and Django 2.2.3 Issues

[Curtis Maloney]

No need to apologise ... we're all human - we can (and do) all make mistakes. 
More importantly - we all learned :)

I believe this is why James was trying to verify which Django (and where) you 
were really invoking.

Problems like this are why a lot of people recommend against installing any 
Python packages globally. Leave system python for the system :)

--
Curtis


On Tue, 16 Jul 2019, at 10:37, Ehigie Aito wrote:
> Ok, before I start let me apologize.
> It seems I am the proverbial boy who cried wolf as I have discovered where 
> the source of the problem. 
> I hope my explanation will help anyone who might make the mistake I was 
> making. 
> Lets start:
> On my development machine, I had Django 1.9.5 installed globally and in 
> Django 1.9.5, in the settings.py file, now MIDDLEWARE is called 
> MIDDLEWARE_CLASSES. Somehow in new Django projects I was creating with Python 
> 3.8 in a virtualenvironment, calling django-admin to create it, Python 3.8 
> wasnt using the django-admin command of the installed Django in the virtual 
> environment but was using that of the globally installed version 1.9.5 which 
> has MIDDLEWARE_CLASSES and on completion, trying to run the project with 
> Python 3.8 caused it to fail. This never happens with Python 3.7 though as it 
> always uses the django-admin of the virtual environment.
> 
> Hope my apology is accepted.
> 
> Thank you all very much for your help.
> 
> Kind regards
> 
> On Monday, July 15, 2019 at 1:25:24 PM UTC+1, Curtis Maloney wrote:
>> 
>> 
>> On Mon, 15 Jul 2019, at 22:13, Ehigie Aito wrote:
>>> Like I said, I didn't say the problem was from Django. I said it's from 
>>> Python 3.8 because creating a project with Python 3.7 doesn't produce this 
>>> traceback.
>> 
>> I think it's quite clear there is an incompatibility with Django and Python 
>> 3.8a1.
>> 
>> I just don't think it's your original conclusion of "Creating a project with 
>> Python 3.8 and Django 2.2.3, the MIDDLEWARE variable in the settings.py file 
>> is changed to MIDDLEWARE_CLASSES"
>> 
>> I'm trying to ask for what _evidence_ you have that this change has happened.
>> 
>> As I said earlier, I think there is a change in how Python 3.8 works that is 
>> causing those checks to fail.
>> 
>> --
>> C
>> 
>> 
>>> 
>>> On Mon, 15 Jul 2019, 13:07 Curtis Maloney,  wrote:
>>>> __
>>>> I think you're making an assumption about the cause of the problem, 
>>>> without evidence.
>>>> 
>>>> Yes, there's an issue shown in that traceback related to middleware, but 
>>>> I've not seen yet why you've concluded it's creating a settings.py with 
>>>> MIDDLEWARE_CLASSES.
>>>> 
>>>> I think the problem is more likely some change in Python 3.8 is making the 
>>>> middleware not initialise, or the detection of what's in the MIDDLEWARE 
>>>> list is not working.
>>>> 
>>>> Can you elaborate on what evidence you have that the combination of Python 
>>>> 3.8 and Django 2.2.3 is generating a settings.py with MIDDLEWARE_CLASSES ?
>>>> 
>>>> --
>>>> C
>>>> 
>>>> 

>>>> --
>>>> You received this message because you are subscribed to the Google Groups 
>>>> "Django developers (Contributions to Django itself)" group.
>>>> To unsubscribe from this group and stop receiving emails from it, send an 
>>>> email to django-d...@googlegroups.com.
>>>> To post to this group, send email to django-d...@googlegroups.com.
>>>> Visit this group at https://groups.google.com/group/django-developers.
>>>> To view this discussion on the web visit 
>>>> https://groups.google.com/d/msgid/django-developers/5a40defe-8a9c-46cc-b2f1-5cf4fea652b8%40www.fastmail.com
>>>>  
>>>> <https://groups.google.com/d/msgid/django-developers/5a40defe-8a9c-46cc-b2f1-5cf4fea652b8%40www.fastmail.com?utm_medium=email_source=footer>.
>>>> For more options, visit https://groups.google.com/d/optout.
>>> 

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

Re: Python 3.8 and Django 2.2.3 Issues

[Curtis Maloney]

On Mon, 15 Jul 2019, at 22:13, Ehigie Aito wrote:
> Like I said, I didn't say the problem was from Django. I said it's from 
> Python 3.8 because creating a project with Python 3.7 doesn't produce this 
> traceback.

I think it's quite clear there is an incompatibility with Django and Python 
3.8a1.

I just don't think it's your original conclusion of "Creating a project with 
Python 3.8 and Django 2.2.3, the MIDDLEWARE variable in the settings.py file is 
changed to MIDDLEWARE_CLASSES"

I'm trying to ask for what _evidence_ you have that this change has happened.

As I said earlier, I think there is a change in how Python 3.8 works that is 
causing those checks to fail.

--
C


> 
> On Mon, 15 Jul 2019, 13:07 Curtis Maloney,  wrote:
>> __
>> I think you're making an assumption about the cause of the problem, without 
>> evidence.
>> 
>> Yes, there's an issue shown in that traceback related to middleware, but 
>> I've not seen yet why you've concluded it's creating a settings.py with 
>> MIDDLEWARE_CLASSES.
>> 
>> I think the problem is more likely some change in Python 3.8 is making the 
>> middleware not initialise, or the detection of what's in the MIDDLEWARE list 
>> is not working.
>> 
>> Can you elaborate on what evidence you have that the combination of Python 
>> 3.8 and Django 2.2.3 is generating a settings.py with MIDDLEWARE_CLASSES ?
>> 
>> --
>> C
>> 
>> 

>> --
>>  You received this message because you are subscribed to the Google Groups 
>> "Django developers (Contributions to Django itself)" group.
>>  To unsubscribe from this group and stop receiving emails from it, send an 
>> email to django-developers+unsubscr...@googlegroups.com.
>>  To post to this group, send email to django-developers@googlegroups.com.
>>  Visit this group at https://groups.google.com/group/django-developers.
>>  To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/django-developers/5a40defe-8a9c-46cc-b2f1-5cf4fea652b8%40www.fastmail.com
>>  
>> <https://groups.google.com/d/msgid/django-developers/5a40defe-8a9c-46cc-b2f1-5cf4fea652b8%40www.fastmail.com?utm_medium=email_source=footer>.
>>  For more options, visit https://groups.google.com/d/optout.
> 

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

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

Re: Python 3.8 and Django 2.2.3 Issues

[Curtis Maloney]

I think you're making an assumption about the cause of the problem, without 
evidence.

Yes, there's an issue shown in that traceback related to middleware, but I've 
not seen yet why you've concluded it's creating a settings.py with 
MIDDLEWARE_CLASSES.

I think the problem is more likely some change in Python 3.8 is making the 
middleware not initialise, or the detection of what's in the MIDDLEWARE list is 
not working.

Can you elaborate on what evidence you have that the combination of Python 3.8 
and Django 2.2.3 is generating a settings.py with MIDDLEWARE_CLASSES ?

--
C

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

Re: Python 3.8 and Django 2.2.3 Issues

[Curtis Maloney]

On Mon, 15 Jul 2019, at 21:36, Ehigie Aito wrote:
> Like I said, in older versions of Django, that variable used to be named 
> MIDDLEWARE_CLASSES, if I create a Django project with Python 3.7 and Django 
> 2.2.3, its MIDDLEWARE but Python 3.8 and Django 2.2.3 its named 
> MIDDLEWARE_CLASSES which on running python manage.py runserver fails. Here is 
> the traceback:

So you're saying that "django-admin startproject" will produce a different 
settings file based on the version of Python?

Can you show us a comparison, please?

> Exception in thread django-main-thread:
> Traceback (most recent call last):
>  File "/usr/local/lib/python3.8/threading.py", line 923, in _bootstrap_inner
>  self.run()
>  File "/usr/local/lib/python3.8/threading.py", line 865, in run
>  self._target(*self._args, **self._kwargs)
>  File 
> "/home/pystar/.local/share/virtualenvs/del-wUbba1cG/lib/python3.8/site-packages/django/utils/autoreload.py",
>  line 54, in wrapper
>  fn(*args, **kwargs)
>  File 
> "/home/pystar/.local/share/virtualenvs/del-wUbba1cG/lib/python3.8/site-packages/django/core/management/commands/runserver.py",
>  line 117, in inner_run
>  self.check(display_num_errors=True)
>  File 
> "/home/pystar/.local/share/virtualenvs/del-wUbba1cG/lib/python3.8/site-packages/django/core/management/base.py",
>  line 436, in check
>  raise SystemCheckError(msg)
> django.core.management.base.SystemCheckError: SystemCheckError: System check 
> identified some issues:
> 
> ERRORS:
> ?: (admin.E408) 'django.contrib.auth.middleware.AuthenticationMiddleware' 
> must be in MIDDLEWARE in order to use the admin application.
> ?: (admin.E409) 'django.contrib.messages.middleware.MessageMiddleware' must 
> be in MIDDLEWARE in order to use the admin application.
> ?: (admin.E410) 'django.contrib.sessions.middleware.SessionMiddleware' must 
> be in MIDDLEWARE in order to use the admin application.

This does look troublesome. Can you show the settings file used?

--
C

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

Re: Python 3.8 and Django 2.2.3 Issues

[Curtis Maloney]

First for everyone reading, it's important to note that Python 3.8 hasn't been 
released yet.

Secondly, a new project in current Django will not emit "MIDDLWARE_CLASSES" in 
a new settings file.

Could you explain how you determined something had "changed" the setting?

Could you also provide details on how manage.py fails? Perhaps a traceback?

--
Curtis


On Mon, 15 Jul 2019, at 20:57, Ehigie Aito wrote:
> Creating a project with Python 3.8 and Django 2.2.3, the MIDDLEWARE variable 
> in the (link: http://settings.py) settings.py  
> file is changed to MIDDLEWARE_CLASSES which makes running this command: 
> '(link: http://manage.py) manage.py  
> runserver' fail. Can anyone kindly try to reproduce this error?
> 

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

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

Re: GDAPS

[Curtis Maloney]

On 6/20/19 7:12 AM, Christian González wrote:
What I need for a good plugin life cycle are methods, callbacks that are 
called when a plugin is "installed" = run the first time, methods for 
enabling/disabling etc.

>
The easiest way would be implementing these methods within the AppConfig 
subclass.


I asked myself why is there a PluginMeta needed? Can't I add those data 
attributes directly to AppConfig?


So my question on you all is: Is it a good idea to merge those data 
deeply with tha AppConfig object? I mean, as a plugin in my sense is 
more or less the same as an app, it won't matter. But deeply inside, I 
feel that there is something wrong done. Separate concerns should not me 
mixed - and I don't know what you want to implement in Django's future 
into AppConfig. Maybe there could be conflicts.


Another way would be implementing the methods too into the PluginMeta 
object.


May I ask for your opinions here?


I would likely keep this interface isolated from the app config, to 
prevent future name clashes.


And a second question: The DJango docs say, that it's not recommended to 
use "default_app_config". But in each and every example, even in the 
tutorials and the Django boilerplate code of "./manage.py startproject 
foo" are NO Appconfigs addressed in INSTALLED_APPS. Nobody does this, right?


How "obligate" is this recommendation, when noone uses it? Should this 
be kept?


I think it's most likely there as a legacy state, in order to reduce the 
burden of upgrading.


I do agree it would be better if we abide by our own recommendations.

--
Curtis

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

Re: GDAPS

[Curtis Maloney]

On 6/17/19 5:47 PM, Christian González wrote:



I've given some thought to this over the years, and what I think we've
somehow missed in settings until now is ... Namespaces!


I can second this from my POV, having "evaluated" a few plugin systems now.



Any plugin or app ought be able to declare its own settings and their
defaults. And ISTM the "obvious" place to do this is in their AppConfig

Except, that may be too late, since we may want/need the settings
before apps are loaded?

So the alternative is for a plugin to declare in its entry points a
reference to its settings declaration. This way, all 3rd party
settings can be gathered, vetted, and applied before having to scan
the INSTALLED_APPS list.


I want to separate these things: Yes, AppConfig is too late, as the
settings.py is already scanned, and INSTALLED_APPS are determined.
That's because Django works this way. I don't recommend Django to
completely change its way of loading apps.



In GDAPS there are 2 ways of adding apps/plugins: 1. simply add it to
INSTALLED_APPS. A GDAPS plugin ins a normal Django app. 2. via
setuptools entry point, like pretix. I therefore added my Pluginmanager
hook, also like pretix. It just finds the plugins and adds them to
INSTALLED_APPS.



But here it is too late. settings.py continues, and *afterwords* all the
apps are scanned for their settings. you can't override them again in
settings.py after that.


I'm a little unclear here.

Is it too late because you want to be able to exclude settings from 
packages that are installed but you don't want "active" in the project?


That you only want 3rd party "settings contributing" plugins to be 
activated when selected?


In which case, doesn't it make more sense to include a plugins.cfg to be 
processed _before_ settings.py to decide?  And if handled well, I expect 
only an exclusion list may be required [but an inclusion list would be 
safer].



What would IMHO clean this problem, would be moving INSTALLED_APPS
outside of settings.py (maybe in a declarative way: yml, cfg file etc.).
Then Django could scan this list, load apps (or do whatever it needs,
scan metadata, check for compatibility, etc.), load their settings, and
*afterwords* run the main settings.py to eventually override some of the
apps' settings globally. This could even be coded with backwards
compatibility, e.g. if installed_apps.cfg is present, use that (and
disallow INSTALLED_APPS in settings.py),  else fall back to
settings.INSTALLED_APPS.



It wouldn't be necessary to make a setuptools entry point for app/plugin
settings. The entry point I would recommend is a "settings.py" for each
app - automatically namespaced or better, with a NAMESPACE = "fooplugin"
- which would enable having 2 plugins using the same namespace (think of
"sub-plugins" of one bigger plugin).


Ah, I think I see now.  You want INSTALLED_APPS to be the definitive 
truth of all apps _and_ plugins. So it's not possible to have a plugin 
that's not also an app?


Sub-plugins opens up the can of works that is dependency resolution.


Now what we'll need is a way to avoid namespace clashes, and a
dev-friendly way to update these settings in settings.py

I would definitely *allow* namespace clashes, as explained above. Like
in partial classes. A "Textprinter" plugin could have 3rdparty
sub-plugins, which could use the same namespace (HTMLProviderPlugin,
MarkdownProviderPlugin etc.)


Yes, I did consider this. I think it's valid that a plugin may override 
another plugins defaults.


But in the end, the projects settings.py should be final.

--
Curtis

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

Re: GDAPS

[Curtis Maloney]

[forgive me for typing as I think... but sometimes it's the best way to 
think ;) ]


On 6/17/19 5:19 AM, Christian González wrote:

Am 16.06.19 um 10:06 schrieb Adam Johnson:
* What do you think are the implications for Django core? Is there 
anything Django could do better to support this and all the other 
plugin systems you’ve looked at? Also I’m totally sure you can 
contribute, it’s not scary and there is a lot of information on 
getting started! See

https://docs.djangoproject.com/en/dev/internals/contributing/


Yes, I'll have a deeper look at the contributing guidelines.
The most parts where I had to struggle within Django were:

* The settings, to let each module provide it's own setting. There is no 
standardized way of having settings saved. I borrowed the 
graphene-django way - which had copied it from DRF ;-)


I've given some thought to this over the years, and what I think we've 
somehow missed in settings until now is ... Namespaces!


Whilst we have namespace-by-prefix (CACHE_*) and namespace-by-dict 
(DATABASES = {} ) when it comes to plugins having their own declared 
settings, we may want to move to something a little more formal.


Any plugin or app ought be able to declare its own settings and their 
defaults. And ISTM the "obvious" place to do this is in their AppConfig


Except, that may be too late, since we may want/need the settings before 
apps are loaded?


So the alternative is for a plugin to declare in its entry points a 
reference to its settings declaration. This way, all 3rd party settings 
can be gathered, vetted, and applied before having to scan the 
INSTALLED_APPS list.


Now what we'll need is a way to avoid namespace clashes, and a 
dev-friendly way to update these settings in settings.py


--
Curtis

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

Re: How to deal with potential Django bugs you come accross

[Curtis Maloney]

Hi Erik,


On 5/13/19 8:22 PM, Erik Stein wrote:


Hello everyone --

 From time to time I come accross a potential bug in Django core, but 
because of a tight schedule don't have the time to dive into it and 
write a proper ticket. How would you suggest to deal with it?



my personal position would be to open a ticket with what information you 
_do_ have, so the discovery is not lost.


The "worst case" is one of the ever efficient Django Fellows comes by, 
tests it out, and closes it as "works as expected".


If you _don't_ log the issue, it _will_ be forgotten about, because 
we're all human. :)



Today e.g.

– Using i18n_patterns with prefix_default_language=True,
– trying to get the frontpage URL without a language given in the URL

works in debug mode, but gives an internal server error without any 
backtrace in production mode.


This was caused by a buggy 404.html template, but probably buggy 404 
templates should give a backtrace, too, and i18n_patterns shouldn't be 
concerned by this anyway.


Certainly a solution worthy of discussion!

Are those notes something which should get into Trac to be investigated 
later?


Absolutely yes!


Thanks for you opinion and guidance,


--
Curtis

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

Re: Proposal to format Django using black

[Curtis Maloney]

On 4/25/19 8:14 PM, James Bennett wrote:

I like Django's style guide.

I like the *idea* of an autoformatter.

I dislike the particular mostly-unconfigurable style Black enforces, and 
I find that several of its rules negatively impact code readability.


So I would be -1 on applying it to Django.



I think this very clearly sums up what I was going to say on this topic, 
if I hadn't already.


I see the benefits [lower barrier to entry, time saving for the Fellows, 
etc], but I don't believe Black is the answer.


Specifically because in my own experience with it (as well as 
demonstrated in this list) there are cases where its style makes code 
significantly harder to read.


And IMHO, the sole purpose of a consistent style (and thus a style 
guide) is to reduce the cognitive load of humans parsing code.


--
Curtis

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

Re: First ASGI pull request is ready for review

[Curtis Maloney]

I cannot find emoji enough to express how much I appreciate the work 
you've put into this :)


--
Curtis


On 4/25/19 6:50 AM, Andrew Godwin wrote:

Hi everyone,

Just wanted to drop a note and say that the first pull request in the 
series needed to enable async in Django is now ready for review: 
https://github.com/django/django/pull/11209


This is a very minimal amount of work to get Django async-safe and 
understanding ASGI as an application interface, but the idea is to land 
this so it's definitely in 3.0, and then work on getting async abilities 
down to views before the 3.0 feature freeze if we can.


Once those two things are down, we can then expand the effort out a lot 
more and have some work for new contributors to get their teeth into, as 
we can then start making all the other parts of Django async-capable as 
a parallel effort.


Reviews and comments on the PR are encouraged; I want to make sure this 
is not going to hurt existing sync Django when it lands, and that it's a 
useful stepping stone towards async in views.


Andrew


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

Re: Why does ModelForm do validation and not Model

[Curtis Maloney]

On 4/17/19 4:55 AM, Aymeric Augustin wrote:

Hello Will,

It's mostly for performance reasons, since validation can be expensive. 


Really? My memory was that it was (a) backward compatibility [model 
validation was added later], and (b) practicality [try catching 
everywhere in your code you save a model, and enforce catching 
validation exceptions there].


Models _support_ validation, but don't _enforce_ it.

--
Curtis

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

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

[Curtis Maloney]

On 4/13/19 10:22 PM, Markus Holtermann wrote:

Thanks for the proposal, Shai. I quite like it.

As discussed at the DCEU sprints I think I'd like to be able to omit the display form of an item and have it auto 
generated from an item's name, i.e. turning "FOO_BAR" into "Foo Bar" (`key.replace("_", 
" ").title()`)



For reference, this is what my project does ( labeled-enums: 
https://pypi.org/project/labeled-enum/ )



--
Curtis

--
You received this message because you are subscribed to the Google Groups "Django 
developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/5a5956f5-84ba-1abf-9dbe-56ba1fbe84dc%40tinbrain.net.
For more options, visit https://groups.google.com/d/optout.

Re: Add to QuerySet method `one` that acts as `first` but without ordering

[Curtis Maloney]

On 4/14/19 8:02 PM, Florian Apolloner wrote:

Hi,

while your arguments for adding `.one` are all good and well, I think 
adding yet another function will add quite some confusion and will make 
arguing harder imo. As a middleground I could imagine adding an 
`ordered=True/False` argument to first to turn off ordering as needed. 
This will also make it easier to argue about it in the docs I think. 
Would that work?




I was thinking the same for most of this thread... I would just 
bike-shed it as, for instance "ensure_ordering=False" or 
"stable_order=False" so you more clearly know what you're asking for.


--
Curtis

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

Re: Proposal to format Django using black

[Curtis Maloney]

So to summarise the discussion so far:

1. automated code formatting will be a great boon - reduce work, lower 
barrier for new committers, reduce work for the fellows, etc.


2. there are issues with git history in doing "the great commit".

3. there are issues with black's formatting choices.


So to address 1:

I am entirely +1 for automated code formatting to take the work out of 
our hands.


Can such a tool be automated into, say, github in a way that doesn't 
create extra commit noise?


To address 2:

I side with those who favour a progressive solution, whereby new code 
only has the new tool applied.


That said, there might be cause to suggest a deadline [perhaps a N.0 
release?] where all remaining code is "cleaned".


And finally 3:

My perspective on the goal of any code formatting tool is this:

When we as developers approach a piece of code, our goal is the 
understand its intent and its implementation of that intent.


In the process of reaching that, we pass through the stages of (a) 
identifying the relevant code, (b) understanding the action of the code, 
and (c) understanding the intent of the code.


Good code formatting choices will remove or reduce the cognitive load in 
(b) and (c).


In my experience with using black [we use it at work], there are 
numerous choices (including those demonstrated in this list already) 
where it can significantly _increase_ the cognitive load in simply 
parsing the code.


As simple as black can make the job of code formatting, I feel I'd 
rather see a different tool that retained the benefits of "trivial code 
reformatting", but still allowed us to retain some of Django's existing 
code formatting rules.


(An interesting [and defensible] choice, we had a module with a lot of 
strings wrapped across lines. black opted to push them onto the same 
line, but NOT to merge them.  This is because in Python prior to 3.7, it 
would have altered the generated AST - one of the guides black uses)


--
Curtis

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

Re: More standard template filters

[Curtis Maloney]

On 4/5/19 8:16 PM, Adam Johnson wrote:

FYI Jinja2 allows (most) python expressions, so this would Just Work(TM):

{{  myvar.startswith("x") }}

Django Template Language has a lot of legacy that prevents this from 
happening, afaiu it would not be possible to move to it.


For "legacy" read "philosophical choices" :)

--
Curtis

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

Re: More standard template filters

[Curtis Maloney]

On 4/5/19 3:06 AM, Collin Anderson wrote:

Hi All,

I use django templates a lot and I always wished there was a 
myvar|startswith:"teststring", myvar|endswith:"teststring" and a 
myvar|contains:"teststring" filter.


It's almost like we need a syntax for calling methods with an argument, 
just like we can with filters.


For example (bring on the sheds for bikes!)

{{ myvar.startswith<"teststring" }}

I instead do stuff like myvar|slice:":10" == "teststring" which is a 
total hack.


Is this something that could be simple and common enough to add to 
django as batteries-included built-in?


Alternatively, I recall some time in the past I may have written a 
"strings" template filter library simply to provide string methods as 
filters...


--
Curtis

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

Re: GSoC 2019 proposal - Easy Ethereum Blockchain integration

[Curtis Maloney]

On 3/15/19 6:42 AM, Diego Lima wrote:

*Introduction*

These days, every single living being has heard of Bitcoin. Some of 
those know that Bitcoin is a cryptocurrency (crypto for short) and, 
within those, a few know that it runs on top of a technology called 
Blockchain.


Be aware that outside of the ponzi-scheme laden world of 
cryptocurrencies, "crypto" is short for "cryptography" ; be careful to 
ensure your audience knows which you mean :)



*My proposal is...*


to develop a library to supplement or support the development of django 
applications with blockchain integration.


My success indicator is whether I have made it easy for anyone to store 
and retrieve information on the blockchain inside their Django code.


This sounds like an interesting and potentially very popular project.

However, AIUI Django's GSoC projects should involve development of 
Django itself.


Is there a reason why your project could not remain a 3rd party library?
This would allow it to develop and release at a pace independently of 
Django's release cadence.


--
Curtis

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

Re: Password reset emails in combination with click tracking do not work with Intelligent Tracking Prevention on Safari for iOS 12 and macOS Mojave

[Curtis Maloney]

On 2/23/19 7:35 AM, Collin Anderson wrote:
I wouldn't mind just rolling back the security fix (or maybe making a 
straightforward way to enable/disable the behavior). We could instead 
encourage people to use  on any links (from the 
password rest page) to untrusted urls.


I don't think it would be controversial to add the rel="noreferrer" part 
to the docs no matter what choice we make about the other functionality.


--
Curtis


On Friday, February 22, 2019 at 5:03:01 AM UTC-5, Henrik Ossipoff Hansen 
wrote:


Just wanted to chime in and say we also experienced this issue. We
ended up having to revert the security fix that was added to the
view in Django just to avoid the flood of customers reporting they
couldn't reset their passwords on our apps anymore - so I'm assuming
this affects a lot of users out there.

torsdag den 21. februar 2019 kl. 14.48.45 UTC+1 skrev Mat Gadd:

You can see this in action yourself using Chrome's Dev Tools.
Open Dev Tools, then their Settings, and turn on "Auto-open
DevTools for popups". Then, click any link in the Gmail web app.
You'll see you go via google.com/url?q=original_url_here
. Since they're doing
this with JavaScript, the links look like they're going to open
the real URL, but they /don't./

On Thu, 21 Feb 2019 at 10:44, Mat Gadd  wrote:

Exactly that, yes. We've disabled all click tracking that we
can, but Gmail has its own redirect which causes Safari's
privacy features to kick in. (Some?) Gmail users are unable
to use the password reset emails.

On Thursday, 21 February 2019 01:03:54 UTC, Philip James wrote:

Mat, are you saying you're seeing Safari still blocking,
even with click tracking turned off, because GMail
itself is inserting a redirect?

PJJ
http://philipjohnjames.com


On Wed, Feb 20, 2019 at 4:46 AM Mat Gadd
 wrote:

We're also now seeing Gmail users complain that the
password reset links don't work, even after we
disabled click tracking. It seems that Google are
inserting their own click tracking into users'
emails, which is… weird?

The markup of links is transformed to the following
(where … is our original URL):

https://www.google.com/url?q=
…">Link text here

Gmail is a *huge* provider of emails, and they make
up around 54% of our user base. Anyone using the
Gmail web app can no longer reset their password
simply by clicking the link in the email.

On Wednesday, 23 January 2019 12:51:22 UTC, Perry
Roper wrote:

It would appear that this affects a large number
of users. We're also experiencing this in the
following configurations.

- Mailgun click tracking enabled + Safari 12.0
on MacOS or any browser in iOS 12
- Clicking the link in the Gmail app or web app
(Mailgun click tracking disabled) + Safari 12.0
on MacOS or any browser in iOS 12.

All iOS 12 browsers and MacOS Safari users using
the Gmail app, or in any email client if the
site they are requesting a password from uses
link tracking.

On Thursday, 22 November 2018 20:43:15 UTC+7,
Mat Gadd wrote:

Hi all,

I raised a ticket
 
regarding
this and was directed here to discuss the
topic. The summary is that the combination
of using click-tracking redirects (which are
popular with a variety of email providers)
with the Django contrib.auth password reset
views does not work in Safari on macOS and
iOS as of the latest major versions.

It took me quite a long time to work out
what was happening, so I wanted to at least
raise a ticket where other people might find
it, but was also hoping to start a
discussion around how else the problem could
be mitigated. 

Re: Extend FAQ with "How do I get Django and my JS framework to work together?"

[Curtis Maloney]

On 2/5/19 1:09 PM, Cristiano Coelho wrote:
Pointing to Django Rest Framework should be more than enough. Anyone 
starting a project with Django and a SPA/JS architecture, will pretty 
much end up with DRF. Correct me if I'm wrong.


It's likely they'd end up with DRF, however there are alternatives.

However, by explicitly listing DRF, it might give the impression it's 
the "blessed" solution by Django...


--
Curtis

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

Re: Extend FAQ with "How do I get Django and my JS framework to work together?"

[Curtis Maloney]

On 2/5/19 11:52 AM, Maciek Olko wrote:

I didn't find this topic being discussed before.



I guess it wouldn't take much to say "Just like any other server-side 
framework that can parse and generate arbitrary content, Django can be 
used to support any Javascript or Mobile app that talks HTTP(S)."


Since Django doesn't care what the client is, so long as it talks HTTP...

--
Curtis

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

Re: IRC Channel

[Curtis Maloney]

On 12/14/18 5:30 AM, Avi Garg wrote:

Does Django have an IRC channel? I am unable to join it if so...


There is #django on the Freenode network.

To join it you will need to create an account on their network - see 
https://freenode.net/ for more details.


--
Curtis

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

Re: A faster paginator for django

[Curtis Maloney]

On 12/5/18 8:30 PM, Saleem Jaffer wrote:

Hi all,

The default paginator that comes with Django is inefficient when dealing 
with large tables. This is because the final query for fetching pages 
uses "OFFSET" which is basically a linear scan till the last index of 
the current page. Does it make sense to have a better paginator which 
does not use "OFFSET".


If this sounds like a good idea, I have some ideas on how to do it and 
with some help from you guys I can implement it.


There are a number of alternatives to this, as well as low-cost 
solutions to improve OFFSET / LIMIT pagination.


By adding an index to the sorting field(s), it can drastically improve 
the "simple" case.


Beyond that, you start getting into cases with more significant 
trade-offs.  I know Matthew Schinckel was recently working on a drop-in 
replacement paginator that used "keyset pagination" 
https://bitbucket.org/schinckel/django-keyset-pagination


There's a lot of published work on this topic, and I'd be very 
interested to see, at least, a library implementing some of these 
alternatives.


At the very least, we could want to ensure the documentation recommends 
indexing on the ORDERing fields, where possible.


--
Curtis

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

Re: Consensus about visual diagrams in the docs.

[Curtis Maloney]

On 11/30/18 7:38 PM, guettli wrote:

I do not care for the strategy, I care for the goal.

How to find clear consensus now?


There is a time honored practice in open source of spurring more 
spirited discussion by presenting a solution, however sub-optimal it may be.


It may not be the accepted solution, but it's far more likely to get 
people to give input than asking for discussion.


[No, I'm not just wrapping up "patches welcome" - this is a general 
observation in life. It's just more openly recognised in OSS :) ]


--
Curtis

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

Re: Question regarding a possible bug

[Curtis Maloney]

On 11/23/18 11:10 AM, bernie2004 wrote:

I am pretty but not 100% sure i found a bug in 2.1.2.

Would it be appropriate to post a description of what i think i found to 
this mailing-list before starting a ticket or is there a better place 
for posting things like that?


Opening a ticket directly is fine, so long as it's not a security 
related issue.


The Django Fellows do an excellent job of curating and addressing 
issues, and the Trac helps keep a coherent history of discussion of the bug.


Just go https://code.djangoproject.com/ and follow the instructions :)

--
Curtis

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

Re: QuerySet.iterator together with prefetch_related because of chunk_size

[Curtis Maloney]

On 10/12/18 10:51 AM, charettes wrote:

Hello Tobias,

 From my understanding the introduction of chunk_size doest't help here.

The fundamental reason why iterator() cannot be used with 
prefetch_related() is that the latter requires a set of model instance 
to be materialized to work appropriately which chunk_size doesn't 
control at all.


In other words chunk_size only controls how many rows should be fetched 
from the database cursor and kept into memory at a time. Even when this 
parameter is used, iterator() will only materialize a single model 
instance per yield.


I inferred from the original post they were suggesting to do a set of 
prefetch_related "filling" queries _per_ _chunk_


It wouldn't be as efficient as the 1+P (where P is number of prefetched 
relations) of a normal prefetch_related, but at 1+(P x Chunks) it would 
_probably_ be more efficient than the 1+(P x N-rows) it would otherwise 
be [or worse!]


--
Curtis

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

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

[Curtis Maloney]

On 10/02/2018 09:42 AM, martin_x wrote:

Hi there,

Thanks for making Django a great framework for starters :D

Recently my team have run into problems when trying to remove a database 
column from the model without stopping our Django server, below is the 
timeline:


There have been processes developed for addressing this, but they're 
quite involved.


You need to ensure any field the current running codebase knows about 
never disappears. So, the process of removing a field must be spread 
across multiple code deployments


The first setting it nullable [or with a "harmless" default] so when the 
new code inserts new rows the DBMS doesn't complain.


The next deploy can then drop the field, as Django no longer interacts 
with it.


Either way, you're still likely to encounter a full-table exclusive lock 
whilst the DBMS rewrites the table to no longer include that field.


Hope this helps some.

--
Curtis

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

Re: RFC732 (a.k.a. brotli) support

[Curtis Maloney]

On 09/14/2018 08:24 PM, Aymeric Augustin wrote:

Hello,

I would like to be sure that Brotli is actually faster. In my 
experience, while decompression is fast, compression can be extremely slow.


https://blogs.akamai.com/2016/02/understanding-brotlis-potential.html

It's primarily tuned for fast decompression, making it especially good 
for offline compression (i.e. compression of static assets on deploy)


At lower levels it can get as good compression as gzip, but much faster, 
or similar speed for better results. IIRC the general "wisdom" is that 
brotli at level 4 is typically faster than gzip, and gives better results.


I like the general idea of an "extensible" or plugin driven 
Content-Encoding handler, though it would require at least some 
preferencing engine so you can influence which algorithm is chosen by 
(a) browser supported, (b) local preference, and (c) content type.


--
Curtis

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

Re: Not Creating test DBs with PG backend

[Curtis Maloney]

On 08/28/2018 08:33 PM, Tim Graham wrote:

Why is a new option needed? Why can't --keepdb be used for this use case?


Because that would be different behavior.

If you can convince me that using --keepdb is a solution, then I will 
use your argument to say that --keepdb should be on always.


What I'm looking to offer users is to create and clean up objects in the 
test DB, separate from create/drop test DB.


However, I want to do this in a way that doesn't weaken the existing 
protection for "Oops, we're trying to use a test DB that already 
exists... did you make a mistake?  We don't want to trounce real data."


--
Curtis

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

Not Creating test DBs with PG backend

[Curtis Maloney]

Greetings,

one problem that turns up more and more frequently, it seems, is that 
someone is trying to run tests but can't because of the following scenario:


1. The user they connect to the DB using a role that does NOT have 
permission to create a DB


2. Django's PG adapter, when keepdb is not set, will attempt to create 
the DB


3. If the create fails, and NOT with the error of "duplicate DB name", 
KABOOM.


The error they get is that the user does not have permission to create 
DBs, since permissions are checked before testing if the name exists.


Instead, I'm trying to leverage the existing _database_exists check used 
by keepdb.


My initial attempt checked if the DB exists and, if it does, issues a 
"DROP OWNED BY CURRENT_USER;" instead of calling _execute_create_test_db.


Of course, this failed the tests, and rightly so. This obliterates the 
protection of connecting to the wrong DB... and, in fact, makes that 
mistake far FAR more damaging.


So I'm looking for input on what might be the best direction moving forward:

1. wrangle a new option to say "use existing" ... to allow using an 
existing DB if it exists.


2. prompt the user to confirm they want to use the existing DB... and 
perhaps prompt a second time to confirm they want to DROP OWNED BY...


3. some other option?

The first option, at least, will possibly require more invasive changes, 
since higher levels of the code make assumptions about 
_execute_create_test_db and when it will succeed / raise exception.


--
Curtis

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

Re: A Django Async Roadmap

[Curtis Maloney]

In general this sounds like a tremendously useful tool... I'm caused to 
wonder, however... what, if any, are the performance impacts?


--
Curtis



On 08/21/2018 08:10 AM, charettes wrote:

Regarding the lazy loading of deferred fields and foreign keys
I wanted to mention I've been working on a third-party application
that allows overriding the default behavior[0].

The project works by tainting objects retrieved from "sealed"
querysets and having fields descriptors lookup whether or not
the object is "sealed" on attribute access and warn the developer
about it if it's the case. Warnings can be elevated to errors
using `filterwarnings` when deemed appropriated (e.g. CI, staging).

It has been an useful tool to assist in figuring out where
`select_related()` and `prefetch_related()` should be used
to adjust complex projects database interactions.

I assume a similar pattern could be used to mark objects retrieved
from `QuerySet.__aiter__` to prevent non-async queries from being
performed on attribute accesses; on `Model._state.async = True`
field descriptors would error out.


Cheers,
Simon

P.-S.

While the project might look complex most of the code takes care
of the delicate tasks of replacing fields descriptors once models
are configured which could be significantly simplified if it was
part of Django core.

[0] https://github.com/charettes/django-seal
Le samedi 9 juin 2018 02:30:59 UTC-4, Josh Smeaton a écrit :

I think most of what you've laid out sounds great and that pursuing
async Django is in the projects best interests. The sync to async
and async to sync wrappers that have come out of channels give me
much more confidence that this project is doable in a reasonable
amount of time with backwards compatibility being preserved.

The only real concern I have at the moment is around your comments
regarding on demand foreign key traversal. If existing code running
synchronously is going to be impacted, that's going to be very
difficult for a lot of people. If it's only asynchronous traversal
that'll have issues, then I have no real concern, as on demand
foreign key fetching is usually a bug anyway.

Having a brief read through the psycopg asynchronous docs[0], it
looks like a number of features will be impossible or troublesome to
use, like transactions, executemany, and named cursors (.iterator()
with server side cursors). We'd also need to investigate how
pgbouncer would work in async mode, as most large sites using
postgres are also using pgbouncer. I would expect support can only
further improve, especially if there is a driver like django
pushing. Fallback would just be to run inside a thread pool though,
so it's not a blocker for the rest of the proposal.

Very exciting times ahead!

[0] http://initd.org/psycopg/docs/advanced.html#asynchronous-support


On Monday, 4 June 2018 23:18:23 UTC+10, Andrew Godwin wrote:

Hello everyone,

For a while now I have been working on potential plans for
making Django async-capable, and I finally have a plan I am
reasonably happy with and which I think we can actually do.

This proposed roadmap, in its great length, is here:

https://www.aeracode.org/2018/06/04/django-async-roadmap/


I'd like to invite discussion on this potential plan - including:

  - Do we think async is worth going after? Note that this is
just async HTTP capability, not WebSockets (that would remain in
Channels)

  - Can we do this in a reasonable timeframe? If not, is there a
way around that?

  - Are the proposed modifications to how Django runs sensible?

  - How should we fund this?

There's many more potential questions, and I really would love
feedback on this. I'm personally pretty convinced that we can
and should do this, but this is a decision we cannot take
lightly, and I would love to hear what you have to say.

Andrew

--
You received this message because you are subscribed to the Google 
Groups "Django developers (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send 
an email to django-developers+unsubscr...@googlegroups.com 
.
To post to this group, send email to django-developers@googlegroups.com 
.

Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/0b3b92b9-eee7-4909-82d6-c0138e8b5760%40googlegroups.com 

Re: HTML5 and XHTML5 documents

[Curtis Maloney]

On 08/17/2018 06:50 PM, Nils Fredrik Gjerull wrote:

think, however, that it is more clear if we give it a value. By the way,
the syntax is not new it is the old syntax from HTML4. I have spent
quite some time cleaning up ill-formed HTML4.


One of the more significant differences between the advent of XHTML and 
now, is that HTML5 introduced standard rules for how to deal with 
"invalid" markup, meaning its handling in browsers became consistent.


XHTML was a great move to allow a shift to browsers only accepting valid 
markup, but it never happened -- in part because IE just wouldn't play 
along.


So a softer solution was found - moving to HTML5 with defined failure 
modes and handling.


Currently, ISTM the only thing standing in the way of you using Django 
for generating valid XHTML is the form widgets, in which case I suspect 
writing your own widget templates would be far less work for everyone 
involved.


You could also provide them, quite trivially, as a 3rd party app for 
other people facing the same issues as you.


--
Curtis

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

Re: Django and Cython

[Curtis Maloney]

On 08/02/2018 07:02 AM, Daniel Anechitoaie wrote:
I'm looking at frameworks like https://vibora.io/ that make use of 
Cython to greatly improve the performance and I'm just wondering if 
something like this would work with Django?
Was there any discussion (taken into consideration) about using Cython 
to boost the performance of certain aspects of the framework?

Would it help make it faster?

I really love Python and Django for me is the best web framework out 
there, but you have to notice how fast other frameworks from other 
programming languages are.

Would using Cython help boost the performance?


There was a discussion some time ago about perhaps cythonising some of 
the template engine and other select parts of Django.  Someone did some 
eexcellent independant work on this, and you should be able to find 
their results in the mailing list archives.


However, I think you'll find the common wisdom on speeding up Django is 
to reach for tools like PyPy, which can provide hot-spot JIT 
compilation, thus focusing performance work on the parts where your app 
needs it.


Further to that, my own experiences of optimising and scaling django 
have shown often the performance bottlenecks are not where you expect.


As anyone in the industry will tell you, beware of benchmarks not 
testing what you _actually_ do.


One time we got a dramatic improvement in site resource usage by moving 
a user setting (like preferred language] into a cookie instead of the 
user session. This allowed many requests to never access the session 
store at all, avoiding a round-trip.


Another time, a site trebled in throughput (on average) by simply 
upgrading Django.  As is often the case, a smarter algorithm (in this 
case, in how QuerySets made copies) will yield improvements orders of 
magnitude more than minor optimisations.


As has been mentioned in other posts, async IO is often viewed as a 
solution to performance problems.  This is a furphy; asyncio can help 
improve resource utilisation when you have an IO-bound workload.


It can allow fewer processes to scale more readily to consume more CPU 
by avoiding blocking on IO.  It's trues that the majority of web sites 
are IO bound [waiting for DB, disk, or even other web sites].


However, this doesn't necessarily make each individual request any 
faster - in many cases, it can actually be slower.


As is always the case with improving performance, measurement and 
careful analysis are requried.


--
Curtis

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

Re: A Django Async Roadmap

[Curtis Maloney]

On 06/05/2018 07:54 AM, Tom Forbes wrote:

Are the proposed modifications to how Django runs sensible?


I had a few random thoughts while reading your proposal:

I think getting rid of the related field references could be a big issue 
here and cause a lot of headaches for existing applications. Could we do 
this in a backwards compatible way at all? I wonder if PEP 567 
 could help here, could we 
define some kind of ‘Django async context’ and do different things 
depending on if this is true or false?


One thought about the related field stuff... whilst having it makes it 
easy to get started, any site at scale will sensibly obviate their need 
in almost all cases by using select_related, for performance reasons.


--
C

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

Re: Spaces between argument separator and argument in template filter generate error

[Curtis Maloney]

On 05/31/2018 06:39 PM, oli...@kidsnote.com wrote:

Are there any reasons that not allow spaces between separator and arg?


My first thought would be that it starts making the syntax looser, 
meaning more things that are currently error cases would be accepted as 
valid.


Which means mistakes will no longer raise errors.

--
Curtis


2018년 5월 31일 목요일 오전 11시 41분 22초 UTC+9, oli...@kidsnote.com 님 
의 말:


In the template filter system now,

spaces between augment separator and augments generate error.
For example, the following template code generates the following error.

{{ value | filter: "arg"}}

TemplateSyntaxError at /
Could not parse the remainder: ': "arg"' from 'value | filter: "arg"'

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



What do you think of this ticket?

--
You received this message because you are subscribed to the Google 
Groups "Django developers (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send 
an email to django-developers+unsubscr...@googlegroups.com 
.
To post to this group, send email to django-developers@googlegroups.com 
.

Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/131b5095-c5b7-4492-92fa-e58912ac842a%40googlegroups.com 
.

For more options, visit https://groups.google.com/d/optout.


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

Re: A more useful list of common passwords?

[Curtis Maloney]

On 03/30/2018 07:05 PM, Adam Johnson wrote:

This new file sounds good to me.

Whilst you're at it, what is the new file size?


I downloaded the gist, took only column 3 (the actual passwords) and 
gzipped it, it came to 81K over the existing 3.8K. Uncompressed that's 
163K over 7.1K.


Still a tiny drop compared to a running system... but something worth 
keeping an eye on.


A quick look at the code shows, of course, that you can specify your own 
file, so IFF this new file is rejected, it can at least be easily 
offered and used.


It would probably warrant a smarter checking algorithm over the current 
one, where the validator loads the whole file into memory on 
initialization (and doesn't share it between instances).


The current solution is storing the strings in a set, so membership of 
strings in a set _should_ be fairly efficient.


--
Curtis

OOI have you seen https://github.com/ubernostrum/pwned-passwords-django/ 
, which uses Troy Hunt's massive API for all leaked passwords ?


The joy of pluggable validators is... people can choose their level of 
strictness :)


--
C

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

Re: A more useful list of common passwords?

[Curtis Maloney]

By which I mean... hi Brenton! Great to see you being active again :)

It's great you've taken the time to do this, and the benefits are very 
clear [improved security], but what are the costs?


Whilst you're at it, what is the new file size?

--
Curtis



On 03/30/2018 04:26 PM, Curtis Maloney wrote:

What sort of performance impact is this having over the existing list?

What's the additional memory load, if any?

--
Curtis


On 03/30/2018 04:24 PM, Brenton Cleeland wrote:
Three years ago Django introduced the CommonPasswordValidator and 
included a list of 1,000 passwords considered to be "common". That 
list was based on leaked passwords and came from xato.net[1].


I'd like to update the list to

a) be from a more reliable / recent source
b) be larger and more in line with the NIST recommendations

Security researcher Troy Hunt has published a massive list of leaked 
passwords, including frequencies on Have I Been Pwned[2]. The top 
20,000 of which are available in a gist from Royce Williams[3], 
including the frequency, md5 hash and plain text password.


Interestingly there's 27 passwords in the Django list that aren't in 
the HIBP list. I'd post them here but they're mostly short and not 
safe for work.


I've created a ticket for the increase in size[4] but wanted to check 
in and make sure this is something django-developers thinks is valuable.


Cheers,
Brenton

[1]: 
https://web.archive.org/web/20150315154609/https://xato.net/passwords/more-top-worst-passwords/#.Wr3H1chxV25 


[2]: https://haveibeenpwned.com/Passwords
[3]: 
https://gist.github.com/roycewilliams/281ce539915a947a23db17137d91aeb7

[4]: https://code.djangoproject.com/ticket/29274

--
You received this message because you are subscribed to the Google 
Groups "Django developers (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send 
an email to django-developers+unsubscr...@googlegroups.com 
<mailto:django-developers+unsubscr...@googlegroups.com>.
To post to this group, send email to 
django-developers@googlegroups.com 
<mailto:django-developers@googlegroups.com>.

Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/0a215878-9d3f-4446-a018-602694f54904%40googlegroups.com 
<https://groups.google.com/d/msgid/django-developers/0a215878-9d3f-4446-a018-602694f54904%40googlegroups.com?utm_medium=email_source=footer>. 


For more options, visit https://groups.google.com/d/optout.




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

Re: A more useful list of common passwords?

[Curtis Maloney]

What sort of performance impact is this having over the existing list?

What's the additional memory load, if any?

--
Curtis


On 03/30/2018 04:24 PM, Brenton Cleeland wrote:
Three years ago Django introduced the CommonPasswordValidator and 
included a list of 1,000 passwords considered to be "common". That list 
was based on leaked passwords and came from xato.net[1].


I'd like to update the list to

a) be from a more reliable / recent source
b) be larger and more in line with the NIST recommendations

Security researcher Troy Hunt has published a massive list of leaked 
passwords, including frequencies on Have I Been Pwned[2]. The top 20,000 
of which are available in a gist from Royce Williams[3], including the 
frequency, md5 hash and plain text password.


Interestingly there's 27 passwords in the Django list that aren't in the 
HIBP list. I'd post them here but they're mostly short and not safe for 
work.


I've created a ticket for the increase in size[4] but wanted to check in 
and make sure this is something django-developers thinks is valuable.


Cheers,
Brenton

[1]: 
https://web.archive.org/web/20150315154609/https://xato.net/passwords/more-top-worst-passwords/#.Wr3H1chxV25

[2]: https://haveibeenpwned.com/Passwords
[3]: https://gist.github.com/roycewilliams/281ce539915a947a23db17137d91aeb7
[4]: https://code.djangoproject.com/ticket/29274

--
You received this message because you are subscribed to the Google 
Groups "Django developers (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send 
an email to django-developers+unsubscr...@googlegroups.com 
.
To post to this group, send email to django-developers@googlegroups.com 
.

Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/0a215878-9d3f-4446-a018-602694f54904%40googlegroups.com 
.

For more options, visit https://groups.google.com/d/optout.


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

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

[Curtis Maloney]

On 03/30/2018 08:57 AM, Ryan Hiebert wrote:
It's a subtle difference between how a single filter works and two 
filters work together over to-many relationships. Here's a writeup that 
I found helpful: 
https://blog.ionelmc.ro/2014/05/10/django-sticky-queryset-filters/


It's also addressed in the documentation:

https://docs.djangoproject.com/en/2.0/topics/db/queries/#spanning-multi-valued-relationships

--
Curtis

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

Re: GSoC 2018

[Curtis Maloney]

On 03/17/2018 08:18 PM, Manasvi Saxena wrote:

Hello Sir,

On Saturday, March 17, 2018 at 2:23:45 PM UTC+5:30, Curtis Maloney wrote:

On 03/17/2018 07:37 PM, Dmitriy Sintsov wrote:
 > Hi!
 >
 > Template languages are my favorite topic in programming.

Having written a few template engines myself... I guess it's high on my
list too :)

 > If you implement html library yourself, it is much better to
define tags
 > not as functions but as classes with base Tag class which has
properties
 > for tag name, attributes and the nested list of tags. Such way
you will
 > re-implement DOM, although it is already available in lxml library.
 >
 > So maybe it's a better idea to figure out whether lxml can be
used as
 > template engine for Django, because it can load source html into
nested
 > structures via binary optimized code. It should be cleaner and
faster
 > than manual composition of html in Python code.

Now, I like this idea as a line of inquiry.

Despite the Django Template Language being explicitly designed to _not_
use HTML syntax [like so many before it did] so as (a) not create
torturous syntaxs, and (b) not restrict it to just HTML...

I think for the case of knowingly generating HTML, using lxml opens the
door to:
1. ensuring valid markup
2. faster processing [maybe?]
3. minifying on the fly -- readable templates, minimal output.

-- 
Curtis



I was trying to explain the exact pros you have stated above and those 
were the main reason behind how I come up with this idea.
Can you guide me how I should move forward with my idea in order to 
increase my chances of getting selected in spite of that fact that it's 
rejected by the members of Django core team?


Well, you should probably look at past examples of such things, like TAL 
for the server side, and ... just about every JS framework of today 
(svelte, Vue, Knockout, etc :)


lxml should make it easy to parse, iterate, walk, mutate the DOM tree... 
now you need to determine a syntax.


--
Curtis

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

Re: GSoC 2018

[Curtis Maloney]

On 03/17/2018 07:37 PM, Dmitriy Sintsov wrote:

Hi!

Template languages are my favorite topic in programming.


Having written a few template engines myself... I guess it's high on my 
list too :)


If you implement html library yourself, it is much better to define tags 
not as functions but as classes with base Tag class which has properties 
for tag name, attributes and the nested list of tags. Such way you will 
re-implement DOM, although it is already available in lxml library.


So maybe it's a better idea to figure out whether lxml can be used as 
template engine for Django, because it can load source html into nested 
structures via binary optimized code. It should be cleaner and faster 
than manual composition of html in Python code.


Now, I like this idea as a line of inquiry.

Despite the Django Template Language being explicitly designed to _not_ 
use HTML syntax [like so many before it did] so as (a) not create 
torturous syntaxs, and (b) not restrict it to just HTML...


I think for the case of knowingly generating HTML, using lxml opens the 
door to:

1. ensuring valid markup
2. faster processing [maybe?]
3. minifying on the fly -- readable templates, minimal output.

--
Curtis

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

Re: Cache backends and thread locals

[Curtis Maloney]

I believe I'm (at least partly) responsible for this change, and the short 
answer is basically "historically memcache client libs have been awful with 
threading".

This may have improved, but in order to avoid a whole slew of potential 
problems (with memcache and other backbends) I copied the pattern used by 
database connections.

That said, I like your idea of sharing the connection pool between threads. It 
would mean at worst we'd wind up where we are.

--
Curtis

On 8 March 2018 06:53:57 GMT+11:00, Nicolas Le Manchet  
wrote:
>Hello,
>
>Thanks to commit f02dbbe1ae[0], the Memcached cache backend using
>pylibmc can now keep connections open between requests. Establishing a
>new TCP connection is rather expensive and each saved round trips to
>the cache server allows to shave a few ms of response time.
>
>It appears that in a multithreaded environment we could improve the
>situation even more by letting threads share the same `PyLibMCCache`
>instance.
>
>Currently in Django, each thread asking for a cache backend gets its
>own personal Backend object[1], thus each thread also get its own
>connection pool to memcached. After a few requests the process ends up
>opening as many connections to memcached as there are threads.
>
>If instead we allowed the connection pool to be shared between threads,
>connections would only be opened when necessary (other threads using
>all the pooled connections).
>
>Now the important questions. Why do we have thread locals in the first
>place? Can we share Backend instances between threads?
>
>After looking at the code of all cache backends I feel that nothing
>prevents dropping threadlocal altogether. Did I miss something?
>
>[0]
>https://github.com/django/django/commit/f02dbbe1ae02c3258fced7b7a75d35d7745cc02a
>[1]
>https://github.com/django/django/blob/master/django/core/cache/__init__.py#L64
>-- 
>Nicolas Le Manchet
>
>-- 
>You received this message because you are subscribed to the Google
>Groups "Django developers  (Contributions to Django itself)" group.
>To unsubscribe from this group and stop receiving emails from it, send
>an email to django-developers+unsubscr...@googlegroups.com.
>To post to this group, send email to
>django-developers@googlegroups.com.
>Visit this group at https://groups.google.com/group/django-developers.
>To view this discussion on the web visit
>https://groups.google.com/d/msgid/django-developers/1520452437.1399418.1295099912.51D6677F%40webmail.messagingengine.com.
>For more options, visit https://groups.google.com/d/optout.

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

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

Re: “Abusing BinaryField” warning about binary files in DB

[Curtis Maloney]

On 02/26/2018 08:30 AM, Antoine Pietri wrote:

Can I suggest replacing the warning by something like this?:


Although you might think about storing files in the database, consider that
it might be a bad design choice. This field is not a replacement for proper
static files handling.

That said, there might be cases where you do want the guarantees that the
database offers you for binary files. Be sure to be aware of the
trade-offs[1] before you decide to do so.
[1]: https://wiki.postgresql.org/wiki/BinaryFilesInDB 




As discussed on IRC, I think the wording here is a bit weak... "it might 
be" probably ought be "it is probably".



--
Curtis

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

Re: Thoughts on diff-based migrations with django?

[Curtis Maloney]

Hi,

I must say your idea intrigues me... and I'd certainly like to discuss 
it further.


The first thought that comes to mind is how would such a system handle 
data migrations?


Being able to leap from one schema state to another is great, buy 
typically in the life-cycle of a reusable app it's required to also 
migrate old data into new schema.


This also happens within project-specific apps.

--
Curtis


On 02/20/2018 05:05 PM, djrobstep wrote:

Hi all,

Some thoughts on schema migrations that may interest you. By way of 
background, I'm the author of migra 
(https://github.com/djrobstep/migra), a schema comparison/diff tool for 
Postgres.


I initially wrote this tool because I wanted to be able to generate 
migration scripts automatically, without needing historical migration files.


It means that you can do things like sync your database to your models 
mostly automatically, and also explicitly test for a matching schema. 
Instead of a chain of migration files you only ever need to keep track 
of one, containing any pending changes).


I've used this approach with success on a number of projects now, and it 
seems to work pretty well. I also talked about this approach to 
migrations at the most recent PostgresOpen 
(https://www.youtube.com/watch?v=xr498W8oMRo).


The downside of this approach is that it's slightly more operationally 
complex (you need have a temporary copy of your production schema 
available for comparison purposes, typically a --schema-only dump file) 
and also that it's postgres-only at this point. It's also conceptually 
quite different to the typical Django/Rails style of migrations which 
represents a barrier to entry.


In spite of this, I think doing migrations this way has some compelling 
advantages, that are relevant to users of Django.


I'm interested in your opinions on this topic as Django developers. What 
do you think? Is it something worth offering as an option for managing 
Django migrations? If your feelings are positive, I'm happy to take a 
look at extending the code accordingly.


--
You received this message because you are subscribed to the Google 
Groups "Django developers (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send 
an email to django-developers+unsubscr...@googlegroups.com 
.
To post to this group, send email to django-developers@googlegroups.com 
.

Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/5f84157b-071e-42c3-90dd-6f9e3df48ab3%40googlegroups.com 
.

For more options, visit https://groups.google.com/d/optout.


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

Re: Google Summer of Code 2018

[Curtis Maloney]

On 02/13/2018 09:23 PM, askpriya...@gmail.com wrote:

Hello !

What is the policy regarding NoSQL datastores being used as backends ? I think 
adding support for something like MongoDB might be good idea.


Could you elaborate on why you think it would be a good idea?

I believe every other time the discussion has come up the following 
points have been made.


1. "NoSQL" is not a DB category, it is an anti-category
2. Because of there there is no common data model, or query languages.
3. If you limit yourself to just document stores, there is still no 
common query language [but this can be hidden by code]
4. Document stores are a really really bad fit for the ORM, as it's 
designed for the relational model, not document model.
5. A better approach would be to develop an ODM, which is sufficiently 
compatible with the ORM you can provide similar tools like ModelForms 
and ModelAdmin, as well as GCBV.


If I missed anything, I'm sure someone else will remind me.

[Also... why is it always MongoDB, instead of something with a solid 
reputation of reliability and performance?]


--
Curtis


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

RFC : Migration Adapters

[Curtis Maloney]

Hey,

I've recently written an app that implements a closure tree using 
views... and in order to make the migrations work as needed you must 
manually add an entry to the migrations.


Another friend of mine, a recent django convert, was wanting a way to 
add to the migration script generated when creating certain tables...


And today I realised I wanted quite involved control of how migration 
actions are written for the idea I was working on...


What I conceived was what I call a MigrationAdapter, which controls at 
least how create/modify/delete actions for a given object are generated.


I've started looking into the migrations code, and it appears the steps 
are very much hard-coded [and, it appears, with much painfully learned 
good reasons]...


Anyone with more familiarity with the migration machinery got input on 
if this is feasible?


--
Curtis

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

Re: Don't assume that missing fields from POST data are equal to an empty string value.

[Curtis Maloney]

On 01/22/2018 06:03 PM, Anupam Jain wrote:
Wow - I just realised that we have been losing data for sometime on our 
web platform since there were some fields in the ModelForm that were 
hidden and not being sent. They were all being overwritten as blank 
values. Thank God, we use django-reversion to track changes. Will take 
us sometime to recover the data though.


Just something vaguely related that this post prompted in me ...

My general guide is... if you're using hidden fields, then you're 
probably doing it wrong.


There are very few valid cases for passing data in hidden fields. In 
most cases you really want to exclude the fields from the model. This 
has the added benefit of protecting from a malicious user who edits the 
values of the hidden fields.


A ModelForm will _only_ update fields on the model that it has fields 
for. No matter what the user - or your code [such as clean functions] - 
manages to get into the cleaned_data dict.


--
Curtis

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

Re: GLOBAL_PERMS

[Curtis Maloney]

So, I've taken a different approach, following Markus' idea, and added 
"app_label" to Permission.


I probably still need to add a check to ensure you don't set app_label 
_and_ content_type, but that can wait for now.


You can now define new app-level permissions on the app's 
AppConfig.permissions [optional].


I've also implemented a "create_app_permissions" function which will ... 
do just that.  Call it whenever you like :)


Basic tests are working, as well as added ones.

No documentation or changelog as yet...

--
C

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

Re: GLOBAL_PERMS

[Curtis Maloney]

On 12/31/2017 11:51 AM, Josh Smeaton wrote:


- I dislike the seetings approach of GLOBAL_PERMS and would rather see
   users writing explicit data migrations.


I don't favour either setting or migration based perms, but if you're 
going to go with migration based, then please also consider adding a 
first class permission type, to avoid the ceremony of creating 
forward/back functions, and having to remember the model layout for 
Permissions.


Something like:

migrations.CreatePermission(app_label, permission_name)


Certainly, if we go the data migration path I'd go this way...

--
C

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

Re: GLOBAL_PERMS

[Curtis Maloney]

On 12/31/2017 12:50 AM, Markus Holtermann wrote:

Thanks Curtis,

I had a quick look. Some thoughts (in no particular order):

- IMO a nice idea. I've attached all model independent permissions to
  the user model in the past to work around the limitation.


Certainly a good one I'll remember to mention on #django next time it 
comes up :)



- How do you envision 3rd party apps handling their own permissions? If
  I install 2 independent apps and both use a permission can_do_foo, one
  can't distinguish between those two, right?


I had considered this, and yes would much rather some sort of per-app 
permissions.  For some years now the model-centric view many people take 
of their designs has bothered me.



- What do you think about adding an 'app_label' to the Permission model
  that can be used instead of a content type. That could solve the issue
  from the previous point? content_type and app_label would be
  exclusive?


Oh, absolutely!  A solid mechanism for per-app permissions would win me 
over in a second.


Would we keep the existing syntax of "{scope}.{codename}" and fallback 
scope from model to app label?  Or have a different syntax for app-level 
permissions, like "{app_label}:{codename}"?


And if so, how would that be handled in templates?

Also would we add get_app_permissions() to the auth API?


- I dislike the seetings approach of GLOBAL_PERMS and would rather see
  users writing explicit data migrations.


I was specifically aiming for something almost as simple as the 
per-model custom permissions.


Could we add it to AppConfig?  Feels like the right place to me.

--
C

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

GLOBAL_PERMS

[Curtis Maloney]

So, after a discussion with a new user on #django today I decided to 
make "permissions not bound to models" a first-class feature.


So I've written a simple patch that is in 
https://github.com/django/django/compare/master...funkybob:feature/cjm/global_perms?expand=1


Basically:

1. Allow Permission.content_type to be null

2. Adjust everything else to cope with that

3. Add new setting "GLOBAL_PERMS"

4. Teach create_permissions to honor that.

5. Write minimal test and documentation.

Would welcome further input.

--
C

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

Re: about ticket 28588- has_perm hide non-existent permissions

[Curtis Maloney]

On 09/25/2017 08:56 PM, Dan Watson wrote:
Seems like maybe it would be more helpful if has_perm logged a note 
about the permission not existing (probably only in debug), rather than 
just returning False. In fact, I'd argue it should still return True -- 
if the permission did exist, the superuser would have it. And there's a 
backwards-compatibility argument. Think of superusers more as 
"permissions don't apply to me" than "I have all permissions".


I agree with the logging... however, I think has_perm should always 
return False for non-existent permissions.  This will mean any 
half-decent level of testing will uncover a typo in a permission name, 
since you will never trigger the True state.


This would also be an argument for is_superuser to equate to "has all 
the perms" instead of "has_perm always says true".


--
Curtis




Dan


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

Re: Django 2.0 Python version support (Python 3.6+ only?)

[Curtis Maloney]

Is there any list of things we gain from dropping / adding any particular 
version?

The older discussion mentions a tracking ticket, but it is empty.

--
C

On 8 August 2017 9:45:54 AM AEST, Tim Graham  wrote:
>With a little more than a month to go until the Django 2.0 alpha
>(targeted 
>for September 18), I'd like to make a final decision about whether or
>not 
>to keep Python 3.4 support for Django 2.0. Jenkins is currently running
>the 
>tests on pull requests with Python 3.4 and 3.6. I've seen a few times
>where 
>contributors first used Python 3.5+ syntax and then had to make
>adjustments 
>for 3.4 compatibility so while it's not a large burden, it's not a 
>non-trivial one.
>
>Has anyone changed their thinking in the last few months? If not, I
>guess 
>we'll keep Python 3.4 support for Django 2.0 and drop it for 2.1.
>
>On Friday, February 17, 2017 at 9:32:20 PM UTC-5, Tim Graham wrote:
>>
>> Ok, I created a ticket to track cleanups and new Python features we
>can 
>> use when Python 3.4 support is removed: 
>> https://code.djangoproject.com/ticket/27857
>>
>> We can evaluate that a bit later in the Django 2.0 release cycle and 
>> decide whether or not to keep Python 3.4 support for 1.11.
>>
>> On Wednesday, January 18, 2017 at 12:20:13 PM UTC-5, Rotund wrote:
>>>
>>> I agree that allowing more people to be able to do development
>against 
>>> Django 2.0 is important. That stated, please be very explicit in the
>
>>> release notes and documentation that "Versions below Python 3.6 are 
>>> expected to be dropped before the next Django LTS will be released,
>so 
>>> please keep that in your project planning." (Language too informal,
>but I 
>>> think the idea is correct.)
>>>
>>>
>>>
>>> On Wed, Jan 18, 2017 at 2:28 AM, Claude Paroz 
>wrote:
>>>
 Le mardi 17 janvier 2017 15:48:46 UTC+1, Tim Graham a écrit :
>
> I propose to tentatively target Python 3.5+ for Django 2.0 but not
>to 
> remove the current workarounds for Python 3.4 at this time.
>Shortly before 
> the alpha for Django 2.0, an interested person can look into how
>much work 
> is required to fix any test failures on Python 3.4 and we'll make
>a 
> decision then.
>

 I'm strongly advocating for keeping 3.4 support for now, as I would
>have 
 difficulty to continue contributing to Django.
 My main system is still using 3.4 and will be for some months. Even
>if I 
 could rather easily installing manually a more recent Python, I
>very much 
 like relying on my stable distro packages. Sorry for my dumbness!

 Claude

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

>https://groups.google.com/d/msgid/django-developers/09570028-4eea-41ac-b364-93ae2c946b21%40googlegroups.com
>

>
 .

 For more options, visit https://groups.google.com/d/optout.

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

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

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

Re: Trimming in the settings file (Was: Re: Follow-up to #28307: Possible app_template improvements)

[Curtis Maloney]

On 26/06/17 20:21, Melvyn Sopacua wrote:

On Thursday 15 June 2017 08:14:02 Aymeric Augustin wrote:

I see the point for the number of useless files. But in every release,
settings.py has been trimmed more and more to the point that it's next
to useless. I'm wondering about the upside of that. Cause I'm seeing
plenty of downsides for both new and veteran users.


Can't say I agree it's useless... I find I need very little to modify 
the start project template to get under way... especially now that admin 
is in by default.



Not to mention the choice of what to remove. To keep STATIC_URL (which I
rarely change) but remove STATIC_ROOT (which is different per project
and sometimes even per install) is beyond me.


Because STATIC_URL is useful always, whereas STATIC_ROOT typically only 
makes sense when you deploy...



--
Curtis

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

Re: Follow-up to #28307: Possible app_template improvements

[Curtis Maloney]

On 15/06/17 16:14, Aymeric Augustin wrote:

Hello,

The more files get generated to startapp, the more empty useless files
accrue in many projets, because devs don't take the time to delete those
they don't use.


Beat me to the punch... I agree the default template should be as light 
as possible.



Encouraging people to improve the structure of their Django code is
worthwhile but I don't believe the startapp template is the right medium
for that.


There's no reason we can't provide an "advanced" template in core, surely?

IMHO project/app templates are one of the least utilised features of 
Django, sadly.


It deserves more marketing :)

--
Curtis

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

Admin browser support policy

[Curtis Maloney]

This topic seems to appear frequently over the years, but I've yet to 
see a clear decision.


Without a clear Browser Support Policy for admin, it can be very unclear 
what cleanups, optimisations, and improvements can be made.


Collin Anderson suggested supporting IE11+ ("as that's the latest on 
Windows 7 and there's not much 9-10 usage"), and I'd suggest also 
considering the general Google approach:


Basically, it's "Current and Previous version", and considering IE as 
separate from Edge (so IE 10/11, Edge current and previous).


Does this sound fair and reasonable?
Do we care about mobile browsers?
Does Safari deserve/require special casing?

Once we can resolve this, I want to start working on revising all the 
JS. But I won't start that until I know what dross I have to still drag 
along.


--
Curtis

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

Re: Default to BigAutoField

[Curtis Maloney]

On 10/06/17 22:21, Claude Paroz wrote:

Le samedi 10 juin 2017 11:40:42 UTC+2, Curtis Maloney a écrit :

Right, hence my point of having a global setting to say "the default
auto-field is ..."



I see, but this conforms to the pattern "use the same id field type for
all models of my project". I'm not sure we should encourage that.


Yeah... naming would be key with "DEFAULT_AUTO_FIELD_TYPE" or whatever...


Another idea would be to offer variants of models.Model which models
could inherit from, like models.BigIntModel or models.UUIDModel.


Ah, well... now you're talking.  But then, you can do this already as an 
abstract base with TYPE as id...


class BigIntModel(models.Model):
id = BigAutoField(primary_key=True)
class Meta:
abstract = True


--
C

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

Re: Default to BigAutoField

[Curtis Maloney]

f) let MySQL users opt for PositiveBigAutoField if they want...


On 10/06/17 19:40, Curtis Maloney wrote:

Right, hence my point of having a global setting to say "the default
auto-field is ..."

This would:
a) let people continue to use AutoField
b) let people opt for BigAutoField
c) let 3rd party projects be agnostic
d) let people use UUIDField(default=uuid.uuid4)
e) possibly make it feasible to change mid-stream from AutoField to
BigAutoField...

--
C

On 10/06/17 19:33, Claude Paroz wrote:

I think we should first discuss if it makes sense to set a BigAutoField
by default for all tables. I'm not convinced of that yet. I looked at my
projects with this perspective and found for example a case where I have
many small lookup tables (containing between 2-20 entries) for which I
know I would never use BigAutoField if I'd design the schema on paper.

For me, it's a bit like the `on_delete` parameter for foreign keys. A no
"one size fits all" situation.
For example, a quick analysis of contrib models (sorry for bad
formatting):

Model BigAutoField appropriate
===
admin.LogEntry yes
auth.Userno
auth.Group  no
auth.Permission no
contenttype.ContentType no
flatpage.FlatPage  no
redirect.Redirectno
sessions.Session  yes
sites.Site no

Shouldn't we treat that issue by better documentation instead?
Another idea is to leverage the system check framework (--deploy part)
to warn when the max id is over 50% of available range.
We are perfectionists, aren't we :-)

Claude

--
You received this message because you are subscribed to the Google
Groups "Django developers (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send
an email to django-developers+unsubscr...@googlegroups.com
<mailto:django-developers+unsubscr...@googlegroups.com>.
To post to this group, send email to django-developers@googlegroups.com
<mailto:django-developers@googlegroups.com>.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit
https://groups.google.com/d/msgid/django-developers/0fba4c2c-cd56-4c7d-82b9-7be0a7a3d233%40googlegroups.com

<https://groups.google.com/d/msgid/django-developers/0fba4c2c-cd56-4c7d-82b9-7be0a7a3d233%40googlegroups.com?utm_medium=email_source=footer>.

For more options, visit https://groups.google.com/d/optout.




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

Re: Default to BigAutoField

[Curtis Maloney]

Right, hence my point of having a global setting to say "the default 
auto-field is ..."


This would:
a) let people continue to use AutoField
b) let people opt for BigAutoField
c) let 3rd party projects be agnostic
d) let people use UUIDField(default=uuid.uuid4)
e) possibly make it feasible to change mid-stream from AutoField to 
BigAutoField...


--
C

On 10/06/17 19:33, Claude Paroz wrote:

I think we should first discuss if it makes sense to set a BigAutoField
by default for all tables. I'm not convinced of that yet. I looked at my
projects with this perspective and found for example a case where I have
many small lookup tables (containing between 2-20 entries) for which I
know I would never use BigAutoField if I'd design the schema on paper.

For me, it's a bit like the `on_delete` parameter for foreign keys. A no
"one size fits all" situation.
For example, a quick analysis of contrib models (sorry for bad formatting):

Model BigAutoField appropriate
===
admin.LogEntry yes
auth.Userno
auth.Group  no
auth.Permission no
contenttype.ContentType no
flatpage.FlatPage  no
redirect.Redirectno
sessions.Session  yes
sites.Site no

Shouldn't we treat that issue by better documentation instead?
Another idea is to leverage the system check framework (--deploy part)
to warn when the max id is over 50% of available range.
We are perfectionists, aren't we :-)

Claude

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


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

Re: Default to BigAutoField

[Curtis Maloney]

I don't see it helping once you hit the problem, but like custom user its a 
recommendable setting for pre planning

--
C


On 10 June 2017 11:37:04 AM AEST, Tim Graham <timogra...@gmail.com> wrote:
>I'm not sure how this could work with migrations. In a sense, it would 
>involve making the auto-generated primary key "swappable", including 
>foreign keys that point to it. This sounds like a headache.
>
>I haven't thought of a possible solution since Kenneth floated this
>idea in 
>#django-dev yesterday.
>
>On Friday, June 9, 2017 at 7:11:05 PM UTC-4, Curtis Maloney wrote:
>>
>> I know people hate settings, but what about one for auto id field
>type?
>>
>> It would let you handle backwards compatibility, uuid, and bigint...
>>
>> --
>> C
>>
>>
>> On 10 June 2017 5:42:42 AM AEST, Jacob Kaplan-Moss
><ja...@jacobian.org 
>> > wrote:
>>>
>>> I think this would be a good improvement, and I'd like to see it.
>I've 
>>> been bitten by integers overflowing at least twice I can remember in
>my 
>>> career, which is two times too many.
>>>
>>> However, a major thing we'd have to work out is the upgrade path
>Consider 
>>> a simple model:
>>>
>>> class Person(Model):
>>> name = CharField()
>>>
>>> In Django 1.11, this actually generates a model with an integer `id`
>
>>> field. But in we change it, in Django vNext, that `id` field would
>"turn 
>>> into" a bigint magically without the underlying table changes.
>That'd be 
>>> confusing: you'd expect the model to be "fixed" by pugrading to
>vNext, but 
>>> it wouldn't be. I think the migrations engine would detect this as a
>
>>> migration (?), so perhaps that's the path forward, but it could
>still be 
>>> super-confusing. We've never shipped a release of Django that
>required a 
>>> migration to _all_ your models.
>>>
>>> Have you thought about what the upgrade path should look like,
>Kenneth?
>>>
>>> Jacob
>>>
>>> On Fri, Jun 9, 2017 at 11:24 AM, Kenneth Reitz <ken...@heroku.com 
>>> > wrote:
>>>
>>>> Dear Django Dev,
>>>>
>>>>  
>>>>
>>>> At Heroku, we have the privilege of seeing an extremely broad range
>of 
>>>> customers utilizing tools like Django to build their applications
>and 
>>>> companies. One of the things that we’ve seen customers hit, time
>and time 
>>>> again when using tools like Django, is integer overflows for
>primary keys. 
>>>> Their application starts behaving unpredictably once they reach the
>
>>>> overflow, not even knowing such a constraint exists, and they often
>think 
>>>> the problem is with their database provider, rather than with their
>schema. 
>>>> Once they realize what is wrong, it’s a relatively trivial fix, but
>a 
>>>> migration can take several hours to complete, which results in
>unacceptable 
>>>> amounts of downtime.
>>>>
>>>>  
>>>>
>>>> Because of this, Heroku, as a company, would like to encourage
>bigints 
>>>> as a sane reasonable default for primary keys for application
>models. If 
>>>> the Django project agrees with this idea, that would mean that
>Django would 
>>>> provide BigAutoField as the default for ‘id’ instead of AutoField. 
>>>>
>>>>  
>>>>
>>>> Rails made this change recently 
>>>> <http://www.mccartie.com/2016/12/05/rails-5.1.html>, and has seen 
>>>> success in doing so. 
>>>>
>>>>  
>>>>
>>>> I’m happy to provide the code to do this, but I wanted to discuss
>it 
>>>> here before doing so, to hear what the general consensus was to the
>
>>>> proposal of such a change. 
>>>>
>>>>  
>>>>
>>>>  
>>>>
>>>> Pros:
>>>>
>>>>- 
>>>>
>>>>Users of Django, following the docs, won’t accidentally hit the
>int 
>>>>overflow barrier. 
>>>>- 
>>>>
>>>>Encourages best-practices from the beginning. 
>>>>- 
>>>>
>>>>Bigints don’t take up much more storage than ints when using 
>>>>Postgres. 
>>>>- 
>>>>
>>>>In-line with other frameworks movi

Re: Default to BigAutoField

[Curtis Maloney]

I know people hate settings, but what about one for auto id field type?

It would let you handle backwards compatibility, uuid, and bigint...

--
C


On 10 June 2017 5:42:42 AM AEST, Jacob Kaplan-Moss  wrote:
>I think this would be a good improvement, and I'd like to see it. I've
>been
>bitten by integers overflowing at least twice I can remember in my
>career,
>which is two times too many.
>
>However, a major thing we'd have to work out is the upgrade path
>Consider a
>simple model:
>
>class Person(Model):
>name = CharField()
>
>In Django 1.11, this actually generates a model with an integer `id`
>field.
>But in we change it, in Django vNext, that `id` field would "turn into"
>a
>bigint magically without the underlying table changes. That'd be
>confusing:
>you'd expect the model to be "fixed" by pugrading to vNext, but it
>wouldn't
>be. I think the migrations engine would detect this as a migration (?),
>so
>perhaps that's the path forward, but it could still be super-confusing.
>We've never shipped a release of Django that required a migration to
>_all_
>your models.
>
>Have you thought about what the upgrade path should look like, Kenneth?
>
>Jacob
>
>On Fri, Jun 9, 2017 at 11:24 AM, Kenneth Reitz 
>wrote:
>
>> Dear Django Dev,
>>
>>
>>
>> At Heroku, we have the privilege of seeing an extremely broad range
>of
>> customers utilizing tools like Django to build their applications and
>> companies. One of the things that we’ve seen customers hit, time and
>time
>> again when using tools like Django, is integer overflows for primary
>keys.
>> Their application starts behaving unpredictably once they reach the
>> overflow, not even knowing such a constraint exists, and they often
>think
>> the problem is with their database provider, rather than with their
>schema.
>> Once they realize what is wrong, it’s a relatively trivial fix, but a
>> migration can take several hours to complete, which results in
>unacceptable
>> amounts of downtime.
>>
>>
>>
>> Because of this, Heroku, as a company, would like to encourage
>bigints as
>> a sane reasonable default for primary keys for application models. If
>the
>> Django project agrees with this idea, that would mean that Django
>would
>> provide BigAutoField as the default for ‘id’ instead of AutoField.
>>
>>
>>
>> Rails made this change recently
>> , and has seen
>success
>> in doing so.
>>
>>
>>
>> I’m happy to provide the code to do this, but I wanted to discuss it
>here
>> before doing so, to hear what the general consensus was to the
>proposal of
>> such a change.
>>
>>
>>
>>
>>
>> Pros:
>>
>>-
>>
>>Users of Django, following the docs, won’t accidentally hit the
>int
>>overflow barrier.
>>-
>>
>>Encourages best-practices from the beginning.
>>-
>>
>>Bigints don’t take up much more storage than ints when using
>Postgres.
>>-
>>
>>In-line with other frameworks moving forward on this issue, like
>Rails
>>.
>>
>>
>>
>> Cons:
>>
>>-
>>
>>Backwards compatibility would need to be considered.
>>
>>
>> Why not UUID?
>>
>>
>>
>> I agree! I love using UUID for my primary keys, and I think a patch
>to
>> Django which provides an AutoUUIDField would be wonderful. However,
>there
>> are a few major drawbacks to making this the new default:
>>
>>
>>
>>1.
>>
>>It’s confusing to new users, would make onboarding process more
>>difficult.
>>2.
>>
>>UUID is difficult to implement in MySQL.
>>3.
>>
>>UUID has larger storage requirements.
>>4.
>>
>>Incrementing IDs are actually useful.
>>
>>
>>
>>
>> So, my proposal is to simply lift the int barrier to a bigint barrier
>for
>> new Django applications, and I think it will save a lot of developers
>a lot
>> of pain in the long run.
>>
>>
>>
>> Many thanks,
>>
>>
>>
>> Kenneth Reitz
>>
>> Heroku Python
>>
>> --
>> You received this message because you are subscribed to the Google
>Groups
>> "Django developers (Contributions to Django itself)" group.
>> To unsubscribe from this group and stop receiving emails from it,
>send an
>> email to django-developers+unsubscr...@googlegroups.com.
>> To post to this group, send email to
>django-developers@googlegroups.com.
>> Visit this group at
>https://groups.google.com/group/django-developers.
>> To view this discussion on the web visit https://groups.google.com/d/
>> msgid/django-developers/6fe3401c-4404-4bd8-9d22-
>> 58df95cd1348%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 

Re: Exceptions in model._meta._property_names with some 3rd-pty libraries

[Curtis Maloney]

What about using inspect.getmembers ?

https://docs.python.org/3/library/inspect.html#inspect.getmembers

In other code I've also used inspect.classify_class_attrs but it seems 
to be undocumented :/


If nothing else, it could be used as a guide on how to do this.

--
Curtis


On 03/06/17 08:52, Adam Johnson wrote:

This is my bad, I did the refactoring :) You're right, the original
version

did in fact use a try..except AttributeError and that should be
preserved for cases like this.

I've made a ticket here https://code.djangoproject.com/ticket/28269 . If
you want to make the PR copying in your fix and adding a test that would
be neat, you've done 90% of the work already! :)


On 2 June 2017 at 22:02, Zack Voase >
wrote:

Hi all,

I'm encountering exceptions in a number of popular third-party
Django libraries when upgrading from 1.8 to 1.11. The code path is
typically `MyModel.objects.get_or_create(...)`, which causes
`model._meta._property_names` to be checked (to make sure we're not
querying/setting a property). The problem is, `_property_names` is
implemented as follows:

|
# in django/db/models/options.py:
def_property_names(self):
returnfrozenset({
   attr forattr in
   dir(self.model)ifisinstance(getattr(self.model,attr),property)
})
|

The problem is when a custom field installs a field descriptor on
the model class (during `contribute_to_class()`), with a `__get__()`
method like this:

|
classSomeFieldDescriptor(object):
# ...
def__get__(self,instance,type=None):
ifinstance isNone:
raiseAttributeError("Can only be accessed via an instance.")
# ...
|

Libraries which install such descriptors include

[django-fsm](https://github.com/kmmbvnr/django-fsm/blob/2d2eaee/django_fsm/__init__.py#L225

)
and

[django-jsonfield](https://github.com/dmkoch/django-jsonfield/blob/2.0.1/jsonfield/subclassing.py#L35

).
I think the problem is that we can't assume that all results of
`dir(model_class)` can be accessed via `getattr(model_class, attr)`
without exception; indeed, the Python docs state (c.f.
https://docs.python.org/2/library/functions.html#dir
):

> Because dir() is supplied primarily as a convenience for use at an
interactive prompt, it tries to supply an interesting set of names
more than it tries to supply a rigorously or consistently defined
set of names, and its detailed behavior may change across releases.

A potential fix would be to adjust the definition of
`_property_names` like so:

|
def_property_names(self):
attrs =[]
forattr indir(self.model):
try:
ifisinstance(getattr(self.model,attr),property):
attrs.append(attr)
exceptAttributeError:
pass
returnfrozenset(attrs)
|

Does this seem like a good solution, or even a problem worth solving?

Thanks!
-- Zack

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

https://groups.google.com/d/msgid/django-developers/ec0e2506-4c4b-441f-b005-5623d6521ae3%40googlegroups.com

.
For more options, visit https://groups.google.com/d/optout
.




--
Adam

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

Re: Cython usage within Django

[Curtis Maloney]

On 22/05/17 09:30, Tom Forbes wrote:

Hey Karl and Russell,
Thank you for your quick replies!

Russell:

You are of course right about the speed of the Python code itself being
a bottleneck and the usual suspects like the database are more important
to optimize. However I don't think it's necessarily always a waste of
time to explore optimizing some Python/django functions, if that only
means simply moving them to a separate file and running Cython on them
to get a speed boost.


Of course, I'm sure Russel won't object to be shown to be wrong, if you 
feel like giving it a go anyway :)


--
Curtis

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

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

[Curtis Maloney]

Dogfooding is a fairly strong argument, IMHO.

Especially when there's a volunteer to do the work.

--
C

On 7 May 2017 6:53:13 PM AEST, Paolo Melchiorre  wrote:
>On Sun, May 7, 2017 at 9:16 AM, Florian Apolloner
> wrote:
>> On Sunday, May 7, 2017 at 12:50:02 AM UTC+2, Paolo Melchiorre wrote:
>>>
>>> Hello,
>>>
>>> in the djangoproject.com the search is powered by elasticsearch.
>>>
>>> Since the site uses postgresql as database backend I want propose to
>use
>>> the Full-Text Search function provided by
>django.contrib.postgres.search
>>> module.
>>>
>>> I presented a talk "Full-Text Search in Django with PostgreSQL" at
>the
>>> last PyConIT 2017 Conference in Florence
>>> https://twitter.com/pauloxnet/status/850766131338117120
>>> and I proposed a similar talk for the next EuroPython 2017
>>> https://ep2017.europython.eu/conference/voting/#ord128
>>>
>>> If you're interested in this proposal it will be nice to organize a
>>> related sprints at the next EuroPython 2017
>>> https://ep2017.europython.eu/en/events/sprints
>>
>> What would be the benefit of using django.contrib.postgresql aside
>from much
>> work?
>
>The benefit would be to have a djangoproject.com made with
>technologies the site talks about and to demonstrate what you can
>build using only officially documented Django module.
>
>For the work to do this I can candidate myself to work on it!
>
>-- 
>Paolo
>
>-- 
>You received this message because you are subscribed to the Google
>Groups "Django developers  (Contributions to Django itself)" group.
>To unsubscribe from this group and stop receiving emails from it, send
>an email to django-developers+unsubscr...@googlegroups.com.
>To post to this group, send email to
>django-developers@googlegroups.com.
>Visit this group at https://groups.google.com/group/django-developers.
>To view this discussion on the web visit
>https://groups.google.com/d/msgid/django-developers/CAKFO%2Bx59T7ykkk9WT%3DoAyvG9xX-vxp4gSN0gLRAmSmz%2Byo1bqQ%40mail.gmail.com.
>For more options, visit https://groups.google.com/d/optout.

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

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

Re: Admin and CSS Custom Properties

[Curtis Maloney]

I recently discovered that the stated "policy" on browser support in 
Admin is... well... not clear at all.


https://docs.djangoproject.com/en/1.11/faq/admin/#what-browsers-are-supported-for-using-the-admin

It claims to support full function for "YUI's A-Grade" browsers, but the 
link it provides does nothing to explain the supported versions, and a 
further "target environments matrix" link still lists IE6.


So perhaps it's time to update the FAQ, and have a discussion on what 
Admin's browser support policy needs to be updated to.


--
Curtis

On 28/04/17 19:14, Patrick Guido wrote:

On 27 April 2017 at 23:18, Adam Johnson > wrote:

Thanks for introducing me to a new CSS feature! I clearly don't keep
up with front end stuff enough.

Re: your issues:

1. From the support grid at the bottom of the Smashing Magazine
article you linked, it looks like it's only IE 11 and Edge 14 that
are major browsers that don't support it. However I feel like if
Django is going to announce a feature like "you can override the
Admin colours", it should work in all browsers. I'm not sure if we
have a written policy for this though.

I guess it also depends on use cases, usually (where I work) we tend to
support only latest browsers when it comes to admin, since
it will be used by only a few people :) But I see your point.

A friend of mine was suggesting configuring colours in python, but this
means that the css would be rendered via python, which is
not ideal.
Another solution would be to add a JS polyfill to make it work on older
browsers, but I'm against it :)
Let's also keep in mind that this (if approved) will be included in
django 2.0 or later, so the browser support will be even better :)


2. I'm not a huge fan of an additional HTTP request for every admin
page load, for every admin site in existence whether or not the
colours have been overridden. HTTP/2 isn't very widely deployed
still so requests still ain't cheap.

Uhm, I think we can easily skip one request if the colours have not been
overridden. We can put the vars in base.css.
Then we can add the variables by changing the template (but that's more
cumbersome) either by adding an external css link
or by adding a style tag with the variables.


3. This can be overcome with a test to ensure the two files are in
sync, I guess?

Uhm, true!


And one more question: how much less painful is this to override the
colours compared to the variable-less way, where you just clone the
colour definitions of every rule in the original file in a second
override file?

I haven't checked all the rules, but I think it will require quite a bit
of work. Maybe we can create a "template" file
that can be used to override quite easily the colours, but that doesn't
scale too well I think.


--
Patrick Guido Arminio

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


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

Re: Django versioning and breaking changes policy

[Curtis Maloney]

See? This is exactly what I told you you could expect ... to be shown 
the new release process details :)


[For those playing at home, Bernhard raised this concern on IRC first, 
and I recommended bringing it here.  He expressed concern about being 
roasted, and I predicted someone would introduce him to the details of 
the new release process :)]


--
C

On 05/04/17 08:29, Bernhard Posselt wrote:

Oh wow, haven't seen that yet, thank you :)

Just make sure to follow the semver spec closely if you transition to
semver, because it can cause issues for parsers. Also the spec is more
restrictive than you'd think with regards to syntax (source: working
with semver in my current Django project)


On 04/04/2017 11:11 PM, Aymeric Augustin wrote:

Hello,

As far as I can tell, recent modifications to the release process means it will 
meet your expectations going forwards.

Take a look at https://docs.djangoproject.com/en/dev/internals/release-process/ 
 for details.

Best regards,





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

Re: Changing {% include %} to strip a trailing newline

[Curtis Maloney]

On 05/01/17 10:09, Adam Johnson wrote:

Whitespace control in templates is an exercise in frustration. In my
experience more flexible tools such as {%-, {%+, -%}, and +%} in
Jinja2 increase the frustration.


I really enjoy the {%- etc. operators in Jinja 2 in the context of
Ansible, there are often cases when templating obscure configuration
files that they come in useful.


I believe SmileyChris had a patch to add this to DTL...

--
Curtis

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

Re: No 'Content-Type' header in response

[Curtis Maloney]

>From what I can see in the rfc, it is permitted but not required.

Only a body in a 204 response is proscribed.

Any metadata (I.e. headers) are about the resource just accessed... So a 
Content-Type would, IMHO, be acceptable but not essential.



On 26 December 2016 9:47:02 PM AEDT, roboslone  wrote:
>Thanks, that was an old setting in Mail.app =/
>
>I've made a pull-request to DRF:
>https://github.com/tomchristie/django-rest-framework/pull/4768
>
>But it seems to me that fixing it in Django would be more appropriate.
>
>On the subject of Content-Type header with no response body, seems
>there's no convention about it, I've found different opinions on the
>web. The only thing I'm sure about is that putting None in that header
>is a bad idea.
>
>> On 26 Dec 2016, at 13:24, Adam Johnson  wrote:
>> 
>> Hi GMail! (you might want to fix your name used on google groups, I
>had the same problem ;) )
>> 
>> This seems to be a legitimate bug in the __repr__ to me - SO informs
>me that DRF is correct in not defining a Content-Type for a 204 as it
>has no body:
>https://stackoverflow.com/questions/21029351/what-content-type-should-a-204-no-response-use
>
>> 
>> I created a ticket: https://code.djangoproject.com/ticket/27640
> . If you want to try fix
>it there's a great contribution guide at
>https://docs.djangoproject.com/en/dev/internals/contributing/
> . I
>think using str.format would be acceptable, but the dict subclass
>sounds more complicated than just doing self.get('Content-Type', '') :)
>> 
>> On 26 December 2016 at 05:57, GMail > wrote:
>> Hi! I'm using Django 1.10.2 and Django-Rest-Framework 3.5.3.
>> I noticed, that HttpRequest.__repr__ method relies on 'Content-Type'
>header:
>> 
>> 
>> > class HttpResponse(HttpResponseBase):
>> > ...
>> >
>> > def __repr__(self):
>> > return '<%(cls)s status_code=%(status_code)d,
>"%(content_type)s">' % {
>> > 'cls': self.__class__.__name__,
>> > 'status_code': self.status_code,
>> > 'content_type': self['Content-Type'],
>> > }
>> 
>> 
>> And after deleting an object in DRF sends empty response with HTTP204
>and no 'Content-Type' header. I was trying to log outgoing response and
>got KeyError here.
>> 
>> So I have two questions:
>> 1. Is this intentional? Do all responses in Django have
>'Content-Type' header and should DRF be aware of it?
>> 2. Why not use `str.format` here? To avoid errors like this, `dict`
>subclass with `__missing__` method could be used.
>> 
>> --
>> You received this message because you are subscribed to the Google
>Groups "Django developers  (Contributions to Django itself)" group.
>> To unsubscribe from this group and stop receiving emails from it,
>send an email to django-developers+unsubscr...@googlegroups.com
>.
>> To post to this group, send email to
>django-developers@googlegroups.com
>.
>> Visit this group at https://groups.google.com/group/django-developers
>.
>> To view this discussion on the web visit
>https://groups.google.com/d/msgid/django-developers/39F85D40-019C-411A-BCA7-402E338EA527%40gmail.com
>.
>> For more options, visit https://groups.google.com/d/optout
>.
>> 
>> 
>> 
>> -- 
>> Adam
>> 
>> -- 
>> You received this message because you are subscribed to the Google
>Groups "Django developers (Contributions to Django itself)" group.
>> To unsubscribe from this group and stop receiving emails from it,
>send an email to django-developers+unsubscr...@googlegroups.com
>.
>> To post to this group, send email to
>django-developers@googlegroups.com
>.
>> Visit this group at https://groups.google.com/group/django-developers
>.
>> To view this discussion on the web visit
>https://groups.google.com/d/msgid/django-developers/CAMyDDM39qZj7fV-MvPX%2BtXvSNL9%2B80283Aa5P47uBh3D46Q8BQ%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 

Re: Feature idea

[Curtis Maloney]

My solution to the "initial password problem" is to send a password 
reset token first...


And Django has this built in, handily :)

http://musings.tinbrain.net/blog/2014/sep/21/registration-django-easy-way/

It would be very easy to use the same approach for an "invite" 
registration pattern.


--
C


On 17/11/16 19:38, Aymeric Augustin wrote:

Hello,


On 16 Nov 2016, at 21:22, Anthony King > wrote:

Sending a link to set a password isn't much better.


The cardinal rule of passwords is “you must be the only person who knows
your password”. This means never writing it down anywhere, except in a
proper password manager, and never telling it to anyone, *even* your IT
staff — to fight social engineering attacks.

Sending a password in clear over email means the IT staff is okay with
knowing the user's password. Disregarding their own guidelines sets a
poor example and reduces their credibility about password management in
general.

Of course, on most Django websites, someone who can create a staff user
can also change the user’s password — it’s rare to give the “create
user” but not the “change user” permission. I’m not making a technical
argument here, I’m thinking of IT literacy and educating users.


Perhaps a way to force a password change on login would be better,
which has more use elsewhere, such as being able to periodically force
password changes


Forcing a password change on login is another interesting idea to solve
this problem. That’s what ActiveDirectory has to do, because OSes don’t
have the same password reset possibilities that web applications have.

However I think that would mean solving the general problem of password
rotation. Django solved password validation recently; it could solve
password rotation next. (Note that password rotation is controversial
because it forces users to choose weak passwords with a basic rotation
scheme like putting month number at the end, instead of storing strong
random password in a password manager. Trade-offs.)

I still think a simple solution hooking into the current password reset
mechanism, just with a different email template, could be a quick
security win for a lot of Django sites. I’d encourage people to use it
if it existed.

Best regards,

--
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 https://groups.google.com/group/django-developers.
To view this discussion on the web visit
https://groups.google.com/d/msgid/django-developers/76AE3F1E-6C00-4E4E-86A7-4E1374FF20AF%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 https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/694f60cb-bcd8-cc32-fd8b-c060c7a54415%40tinbrain.net.
For more options, visit https://groups.google.com/d/optout.

Re: drop compatibility with Python < 2.7.8?

[Curtis Maloney]

Well, I certainly agree with the intent... especially, as you say, for 
LTS users who effectively cement themselves to a version for the long haul.


Might as well remind them there are security updates in things other 
than OpenSSL, Java, and Django :)


--
C


On 15/11/16 09:49, Tim Graham wrote:

Hi,

I was wondering if Django could or should nudge Python 2 users toward
the latest stable release of 2.7.x? For example, we could require at
least 2.7.8 by removing the fallback pbkdf2() implementation in
django.utils.crypto [0]. I guess part of my feeling is that if you're
running 1.11 LTS for at least another three years, you should really try
to use the latest Python 2 as it has security improvements and fixes
compared to the older 2.7.x releases.

As a data point, Ubuntu 14.04 ships with Python 2.7.6 and 16.04 ships
with Python 2.7.12.

[0] https://github.com/django/django/pull/7556

Thanks for your input.

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


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

Re: Fellow Report - October 15, 2016

[Curtis Maloney]

Ummm...

On 16/10/16 11:45, Tim Graham wrote:

https://code.djangoproject.com/ticket/27334- File uploads could rename
temporary files rather than copying them (duplicate)

https://code.djangoproject.com/ticket/27334- File uploads could rename
temporary files rather than copying them (accepted)


Is it a duplicate of itself? :P

--
C

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

Re: Please put monitor.py as default in next django version

[Curtis Maloney]

On 15/10/16 08:16, Ricardo Prado wrote:

Thanks "Folks" in special Aymeric

Let's go, let me explain about this "monitor.py".

When users deploy django app in production, the changes in any python
script need be "reloaded" for apply changes, in this you have two
options to do this:

1 - restart apache or nginx server


Well, no... if you're using apache/mod_wsgi (and have configured it 
correctly) you merely need to "touch" the wsgi script.


If you're using nginx, it doesn't run django, so you should be starting 
whichever uwsgi service you are using (e.g. uwsgi, gunicorn, waitress, etc)



Anyway this is a problem, this file can be included in django core for
apply changes in python script and don't need be reload server. When you
start a django app

typing: "python manage.py runserver".

An internal montior is initialized for apply changes runtime. Would be
good have this option in production too.


Most deploy processes and managers would scream at you if you decided to 
restart the service every time a file changed.


Typically in production you want to update the whole codebase and have a 
controlled reload (is touch really so difficult?)


What sort of situations are you seeing that you want a restart 
frequently and more simple than "touch wsgi.py" ?


--
C

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

Re: Should the Django session-id be hashed?

[Curtis Maloney]

On 22/09/16 18:52, Rigel wrote:

Hello!

The Django session framework stores session-ids in the database as
plain-text. Unless I'm missing something, these ids could be
vulnerable to SQL injection attacks, if any are discovered or if
developers misuse features like extra().


Firstly, extra() is on is way out... being replaced by expressions, 
transforms, and so on...


That said, yes, extra() does potentially open you to SQL attacks, but 
only if you use it incorrectly.  If used as documented -- same goes for 
raw() -- you should remain immune to SQL injection.


The only time you're likely to become vulnerable to SQLi is when you do 
something as stupid as putting values into SQL commands yourself.



This vulnerability could be
mitigated if the session-ids were hashed with a secure cryptographic
hash function, like SHA-256, before storing them or querying for them
in the database.


They're just a random string, I don't see how turning them into another 
random string will help?  Or do you mean to set the original string in 
the cookie only, and hash them for the key, and hash them _every_ _time_ 
you look up the session?



This concern has recently been raised for Joomla! on the Full
Disclosure mailing list:
http://seclists.org/fulldisclosure/2016/Sep/50

What is your opinion on this matter? It could be fairly trivial to
implement, with the only side effect of being computationally
expensive. Still, security is more desirable than efficiency or
performance.


You are right there, security is more important.

However, it's a small overhead for everyone... for a small win for 
almost nobody.


Until you can demonstrate how there's any SQLi vulnerability, I'm -1 on 
this.


--
Curtis

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

Re: Challenge teaching Django to beginners: urls.py

[Curtis Maloney]

On 15/09/16 16:37, Curtis Maloney wrote:

Somewhere I have code to provide a "parse" based URL router.

Will dig it up now 1.10 has has shipped


Ah, found it...

So, here is a gist of a sample of using parse 
(https://pypi.org/project/parse/) instead of regex.


https://gist.github.com/funkybob/3d90c57a837bc164d8b402a1c5b95a8b

Since you can register extra type names, and those types can cast also, 
it covers a lot of things some people expect [but don't get] from regex.



--
C




On 14 September 2016 6:38:20 PM AEST, Florian Apolloner
<f.apollo...@gmail.com> wrote:

Hi Emil,

On Tuesday, September 13, 2016 at 9:50:22 PM UTC+2, Emil Stenström
wrote:

and more experienced users are expected to switch over to using
regexes directly to get the exact behavior they want.


How so? Personally I would use this quite quickly since a few
builtin types would cover 99%. While I can write regex in sleep
nowadays, I still find it kinda tedious to redefine what "slug"
means in every URL I wanna match something… I am sure others think
the same.


Beginners likely won't look at all the different options and
choose one based on it's merits, they'll pick whatever their
teacher suggests they use. Also installing an extra package when
setting up django feels a bit strange.


I think the eco system is far enough to support that, after all
south lived long and well as external package. Either way, DEP or
not, having an implementation out there would definitely help.

Cheers,
Florian


--
Sent from my Android device with K-9 Mail. Please excuse my brevity.

--
You received this message because you are subscribed to the Google
Groups "Django developers (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send
an email to django-developers+unsubscr...@googlegroups.com
<mailto:django-developers+unsubscr...@googlegroups.com>.
To post to this group, send email to django-developers@googlegroups.com
<mailto:django-developers@googlegroups.com>.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit
https://groups.google.com/d/msgid/django-developers/B35D1655-D658-41FC-9EB5-83311B6C892C%40tinbrain.net
<https://groups.google.com/d/msgid/django-developers/B35D1655-D658-41FC-9EB5-83311B6C892C%40tinbrain.net?utm_medium=email_source=footer>.
For more options, visit https://groups.google.com/d/optout.


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