Fellow Report - June 20, 2015

[Tim Graham]

Report for week ending June 20, 2015:

Triaged

---

https://code.djangoproject.com/ticket/24985 - Provide a way to sanitize 
invalid characters from Rss201rev2Feed (accepted)

https://github.com/django/djangoproject.com/issues/492 - 
SelectDateWidget(empty_label) is not working (invalid)

https://code.djangoproject.com/ticket/24997 - Allow bulk_create with proxy 
inheritance (accepted)

https://code.djangoproject.com/ticket/24999 - manage dbshell with mysql 
give the password on the command line, visible system wide (accepted)

https://code.djangoproject.com/ticket/25007 - UUIDFIeld(default=uuid.uuid4) 
created with migrations are the same (invalid)

https://code.djangoproject.com/ticket/25008 - Replace F() Object with 
updated value after save method is called (duplicate)

https://code.djangoproject.com/ticket/25010 - TEMPLATES settings 
documentation is confusing about APP_DIRS (fixed)

Authored



https://github.com/django/django/pull/4862 - Removed 
django.utils.functional.total_ordering()

https://github.com/django/django/pull/4899 - Refs #25006 -- Added a '6 
p.m.' option to the admin's time picker.

Reviewed/committed

--

https://github.com/django/django/pull/4799 - Fixed #24912 -- Fixed 
prefetch_related failure for UUIDField primary keys

https://github.com/django/django/pull/4731 - Fixed #24894 -- Added 
TransactionNow() database function to django.contrib.postgres

https://github.com/django/django/pull/4859 - Fixed #24972 -- Fixed removing 
unique_together indexes on MySQL.

https://github.com/django/django/pull/4856 - Fixed #24971 -- Made startapp 
generate an apps.py

https://github.com/django/django/pull/4835 - Fixed #24943 -- Updated 
contributing tutorial to use virtualenv

https://github.com/django/django/pull/4869 - Fixed #24948 -- Fixed crash 
when uploading bitmap images in forms.ImageField

https://github.com/django/django/pull/4777 - Fixed #24829 -- Allowed usage 
of TemplateResponse in error handlers

https://github.com/django/django/pull/4853 - Fixed #24834 -- Fixed 
get_current_site() when Host header contains port.

https://github.com/django/django/pull/4723 - Fixed #24873 -- Prevented 
nested Prefetch objects from being overwritten.

https://github.com/django/django/pull/4884 - Fixed #24962 -- Added newline 
to characters escaped by contrib.admin.utils.quote()

https://github.com/django/django/pull/4817 - Fixed #24881 -- Clarified 
Meta.order_with_respect_to documentation

https://github.com/django/django/pull/4339 - Fixed #23804 -- Added 
RasterField for PostGIS.

https://github.com/django/django/pull/4893 - Fixed #14200 -- Added a 
fallback if HttpRequest.urlconf is None.

Reviews of core dev work



https://github.com/django/django/pull/4858 - Fixed #24828 -- Allowed 
migration optimization across AlterFooTogether

https://github.com/django/django/pull/4844 - Fixed #24914 -- Added 
authentication mixins for CBVs

https://github.com/django/django/pull/4885 - Fixed #24940 -- Made model 
managers hashable
https://github.com/django/django/pull/4888 - Fixed #20197 -- Made XML 
serializer fail loudly when outputting unserializable chars

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

DecimalField with no max_digits and decimal_places

[Shai Berger]

Hi,

Django's DecimalField requires both max_digits and decimal_places. Database 
backends allow them to be dropped, to specify an "unlimited precision" field. 
Adding support for this in Django is probably not very helpful for new apps, 
but can help significantly in using Django against legacy databases. I have 
opened ticket #24920[1] to track this feature.

I'm raising it here (at Tim's kind suggestion) because there's a bit of a 
design decision to be made about implementing it: Supporting it in the 
existing DecimalField class would lead to quite ugly code with repeated 
branching on whether the attributes have values or not. It would be 
significantly nicer to do this in a new field type. But that discrepancy 
between 
field type and database type would probably be a less-than-optimal public API.

What do you think?

Shai.


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

Re: Misleading Documentation on Model Field Reference

[Tim Graham]

Feel free to propose a ticket and pull request. I don't think this needs 
much discussion on the mailing list. Thanks!

On Saturday, June 20, 2015 at 9:19:47 AM UTC-4, Christian Schmitt wrote:
>
> Hello, I read carefully through out the Django Docs and found one comment 
> really misleading (
> https://docs.djangoproject.com/en/1.8/ref/models/fields/#foreignkey):
>
> > Behind the scenes, Django appends "_id" to the field name to create its 
> database column name. In the above example,
> > the database table for the Car model will have a manufacturer_id column. 
> (You can change this explicitly by specifying db_column 
> 
> ) 
> > However, your code should never have to deal with the database column 
> name, unless you write custom SQL. 
> > You’ll always deal with the field names of your model object.
>
> Currently nothing in the first two paragraphs is obviously wrong, however 
> the second part is. Since when dealing with SQL YOU SHOULD now your column 
> name.
> db_column Name could save you a really expensive join when you don't need 
> to access more data.
> I mean the best example obviously comes with Username's. Here is an 
> example:
>
> from django.db import models
>
> class Tweet(models.Model):
> message = models.TextField()
>username = models.ForeignKey('auth.User', db_column='username')
>
> When you now need to represent tweets to a user you could easily write 
> that:
> Tweet.objects.all()
> You now have all the Tweets and the Usernames.
>
> However if you want to present the Tweet and the Username while using the 
> following:
>
> from django.db import models
>
> class Tweet(models.Model):
> message = models.TextField()
>user = models.ForeignKey('auth.User')
>
> You would obviously need a join to get the username.
>
> So that part is really misleading and It would be great to have more 
> documentation about db_column since it could save some time at the database 
> level, especially when dealing with UNIQUE strings etc.
>

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

Misleading Documentation on Model Field Reference

[Christian Schmitt]

Hello, I read carefully through out the Django Docs and found one comment 
really misleading 
(https://docs.djangoproject.com/en/1.8/ref/models/fields/#foreignkey):

> Behind the scenes, Django appends "_id" to the field name to create its 
database column name. In the above example,
> the database table for the Car model will have a manufacturer_id column. 
(You can change this explicitly by specifying db_column 

) 
> However, your code should never have to deal with the database column 
name, unless you write custom SQL. 
> You’ll always deal with the field names of your model object.

Currently nothing in the first two paragraphs is obviously wrong, however 
the second part is. Since when dealing with SQL YOU SHOULD now your column 
name.
db_column Name could save you a really expensive join when you don't need 
to access more data.
I mean the best example obviously comes with Username's. Here is an example:

from django.db import models

class Tweet(models.Model):
message = models.TextField()
   username = models.ForeignKey('auth.User', db_column='username')

When you now need to represent tweets to a user you could easily write that:
Tweet.objects.all()
You now have all the Tweets and the Usernames.

However if you want to present the Tweet and the Username while using the 
following:

from django.db import models

class Tweet(models.Model):
message = models.TextField()
   user = models.ForeignKey('auth.User')

You would obviously need a join to get the username.

So that part is really misleading and It would be great to have more 
documentation about db_column since it could save some time at the database 
level, especially when dealing with UNIQUE strings etc.

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

Re: delegating our static file serving

[David Evans]

On Friday, 5 December 2014 19:14:29 UTC, Carl Meyer wrote:
>
> On 12/04/2014 10:33 PM, Collin Anderson wrote: 
> > Hi All, 
> > 
> > I'm pretty interested in getting secure and _somewhat_ efficient static 
> > file serving in Django. 
> > 
> > Quick history: 
> > 2005 - Jacob commits #428: a "static pages" view.  Note that this view 
> > should only be used for testing!" 
> > 2010 - Jannis adds staticfiles. Serving via django is considered 
> "grossly 
> > inefficient and probably insecure". 
> > 2011 - Graham Dumpleton adds wsgi.file_wrapper to Gunicorn. 
> > 2012 - Aymeric adds StreamingHttpResponse and now files are read in 
> chunks 
> > rather than reading the entire file into memory. (No longer grossly 
> > inefficient IMHO.) 
> > 
> > I propose: 
> > - Deprecate the "show_indexes" parameter of static.serve() (unless 
> people 
> > actually use it). 
> > - Have people report security issues to secu...@djangoproject.com 
>  (like 
> > always) 
> > - Audit the code and possibly add more security checks and tests. 
> > - add wsgi.file_wrapper support to responses (5-line proof of concept: 
> > https://github.com/django/django/pull/3650 ) 
> > - support serving static files in production, but still recommend 
> > nginx/apache or a cdn for performance. 
> > - make serving static files in production an opt-in, but put the view in 
> > project_template/project_name/urls.py 
> > 
> > I think it's a huge win for low-traffic sites or sites in the "just 
> trying 
> > to deploy and get something live" phase. You can always optimize later 
> by 
> > serving via nginx or cdn. 
> > We already have the views, api, and logic around for finding and serving 
> > the correct files. 
> > We can be just as efficient and secure as static/dj-static without 
> needing 
> > to make people install and configure wsgi middleware to the application. 
> > We could have staticfiles classes implement more complicated features 
> like 
> > giving cache recommendations, and serving pre-gzipped files. 
> > 
> > Is this a good idea? I realize it's not totally thought through. I'm 
> fine 
> > with waiting until 1.9 if needed. 
>
> I also think this is a good plan. It certainly makes sense to look at 
> "static" and "whitenoise" for ideas and compare their code to ours to 
> see where we could be more efficient or secure, but it's much less churn 
> for Django users if we simply improve our existing code rather than pull 
> in something wholly new. 
>
> Carl 
>
>
>  
Sorry to revive an old thread here, but I just wanted to add that v2.0 of 
WhiteNoise now supports serving development files, providing the same 
behaviour as runserver currently does in DEBUG mode. (There were enough 
people wanting to do their development using gunicorn rather than runserver 
to make this worthwhile.)

This means that WhiteNoise is now a one-stop-shop for static file handling 
in Django. If there's still an appetite for integrating it, or something 
equivalent, into core I'd be happy to help out.

Dave

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

Re: Any chances to see Django benefit from new Async features of Python 3.5 ?

[Łukasz Rekucki]

Considering that PEP 492 is mostly about new syntax, it's not really
possible to write code in the core that will work in earlier Python
versions. Unless you wrap everything into some compatibility later, but
that defeats the purpose of the PEP.

Also, Django doesn't really have any asynchronous parts in the core.

BR,
Lucas


On Saturday, June 20, 2015, Benjamin Melki  wrote:

> Hi,
> are there any chances for a future Django version to benefit from new
> built in Python async features ( https://www.python.org/dev/peps/pep-0492/
> ) ?
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django developers (Contributions to Django itself)" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to django-developers+unsubscr...@googlegroups.com
> 
> .
> To post to this group, send email to django-developers@googlegroups.com
> .
> Visit this group at http://groups.google.com/group/django-developers.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/a9353635-0583-43b3-b8c1-d1aa68c8a951%40googlegroups.com
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>


-- 
Łukasz Rekucki

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

Any chances to see Django benefit from new Async features of Python 3.5 ?

[Benjamin Melki]

Hi,
are there any chances for a future Django version to benefit from new built 
in Python async features ( https://www.python.org/dev/peps/pep-0492/ ) ?

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