Re: revisiting the Python version support policy

[Claude Paroz]

Le mercredi 23 janvier 2019 08:31:17 UTC+1, James Bennett a écrit :
>
> I worry about the precedent we'd set if we made an exception for Debian, 
> because the next question would be "OK, can we have an exception for Red 
> Hat, too?" Keep in mind Red Hat currently sells up to fourteen years of 
> support for their RHEL platform.
>

You're right, the fact that this is Debian or any other distro doesn't 
matter here. My idea was to set the policy as : when a new major Django 
version is released, it supports all current supported versions of Python.

> People who want to contribute to Django probably already need to solve 
the problem of having multiple Python versions installed...

That's not my experience. It was during Python 2/3 coexistence, but now if 
you develop with any Python 3 version, the rare cases where Python version 
incompatibilities happen are catched by the CI runs.

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/3160ff66-d0cf-44a4-af00-1330854b8295%40googlegroups.com.
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

[Perry Roper]

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. An option to disable the internal token redirect might be 
> useful, but that then re-opens the token up to being leaked via the 
> HTTP_REFERER header.
>
> Regards,
>  - Mat
>

-- 
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/7db0b6fc-073d-4794-8195-01c3d51dfb72%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Potential suspension of Channels development

[Christian González]

Hi,

I'm no experienced developer nor a Django contributor, but I "suffered" 
from this theme too. What I tried in the past is to create a Django 
"application", or more a framework (https://pypi.org/project/gdaps/), to 
support "plugins" which consist of a backend (the django part), and an 
included frontend (which shoud contain a "plugin" of a Js-framework like 
Vue.js or Angular, etc) that "blends" in into the web client dynamically.


I have experimented with using templates serving Vue code, or separating 
the part that is served to the browser from the Django backend in a 
different directory, bypassing Django templates, and did not succeed much.


This all is not directly related to the theme here, but where it is 
connected, is that, for writing a modern application nowadays, you IMHO 
have to be responsive in the frontend, and I think that async calls are 
not smart enough to solve that.


If you ever tried the "easiness" of Meteor, you always envy that when 
using Django with templates.


So: If I had a wish to Santa Claus :-), I would really support Django 
having "Channels" (or however it may be named) included more deeply into 
the system: I think that the Templates approach is not the worst, 
because it is very flexible. It just doesn't have a solution to the 
communication problem between server and client. Again, if I could wish 
something, It would be Integration of frontend frameworks into the 
template language and having calls to e.g. DRF included INTO the 
template language, like the "batteries included" approach of Meteor with 
their "connected" variables that update automatically when another 
client changes them.


This all is possible with Django DRF, channels and a modern Js 
framework, but VERY much boilerplate code and hand-written updates, 
no-way modern.


I know it's much I demand here - I just want to add my 2cents - Django 
is GREAT software.


It's just that the frontend side (templates, auto-communication and data 
bindings) did not gain that much love as the backend.


Maybe you'll say "Hey, Django IS only a backend". Yes and no. If so, you 
can remove the templates completely. It's not a backend, it just 
focussed on the backend more than on the frontend.


If there would be a way to integrate channels more deeply into Django, 
together with frontend 2-way data bindings, push notifications etc., I 
would really appreciate it and could imagine supporting that using money 
too.


Cheers,

Christian


Am 22.01.19 um 15:18 schrieb John Obelenus:
Chiming in. As a long-time django user (nearly a decade), websockets 
is an area that the project on the whole is very, very, far behind the 
leading edge of the web industry. It's great, often desirable, to not 
be *on* the leading edge, but in my opinion, the project is too far 
behind it.


There are numerous projects where I would, now, not consider using 
django (or at least, using it only for the admin to save time/effort). 
That is the first issue that I see for the django project as a whole.


Secondly, and probably something Andrew expects to be helped (if not 
outright solved), is the general speed of serving requests. Async can 
absolutely help here (How much it helps is up for debate). As a 
developer who is using a lot more NodeJS now the inherent speed in 
that platform's request lifecycle can often be a game-changer in terms 
of performance and resources needed.


On Monday, January 21, 2019 at 2:57:18 PM UTC-5, Andrew Godwin wrote:



On Mon, Jan 21, 2019 at 4:34 AM Michael Martinez
> wrote:

Hi Andrew

To me, Websockets is the defining use case for using Django
Channels. From a user POV, saying that Channels is focused on
the wrong problem (websockets) is like saying Django is too
focused on HTTP.

When I have selected Channels (vs other tools), my rationale
was not:

"/I need a general purpose async platform and it would be
great if it worked with Websockets, ZeromQ and played nice
with Django.../" (therefore Django Channels vs Tornado vs ...)


rather my rationale is more like:

"/I need to build real time features with Websockets using
Django../" (therefore Django Channels).


Oh, I totally get that, and Channels does well at providing
WebSockets - the problem is that it's still an area with a lot
less interest and also one I personally have no use for at the
moment. Those things combined mean that WebSockets is not
something I'm really interested in supporting for free right now;
I'd have to be paid to work on it (as I was with the Mozilla grant
for a lot of Channels' development).

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