Re: revisiting the Python version support policy

[Joe Tennies]

Comments inlined:

On Sat, Jan 26, 2019 at 7:51 PM Alex Krupp  wrote:

> The biggest issues with beginners I see at events like Django Girls or
> just regular Python meetups involve people needing to edit their
> .bash_profile or .bashrc files. Most people can figure out how to download
> the right version of Python for their platform, but then their shell to
> actually use that version of Python is where things go sideways. Same thing
> with setting the DJANGO_SETTINGS_MODULE.
>

Interesting. I mean, I'm a fairly seasoned Linux guy, so I know exactly
what you're talking about for the bash configs, but I actually don't think
I've ever edited them for Django. I tend to use virtualenv, then venv, now
I'm trying to remember to use pyenv instead of just doing it manually.


>
> The basic issues are:
>
> - Figuring out which version of python3 your interpreter is using (and
> even knowing you need to know that)
>

In a small group tutorial, I'd expect that to be part of your training.
That stated, I can see that


> - Knowing how to open the appropriate shell settings file, add the right
> line in the right place, and save it. (Especially since if there is already
> stuff there, beginners aren't going to have any idea what any of it is
> doing which only adds to the confusion.)
>

Interesting. I still have the opposite issue that there's whole sets of
overridable settings that are just imported on your behalf that I don't
know I can override.


>
> - Knowing they need to open a new terminal window or source the settings
> file.
>
> - Knowing how to read the error message if something went wrong, and the
> fix whatever the problem is.
>

To some extent, this is the problem with every new framework of any sort
you pick up. The only way to get better is through just doing it a lot.
It's a bit harsh and shouldn't be interpreted as "We shouldn't make them
better" (because we should always make them better), but I think at some
point the best way to learn is to fail and flail for a bit.

I do training for my company on Python. Now, they are all professional
programmers of some level or another, but I give just enough information
for someone to hang themselves on purpose. Now that's better in a scenario
where there's people there to help you get up to speed (not just the Django
tutorial), but we got quite a few people that complained that I let them do
the wrong thing for 5 minutes to learn... until the end where they thanked
me because they got a much better understanding in the end.


>
> - Knowing how to actually install Django... E.g. pip vs pip3, to sudo or
> not to sudo, etc.
>

I learned pre-pip, so I get it... but I'm a greybeard now, so I think
Django is the gateway drug to the Python world in general. One thing I'd
like to see in general is Django (or probably a group of Django users) get
more opinionated. The only thing I think I've ever heard was South being
the best choice and a general leaning towards Postgres. I had done a fair
amount of work on Drupal back in the day, and that was the big thing
Lullabot brought to the table in that community.


>
> - Knowing what version of Django to install. E.g. beginners mostly aren't
> going to know what LTS stands for or understand the implications of that.
>

This is why I think the LTS needs to be the prominent version on the
webpage and have a blurb about why one SHOULD choose LTS or not.


>
> For beginners, just getting to the point where running the development
> server doesn't throw an error is probably harder than the rest of the
> tutorial combined. So I think making it as easy as possible for beginners
> is a real issue that should be prioritized. As an anecdote, the only reason
> why Reddit is built on Postgres instead of MySQL is that they couldn't
> figure out how to get MySQL installed and running.
>
> That being said, my understanding is that there are a bunch of API changes
> to Python's async modules between Python 3.5 and 3.6, and I know having
> async functionality in Django is a big deal for a lot of people. If there's
> money to pay people to work on that full time then it doesn't matter as
> much, but if there isn't then I'm assuming a lot of that work will probably
> get pushed back a year to when it'll at least be less work, which is
> potentially problematic if it's already going to be a multiyear project as
> is.
>
> While async itself doesn't especially impact me at this point, obviously
> everyone benefits from having smart people in the larger Python/Django
> community to create and maintain the packages we all depend on, and I worry
> about losing folks to node or golang.
>

I mean that is generally outside this conversation as I don't believe
there's a chance of making it in for the 3.0 LTS release.


>
> I'm not a core developer or otherwise especially active so I could be just
> misreading to the situation here, but as a casual observer this seems like
> a bigger risk... Even if getting Django up and running properly is a real
> 

Re: revisiting the Python version support policy

[Alex Krupp]

The biggest issues with beginners I see at events like Django Girls or just 
regular Python meetups involve people needing to edit their .bash_profile 
or .bashrc files. Most people can figure out how to download the right 
version of Python for their platform, but then their shell to actually use 
that version of Python is where things go sideways. Same thing with setting 
the DJANGO_SETTINGS_MODULE.

The basic issues are:

- Figuring out which version of python3 your interpreter is using (and even 
knowing you need to know that)

- Knowing how to open the appropriate shell settings file, add the right 
line in the right place, and save it. (Especially since if there is already 
stuff there, beginners aren't going to have any idea what any of it is 
doing which only adds to the confusion.)

- Knowing they need to open a new terminal window or source the settings 
file.

- Knowing how to read the error message if something went wrong, and the 
fix whatever the problem is.

- Knowing how to actually install Django... E.g. pip vs pip3, to sudo or 
not to sudo, etc. 

- Knowing what version of Django to install. E.g. beginners mostly aren't 
going to know what LTS stands for or understand the implications of that.

For beginners, just getting to the point where running the development 
server doesn't throw an error is probably harder than the rest of the 
tutorial combined. So I think making it as easy as possible for beginners 
is a real issue that should be prioritized. As an anecdote, the only reason 
why Reddit is built on Postgres instead of MySQL is that they couldn't 
figure out how to get MySQL installed and running.

That being said, my understanding is that there are a bunch of API changes 
to Python's async modules between Python 3.5 and 3.6, and I know having 
async functionality in Django is a big deal for a lot of people. If there's 
money to pay people to work on that full time then it doesn't matter as 
much, but if there isn't then I'm assuming a lot of that work will probably 
get pushed back a year to when it'll at least be less work, which is 
potentially problematic if it's already going to be a multiyear project as 
is.

While async itself doesn't especially impact me at this point, obviously 
everyone benefits from having smart people in the larger Python/Django 
community to create and maintain the packages we all depend on, and I worry 
about losing folks to node or golang.

I'm not a core developer or otherwise especially active so I could be just 
misreading to the situation here, but as a casual observer this seems like 
a bigger risk... Even if getting Django up and running properly is a real 
pain point for beginners, which it is, it's at least getting easier every 
year because there are more people and places (both IRL and online) to ask 
for help. Whereas we've seen a lot of posts recently both on this list and 
from other folks in the Python community about burn out, and so at least 
for me doing what we can to ameliorate this by reducing the time it takes 
to add new features and maintain existing ones is what I would personally 
prioritize over 3.5 support.

Anyway sorry for bikeshedding into this, just wanted to bring up a couple 
points that weren't mentioned previously.


On Saturday, January 26, 2019 at 5:15:36 PM UTC-5, Rotund wrote:
>
> Carlton,
>
> I read your response, and I think what you said is very important. I would 
> like to ask you a few questions, if you don't mind. I'm not trying to back 
> you into a corner; I'm trying to understand what you see with your teaching 
> and getting insight from that.
>
> Do you think it makes sense to have beginners working off non-LTS 
> versions? Personally, I think the LTS is the version that beginner's should 
> run. They're "real" projects are likely to take longer, and they aren't 
> going to want to track the latest and greatest. I also think that any 
> non-LTS version of the docs should have a similar heading to the dev 
> version to suggest that beginners likely would benefit from using the 
> latest LTS version.
>
> How many people coming to your trainings are running a stable/enterprise 
> Linux distro? It's pretty quick to get the right version for Windows. As 
> far as Linux, I would expect to see mainly the big couple Linux distros. 
> The more esoteric rolling releases should obviously be fine due to their 
> rolling nature. Therefore, I want to just do an analysis. As far as 
> supported Ubuntu releases go, 18.04LTS and all supported non-LTS are fine. 
> Ubuntu 16.04 and 14.04 are both LTS version and still supported by 
> Canonical. I believe Mint still follows Ubuntu. As far as Debian, testing 
> and unstable have 3.7, but stable has 3.5.3. As far as Fedora, Version 26 
> and above have python 3.6 or newer. I believe we've discussed RHEL/CentOS, 
> but it appears that anything before 8 doesn't have Python 3 at all, and the 
> CentOS7 SCL has Python 3.6 in it. I don't know which other Linux distros 
> are 

Re: revisiting the Python version support policy

[Joe Tennies]

Carlton,

I read your response, and I think what you said is very important. I would
like to ask you a few questions, if you don't mind. I'm not trying to back
you into a corner; I'm trying to understand what you see with your teaching
and getting insight from that.

Do you think it makes sense to have beginners working off non-LTS versions?
Personally, I think the LTS is the version that beginner's should run.
They're "real" projects are likely to take longer, and they aren't going to
want to track the latest and greatest. I also think that any non-LTS
version of the docs should have a similar heading to the dev version to
suggest that beginners likely would benefit from using the latest LTS
version.

How many people coming to your trainings are running a stable/enterprise
Linux distro? It's pretty quick to get the right version for Windows. As
far as Linux, I would expect to see mainly the big couple Linux distros.
The more esoteric rolling releases should obviously be fine due to their
rolling nature. Therefore, I want to just do an analysis. As far as
supported Ubuntu releases go, 18.04LTS and all supported non-LTS are fine.
Ubuntu 16.04 and 14.04 are both LTS version and still supported by
Canonical. I believe Mint still follows Ubuntu. As far as Debian, testing
and unstable have 3.7, but stable has 3.5.3. As far as Fedora, Version 26
and above have python 3.6 or newer. I believe we've discussed RHEL/CentOS,
but it appears that anything before 8 doesn't have Python 3 at all, and the
CentOS7 SCL has Python 3.6 in it. I don't know which other Linux distros
are still generally relevant. I don't know the OSX world, but I assume you
can get a binary installer that's no harder than any other Python version.

On Sat, Jan 26, 2019 at 3:10 AM Carlton Gibson 
wrote:

> I worry about us making this kind of decision in the rarified air of the
> developer mailing list. It's a technical question yes, but it affects the
> entire community.
>
> I think, here, we underplay just how hard it is for people out there. IMO
> expecting that people suffering from massive information overload to
> successfully switch docs version is already setting the bar too high.
> People really struggle.
>
> I'll give you one concrete example.
>
> Teaching DjangoGirls in Barcelona, one student—presumably for EXACTLY the
> kind of version mis-match we're talking about here—had her project created
> with a different version of the template than everybody else's. It didn't
> have contrib.staticfiles in INSTALLED_APPS. As such, where everyone else
> was able to deploy, her deployment failed. In the end there were
> instructors from three tables around here laptop trying who-knows-what in
> the shell before it was worked out and resolved. ("Try `collectstatic`
> locally" led to the answer.)
>
> Without those instructors present that student would have been stuck at
> that point, and lost.
>
> I don't have figures, and we never hear from most of these people, but I
> guess this sort of difficulty happens a lot.
> A quick scan of django-users suggests it's all the time.
>
> > ...there's a new test failure after a recent patch due to
> non-deterministic dict ordering in Python 3.5 which demonstrates the sort
> of minor annoyances that take time away from making useful improvements to
> Django.
>
> It's not that I don't hear you hear. I do.
>
> It's just that I think of this as an accessibility issue, and
> accessibility is a feature too.
>
> For me, if the cost of including someone is that we have to use
> OrderedDict for a wee-bit longer, then so be it.
>
> Kind Regards,
>
> Carlton
>
>
> --
> 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/2c23caa4-b83a-4e45-9811-a62af2b4c311%40googlegroups.com
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>


-- 
Joe Tennies
tenn...@gmail.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 

Re: Introduction as a new member to django contributions mailing list

[Dylan Reinhold]

On the project home page https://www.djangoproject.com/  it has the link on
how to contribute.

https://docs.djangoproject.com/en/dev/internals/contributing

If you have a specific question feel free to ask, but this is a good
starting point.

Dylan

On Sat, Jan 26, 2019 at 10:51 AM Yemdjih Kaze Nasser 
wrote:

> Hello
> My names are Yemdjih Kaze Nasser and I am new to the mailing list and I
> would like to contribute the django organisations.
> Please can how can I get started
>
> --
> 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/50a23743-d915-429d-be51-271cc54d13eb%40googlegroups.com
> 
> .
> 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/CAHtg44CJfsoKggmTphuj7jZGRRm09797%2BzUQ%3DiwbCwHKGWbYEw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Introduction as a new member to django contributions mailing list

[Yemdjih Kaze Nasser]

Hello
My names are Yemdjih Kaze Nasser and I am new to the mailing list and I 
would like to contribute the django organisations.
Please can how can I get started

-- 
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/50a23743-d915-429d-be51-271cc54d13eb%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Automatically initialise the project as git repo

[Dmitriy Sintsov]

On Friday, January 25, 2019 at 3:35:40 PM UTC+3, mihir karbelkar wrote:
>
> Hi,
> I have made several projects with Django but every time I create a new 
> project I have to initialize the repo for git. It would be better if the 
> project initialized itself. Maybe we can add this feature in to help make 
> development "even faster to meet goals in record time".
> I would love to work on this but it will only be my first contribution 
> so If we agree on this I can open probably open an issue and work on it.
> Also I would like to work for django in GSOC 2019 so any help would be 
> appreciated.
> Thanks.
>

Git is not the only choice. There is Mercurial version control system, 
which is written in Python and thus I prefer it for private non-git 
repositories of code. You can even "import mercurial" from Django code to 
get the current revision, for example. Favoring git only which is 
non-Python solution would be to opinionated.

-- 
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/2bc5dac0-ac96-4ea1-9a45-9a829a34619c%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: revisiting the Python version support policy

[Carlton Gibson]

I worry about us making this kind of decision in the rarified air of the 
developer mailing list. It's a technical question yes, but it affects the 
entire community. 

I think, here, we underplay just how hard it is for people out there. IMO 
expecting that people suffering from massive information overload to 
successfully switch docs version is already setting the bar too high. 
People really struggle. 

I'll give you one concrete example. 

Teaching DjangoGirls in Barcelona, one student—presumably for EXACTLY the 
kind of version mis-match we're talking about here—had her project created 
with a different version of the template than everybody else's. It didn't 
have contrib.staticfiles in INSTALLED_APPS. As such, where everyone else 
was able to deploy, her deployment failed. In the end there were 
instructors from three tables around here laptop trying who-knows-what in 
the shell before it was worked out and resolved. ("Try `collectstatic` 
locally" led to the answer.) 

Without those instructors present that student would have been stuck at 
that point, and lost. 

I don't have figures, and we never hear from most of these people, but I 
guess this sort of difficulty happens a lot. 
A quick scan of django-users suggests it's all the time. 

> ...there's a new test failure after a recent patch due to 
non-deterministic dict ordering in Python 3.5 which demonstrates the sort 
of minor annoyances that take time away from making useful improvements to 
Django.

It's not that I don't hear you hear. I do. 

It's just that I think of this as an accessibility issue, and accessibility 
is a feature too. 

For me, if the cost of including someone is that we have to use OrderedDict 
for a wee-bit longer, then so be it. 

Kind Regards,

Carlton


-- 
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/2c23caa4-b83a-4e45-9811-a62af2b4c311%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.