Comments inlined:
On Sat, Jan 26, 2019 at 7:51 PM Alex Krupp <alex.kr...@gmail.com> 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
> 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 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 <carlton...@gmail.com>
>> 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-develop...@googlegroups.com.
>>> To post to this group, send email to django-d...@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
>>> <https://groups.google.com/d/msgid/django-developers/2c23caa4-b83a-4e45-9811-a62af2b4c311%40googlegroups.com?utm_medium=email&utm_source=footer>
>>> .
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>>
>>
>> --
>> Joe Tennies
>> ten...@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
> https://groups.google.com/d/msgid/django-developers/c948baf5-91a2-4577-aeaa-89735bb2e444%40googlegroups.com
> <https://groups.google.com/d/msgid/django-developers/c948baf5-91a2-4577-aeaa-89735bb2e444%40googlegroups.com?utm_medium=email&utm_source=footer>
> .
> 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
https://groups.google.com/d/msgid/django-developers/CACiOJ6sSRut8TAqB0XT1ak2%2BFiHhtvRezsoXb_25EajcuZGDaA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
