Fellow Report - June 4, 2016
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
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
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?
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&type=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?
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?
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?
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?
> 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?
> 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.