Re: Type hints, PEP 561, and mypy-django
FYI we're chatting on https://gitter.im/mypy-django/Lobby about organising this. Feel free to drop by there. On 0, Luke Murphy wrote: Hi folks, Following a short discussion over at: https://github.com/machinalis/mypy-django/issues/9, There is some renewed interest in getting stuck into type hints for Django. I wanted to drop a mail here to see what the status is. In preparation for this email, I've been combing the Django issue tracker and some related project Github issues to see what has already been done and adding notes over at: https://github.com/lwm/mypy-django/issues/1 Was I correct in discovering that there is some general consensus on waiting PEP 561 to land? It seems like that PEP has been accepted and there are three options for implementation: PEP 561 notes three main ways to distribute type information. The first is a package that has only inline type annotations in the code itself. The second is a package that ships stub files with type information alongside the runtime code. The third method, also known as a “stub only package” is a package that ships type information for a package separately as stub files. I saw mention of the necessity of DEP being submitted. Has it been done yet or started? I can't see anything related over at: https://github.com/django/deps Hope someone can enlighten me, thanks! Best, Luke -- You received this message because you are subscribed to the Google Groups "Django developers (Contributions to 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/20180722111916.xvbjtbxs7d2zu6jy%40lostatsea.lostatsea. 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/20180723075146.qsz2sa2tbg2wbldl%40lostatsea.lostatsea. For more options, visit https://groups.google.com/d/optout.
Request middleware
Hi, in our codebase we made use of this gist[1], which relies on a private API, but more importantly, creates requests without going through the response chain. This is relevant for catching exceptions in Middleware: there were two tests that explicitly test for DISALLOWED_HOST and I had to rewrite them to test for a 400 response. I don't see an easy way to restore the old behavior and stick to official API's. Am I missing something or is this correct? -- Melvyn Sopacua [1] https://gist.github.com/tschellenbach/925270 -- You received this message because you are subscribed to the Google Groups "Django developers (Contributions to 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/1724107.Ul47RLQj4Y%40fritzbook. For more options, visit https://groups.google.com/d/optout.
App static files (#29586)
Hi, I just created a new feature request [1] to be able to define static files per application, including a POC patch [2]. [1] https://code.djangoproject.com/ticket/29586 [2] https://github.com/django/django/pull/10218 Feel free to discuss it here for general discussion on the feature utility, or comment on the ticket or on the pull request for implementation details. Cheers, Claude -- www.2xlibre.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 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/fddae41c-d53b-20fc-0b24-444f89e64f52%402xlibre.net. For more options, visit https://groups.google.com/d/optout.
Re: App static files (#29586)
Hi Claude, a few things after a quick glance at it. Overall the feature seems rather simple and I do not see any reason why this would have to be in core from the start; ie it could easily evolve as a 3rd party app. I am not that much into frontend dev, but from my experience a few things popped up rather quickly: * I generally do not load all js/css in bulk, but rather only the essential stuff in and the rest before the ends. (or even just selecting files by type; css vs js etc…) * The app level seems to be a rather coarse grained separation, I could imagine people wanting more control over it without generating more apps for separation. * How would support for subressource integrity etc look like; integration with the storage system would be interesting here * Any thoughts on asset pipelines? Cheers, Florian On Monday, July 23, 2018 at 5:36:05 PM UTC+2, Claude Paroz wrote: > > Hi, > > I just created a new feature request [1] to be able to define static > files per application, including a POC patch [2]. > > [1] https://code.djangoproject.com/ticket/29586 > [2] https://github.com/django/django/pull/10218 > > Feel free to discuss it here for general discussion on the feature > utility, or comment on the ticket or on the pull request for > implementation details. > > Cheers, > > Claude > -- > www.2xlibre.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 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/25e0a1bd-5592-478b-a06b-ff01b1d5bbe9%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: App static files (#29586)
On Mon, Jul 23, 2018 at 12:12 PM Florian Apolloner wrote: > * Any thoughts on asset pipelines? > This seems like it would be critical functionality. It might also help users to avoid potential asset ordering issues without needing to create more apps to resolve conflicts. Regards, Michael Manfre -- You received this message because you are subscribed to the Google Groups "Django developers (Contributions to 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/CAGdCwBsxR7KpKEgBQFkXOy-MuN79LJM1eNC30XUGkCrDuHLiaA%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
Re: App static files (#29586)
Le lundi 23 juillet 2018 18:12:32 UTC+2, Florian Apolloner a écrit : > > Hi Claude, > > a few things after a quick glance at it. Overall the feature seems rather > simple and I do not see any reason why this would have to be in core from > the start; ie it could easily evolve as a 3rd party app. > I purposely kept minimal functionality to start with. The idea is to have a minimal common structure in core, so as 3rd party apps can build upon that minimal structure and add more functionality. e.g. more Asset subclasses can be created to customize behavior. > I am not that much into frontend dev, but from my experience a few things > popped up rather quickly: > > * I generally do not load all js/css in bulk, but rather only the > essential stuff in and the rest before the ends. (or even > just selecting files by type; css vs js etc…) > I think that once you have an asset list, you can program the logic specific to your application. The site_static template tag could be considered mainly as an implementation example. > * The app level seems to be a rather coarse grained separation, I could > imagine people wanting more control over it without generating more apps > for separation. > Once again, one can program a more specific logic by Asset subclasses in the app config assets. A JS() subclass could accept a 'section' parameter which could then be used to segment asset rendering. > * How would support for subressource integrity etc look like; integration > with the storage system would be interesting here > I think this is typically something that should be trivial to implement after this patch is in core. It might be as simple as adding an appropriate kwarg to the Asset() class. > * Any thoughts on asset pipelines? > Sure, the idea is to put a base structure in place to support such functionalities at a later stage (in core or as 3rd party like django-compressor). Thanks for your input! On Monday, July 23, 2018 at 5:36:05 PM UTC+2, Claude Paroz wrote: > > Hi, > > I just created a new feature request [1] to be able to define static > files per application, including a POC patch [2]. > > [1] https://code.djangoproject.com/ticket/29586 > [2] https://github.com/django/django/pull/10218 > > Feel free to discuss it here for general discussion on the feature > utility, or comment on the ticket or on the pull request for > implementation details. > > Cheers, > > Claude > -- > www.2xlibre.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 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/8601fa06-0b66-487d-8d76-165f8f334f65%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: App static files (#29586)
Hi Claude, On Monday, July 23, 2018 at 8:14:23 PM UTC+2, Claude Paroz wrote: > > Sure, the idea is to put a base structure in place to support such > functionalities at a later stage (in core or as 3rd party like > django-compressor). > I am just a little bit worried about adding this without any concrete plan on how 3rd party apps are going to use it. What speaks against trying this outside of core like channels? (I'll happily put it under the django umbrella, but core seems a little bit fast tracked to me). Cheers, Florian -- You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-developers+unsubscr...@googlegroups.com. To post to this group, send email to django-developers@googlegroups.com. Visit this group at https://groups.google.com/group/django-developers. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/53604cdc-73b3-44e6-bccf-7744e2b7f84c%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: App static files (#29586)
Le lundi 23 juillet 2018 20:32:55 UTC+2, Florian Apolloner a écrit : > > Hi Claude, > > On Monday, July 23, 2018 at 8:14:23 PM UTC+2, Claude Paroz wrote: >> >> Sure, the idea is to put a base structure in place to support such >> functionalities at a later stage (in core or as 3rd party like >> django-compressor). >> > > I am just a little bit worried about adding this without any concrete > plan on how 3rd party apps are going to use it. What speaks against trying > this outside of core like channels? (I'll happily put it under the django > umbrella, but core seems a little bit fast tracked to me). > > I think that such little code doesn't make much sense as a 3rd party app. Either we consider it a common base to build upon by 3rd parties or we conclude that it isn't worth to have such a base. One of the goal of this thread is to hear from potential users of this proposed API. I'll see if I can add subresource integrity support to demonstrate a potential added value. 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/4cfce3d2-2b66-49be-ad1b-e25f98659713%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Partial indexes, PR help
Hi, I've opened a PR to add support for partial indexes in Django. It's on the right track, but I bumped into an issue that I need help with. On PostgreSQL, the cast that's introduced when doing something like: Q(published__gt=datetime.date(2017, 10, 1)) => "table"."published" > '2017-10-01'::timestamp; is unfortunate because it turns the function mutable, and the index can therefore not be created (exact error message can be seen in the Jenkins output). I think that's a plausible use-case for a partial index to limit on dates. Locally, I have two tests that filters on the "id" (I didn't see any reason to introduce a new integer column in either of the existing models; using "pk" instead raised a warning about the column not being present) and one that filters on a boolean. Both were suggestions from Markus Holtermann on what he had seen used in production. There was already something for text strings. My problem is that I'm a bit in the wild how to battle the lookup-cast issue on PostgreSQL. I've already tried to study the Lookup-flow. I see two ways: 1. Describe this short-coming well in the documentation, and leave it like this. 2. Introduce a flag that can trigger the cast in this special case. I didn't check to see how much of this that's public API and how much that isn't. It's what I'd favour, but also more difficult. There's enough time to the feature freeze of Django 2.2 to have the first option as a last resort. The tests are still failing, and Oracle had some transaction problem, that I'm also very oblivious about. Again, error messages are in the Jenkins output. Link to the PR: https://github.com/django/django/pull/10140 -- Med venlig hilsen / Kind regards, Mads Jensen Saajan Fernandes: I think we forget things if there is nobody to tell them. -- The Lunchbox (2013) -- You received this message because you are subscribed to the Google Groups "Django developers (Contributions to 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/c465d23f-0090-ee6b-98b5-9b1202beda39%40inducks.org. For more options, visit https://groups.google.com/d/optout.
Re: Partial indexes, PR help
> On Jul 23, 2018, at 12:20, Mads Jensen wrote: > > Q(published__gt=datetime.date(2017, 10, 1)) > => > "table"."published" > '2017-10-01'::timestamp; > > is unfortunate because it turns the function mutable, and the index can > therefore not be created (exact error message can be seen in the Jenkins > output). I think the issue is that you are mixing TIMESTAMP and TIMESTAMPTZ here xof=# create table i (p timestamptz); CREATE TABLE xof=# create index on i(p) where p > '2011-01-01'::timestamp; ERROR: functions in index predicate must be marked IMMUTABLE xof=# create index on i(p) where p > '2011-01-01'::timestamptz; CREATE INDEX xof=# create table i (p timestamp); CREATE TABLE xof=# create index on i(p) where p > '2011-01-01'::timestamptz; ERROR: functions in index predicate must be marked IMMUTABLE xof=# create index on i(p) where p > '2011-01-01'::timestamp; CREATE INDEX -- -- Christophe Pettus x...@thebuild.com -- You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-developers+unsubscr...@googlegroups.com. To post to this group, send email to django-developers@googlegroups.com. Visit this group at https://groups.google.com/group/django-developers. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/C136730A-1C63-47FB-8B24-C1800EC8C778%40thebuild.com. For more options, visit https://groups.google.com/d/optout.
Re: App static files (#29586)
Le lundi 23 juillet 2018 21:17:24 UTC+2, Claude Paroz a écrit : > I'll see if I can add subresource integrity support to demonstrate a > potential added value. > Just for feasibility's sake, here's a quick (and probably dirty) way to implement subresource integrity based on the new code. https://github.com/claudep/django/commit/cba848c3590949e78861ce95c3cc466456c15870 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/4e7d94e0-fcd5-4931-969d-0621a72b9557%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Connecting to remote host like Twitch to monitor chat using websockets
Greetings, Is it possible to use Django Channels and websockets to monitor the chat in twitch rooms, or other sites with chat rooms? I would like to display extra graphics for users who send cheers of high amounts, like 1000, 2000, etc. I have the display worked out in Django where I'm monitoring a simple local chat. This would be used as an overlay web page for OBS for the broadcaster. When someone posts a specific cheer amount, the javascript displays a message or gif on the overlay web page with a short timeout. It's basically to say Thank You to the tipper. I haven't found any documentation or tutorials on using Django Channels for anything but setting up my own chat program. In the consumers, is there a way to connect to a site like twitch and search the DOM for specific chat messages, like cheers? Thanks. -- You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-developers+unsubscr...@googlegroups.com. To post to this group, send email to django-developers@googlegroups.com. Visit this group at https://groups.google.com/group/django-developers. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/196c5d4c-6ced-400d-a953-53918980eca8%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Partial indexes, PR help
> On Jul 23, 2018, at 13:05, Christophe Pettus wrote: > > >> On Jul 23, 2018, at 12:20, Mads Jensen wrote: >> >> Q(published__gt=datetime.date(2017, 10, 1)) >> => >> "table"."published" > '2017-10-01'::timestamp; >> >> is unfortunate because it turns the function mutable, and the index can >> therefore not be created (exact error message can be seen in the Jenkins >> output). > > I think the issue is that you are mixing TIMESTAMP and TIMESTAMPTZ here [...] To be a bit clearer, this seems to be in effect a mixing-aware-and-unaware timestamp issue, just pushed down into PostgreSQL. -- -- Christophe Pettus x...@thebuild.com -- You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-developers+unsubscr...@googlegroups.com. To post to this group, send email to django-developers@googlegroups.com. Visit this group at https://groups.google.com/group/django-developers. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/E38CA9A0-47E5-48B6-B08A-6759A6429FAA%40thebuild.com. For more options, visit https://groups.google.com/d/optout.