Fellow Report - June 4, 2016

2016-06-04 Thread Tim Graham 


Triaged

---

https://code.djangoproject.com/ticket/26680 - more than one row returned by 
a subquery used as an expression (duplicate)

https://code.djangoproject.com/ticket/23518 - Subquery does not respect 
explicit __exact (fixed)

https://code.djangoproject.com/ticket/26681 - save_as=True and inlines in 
ModelAdmin raises ValidationError (duplicate)

https://code.djangoproject.com/ticket/26695 - 
views.generic.base.View.options() documentation doesn't match code (fixed)

https://code.djangoproject.com/ticket/26706 - ManyToMany clear doesn't 
clear the items from the object but deletes from db (worksforme)

Reviewed/committed

--

https://github.com/django/django/pull/6648 - Fixed #26653 -- Made 
SyndicationFeed.latest_post_date() return time in UTC.

https://github.com/django/django/pull/6652 - Fixed #26691 -- Removed 
checking for a file's existence before deleting.

https://github.com/django/django/pull/6632 - Fixed #26616 -- Improved error 
message when AppConfig.name is invalid.

https://github.com/django/django/pull/6606 - Fixed #26617 -- Added distinct 
argument to contrib.postgres's StringAgg.

https://github.com/django/django/pull/6690 - Fixed #26699 -- Clarify doc 
theming difference in documentation

https://github.com/django/django/pull/6678 - Fixed #26686 -- Fixed crash 
when registering model signals with abstract senders.

https://github.com/django/django/pull/6668 - Fixed #26672 -- Fixed 
HStoreField to raise ValidationError instead of crashing on non-dict JSON 
input.

https://github.com/django/django/pull/6689 - Fixed #26526 -- Documented 
QuerySet.latest()'s dependency on database ordering.

https://github.com/django/django/pull/6650 - Fixed #26638 -- Allowed 
callable arguments for QuerySet.get_or_create()/update_or_create() defaults.

https://github.com/django/django/pull/6704 - Fixed #15250 -- Avoided extra 
query on some multi-table inheritance queries.

https://github.com/django/django/pull/6697 - Fixed #26698 -- Fixed 
PostgreSQL dbshell crash on an empty database name.

https://github.com/django/django/pull/6603 - Fixed #26604 -- Added a 
multiple file upload example to topics/http/file-uploads.txt.

https://github.com/django/django/pull/6703 - Fixed #12666 -- Added 
EMAIL_USE_LOCALTIME setting.

https://github.com/django/django/pull/6707 - Fixed #26628 -- Changed CSRF 
logger to django.security.csrf.

https://github.com/django/django/pull/6708 - Fixed #25127 -- Documented how 
to organize models in a package.

https://github.com/django/django/pull/6563 - Fixed #19963 -- Added support 
for date_hierarchy across relations.

Reviews of core dev work


https://github.com/django/django/pull/6688 - Fixed #26337 -- Added i18n 
note about using a non-English base language

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send 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/e49db2d2-3b9f-4faf-94eb-41b372759f81%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

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

2016-06-04 Thread Elf Sternberg 


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

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

[ANNOUNCE] Django bugfix release issued: 1.9.7

2016-06-04 Thread Tim Graham 
Details are available on the Django project weblog:

https://www.djangoproject.com/weblog/2016/jun/04/bugfix-release/

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

Re: Should we require pytz for timezone support in Django?

2016-06-04 Thread Carl Meyer 
On 06/04/2016 12:38 PM, Carl Meyer wrote:
> I just realized that I think something's gotten lost in this thread:
> Josh's original point was about requiring pytz _if you want timezone
> support_ (that is, if USE_TZ=True). That would I presume involve raising
> ImproperlyConfigured (or maybe having a site check raise an error?) if
> USE_TZ=True and pytz is not installed. I'd support this for sure: the
> "well, it might work OK without pytz if you're on Postgres" caveat is
> extra complexity for not much gain.
> 
> But this is not the same thing as putting pytz in install_requires,
> which makes it a required dependency for everyone using Django, even if
> they want USE_TZ=False.
> 
> I don't know how many USE_TZ=False projects there are. I always set
> USE_TZ=True, but I can imagine some small locally-oriented sites might
> have reason to prefer USE_TZ=False? If there is a significant number,
> and we want to continue to support their use-case, it's a non-zero added
> burden to require them to pull in a frequently-updated useless dependency.

FWIW: https://github.com/search?q=USE_TZ+%3D+False=Code

Carl

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


signature.asc
Description: OpenPGP digital signature

Re: Should we require pytz for timezone support in Django?

2016-06-04 Thread Carl Meyer 
I just realized that I think something's gotten lost in this thread:
Josh's original point was about requiring pytz _if you want timezone
support_ (that is, if USE_TZ=True). That would I presume involve raising
ImproperlyConfigured (or maybe having a site check raise an error?) if
USE_TZ=True and pytz is not installed. I'd support this for sure: the
"well, it might work OK without pytz if you're on Postgres" caveat is
extra complexity for not much gain.

But this is not the same thing as putting pytz in install_requires,
which makes it a required dependency for everyone using Django, even if
they want USE_TZ=False.

I don't know how many USE_TZ=False projects there are. I always set
USE_TZ=True, but I can imagine some small locally-oriented sites might
have reason to prefer USE_TZ=False? If there is a significant number,
and we want to continue to support their use-case, it's a non-zero added
burden to require them to pull in a frequently-updated useless dependency.

Carl

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


signature.asc
Description: OpenPGP digital signature

Re: Should we require pytz for timezone support in Django?

2016-06-04 Thread Philip James 
Adding pytz to install_requires might not contribute to a bug fix or new
feature right now, but it does remove a point of confusion from the docs. I
think it also reduces friction in getting Django up-and-running, which
seems valuable for Django users and Django contributors.

PJJ
http://philipjohnjames.com

On Sat, Jun 4, 2016 at 11:42 AM, Carl Meyer  wrote:

> On 06/03/2016 03:55 PM, Philip James wrote:
> > Is there consensus on making pytz required? (I, personally, am in favor,
> > since I too can't remember the last project I did that didn't need it.)
> >
> > If it's required, should it be vendored?
>
> -1 on vendoring pytz. I think it's fine to just make it a required
> dependency if that saves us significant work on a valuable new feature
> or refactoring. I don't really see the hurry to make it a required
> dependency just for its own sake, though.
>
> Carl
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django developers  (Contributions to Django itself)" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to django-developers+unsubscr...@googlegroups.com.
> To post to this group, send email to django-developers@googlegroups.com.
> Visit this group at https://groups.google.com/group/django-developers.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/57532114.20003%40oddbird.net
> .
> For more options, visit https://groups.google.com/d/optout.
>

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

Re: Should we require pytz for timezone support in Django?

2016-06-04 Thread Carl Meyer 
On 06/03/2016 03:55 PM, Philip James wrote:
> Is there consensus on making pytz required? (I, personally, am in favor,
> since I too can't remember the last project I did that didn't need it.)
> 
> If it's required, should it be vendored?

-1 on vendoring pytz. I think it's fine to just make it a required
dependency if that saves us significant work on a valuable new feature
or refactoring. I don't really see the hurry to make it a required
dependency just for its own sake, though.

Carl

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


signature.asc
Description: OpenPGP digital signature

Re: Should we require pytz for timezone support in Django?

2016-06-04 Thread Donald Stufft 

> On Jun 4, 2016, at 1:18 PM, Aymeric Augustin 
>  wrote:
> 
> That doesn’t sound optimal because pytz’ release cycle is tied to the TZ 
> database’s cycle, which is different from Django’s.


IMO just stick pytz in install_requires and be done with it. It’s a very 
trivial dependency, and is available as a Wheel, various eggs, and sdists. Just 
to put some numbers behind this:

93.6% of all downloads of Django from PyPI [1] are originating using a tool 
that will properly support dependencies out of the box. Another 3.5% of that 
are using a tool that we can’t detect— this is largely older versions of pip 
and devpi that didn’t accurately report themselves in the User-Agent header, so 
is going to also be largely things that support dependencies properly. Another 
2.3% of the downloads are coming from mirroring clients like devpi, 
bandersnatch, etc where it’s likely the consumers are mostly or entirely 
automated tooling that understands dependencies again.

Finally, 0.5% of all downloads for Django from PyPI are made using the browser, 
where people may or may not be passing that to a tool that properly understands 
dependencies.

In addition, the latest versions of all Python versions that Django supports 
come with pip already available, eliminating the bootstrapping issues.

Given these numbers, and the existing of ensurepip, I think it’s easily time 
for Django to just start depending on things, particularly when those things 
are something as trivial to install as a pure python library like pytz.

[1] Using the now public metrics database.

—
Donald Stufft



-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send 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/F935353C-45B1-414E-8851-57DAAFA1BB57%40stufft.io.
For more options, visit https://groups.google.com/d/optout.

Re: Should we require pytz for timezone support in Django?

2016-06-04 Thread Aymeric Augustin 
> On 04 Jun 2016, at 00:55, Philip James  wrote:
> 
> If it's required, should it be vendors?

That doesn’t sound optimal because pytz’ release cycle is tied to the TZ 
database’s cycle, which is different from Django’s.

-- 
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/9967F49D-0DA8-4A93-A90B-A41F8782EF65%40polytechnique.org.
For more options, visit https://groups.google.com/d/optout.