[Python-Dev] Software integrators vs end users (was Re: Language Summit notes)

[Nick Coghlan]

On 18 April 2014 16:27, Paul Moore <p.f.moore at gmail.com> wrote:
> On 18 April 2014 20:18, Nick Coghlan <ncoghlan at gmail.com> wrote:
>> At this point, however, I'm mainly looking for consensus that there
>> *are* two different problems to be solved here, and solving them both
>> well in a single tool is likely to be nigh on impossible. (I'm aware
>> we're really on the wrong list for that discussion, but I also think
>> there's value in getting some broader python-dev awareness of this
>> particular topic)
>
> I'm not entirely sure what you're proposing here.
>
> Obviously there are multiple classes of users (whether it's as simple
> as just two, or whether there's more is less important).
> Clearly there is a case for curated stacks and OS distributions, and
> clearly some people use those stacks and distributions.
> Things aren't perfect - CPython and projects like pip need to be aware
> of, and respond to, the differing needs of people who use Python in
> different ways.
>
> But what are you suggesting python-dev needs to *do* about this? What
> precisely is wrong with how we deal with the multiple types of user
> that exist at the moment?

When you go to python.org, you are currently advised to download one
of the following:

- a source tarball (Linux)
- a bare bones binary installer (Windows & Mac OS X)

What I am advocating for is that *we are currently doing it wrong*, as
these are unlikely to be the best thing to install for most new Python
users. Now, we could make things even *more* confusing by instead
presenting the prospective user with *even more* choices, like "oh,
you might want to get it from your Linux distro, or maybe homebrew, or
MacPorts", but that's not helping, because it's asking new users to
make choices that they may not be in a position to make.

>From a usability perspective, I don't believe we should be advertising
a minimalist installation as the preferred entry point for new users -
we should be advertising a full featured sumo distribution that lets
new users quickly experience the full power and flexibility of things
like IPython notebooks. I like Anaconda, because it's fully open
source, abstracts away the underlying operating system more than the
standard installers and the same mechanism that you use to update
packages can also be used to update the Python interpreter itself.

Everything else we do today should remain available for those that
want them - I'm not advocating taking anything away. But we need to
start getting more opinionated on behalf of new users that don't yet
have the experience they need to start challenging our judgement and
make their own choices about which tools to use out of the vast array
of choices the Python ecosystem provides.

> Without wanting to sound like I'm taking things personally, it feels
> like there's an intention to suggest to *some* people that they would
> be better served by a curated stack. I don't know how to answer that
> except from a personal perspective[1], and it's hard to do that
> without knowing whether I'm in a group that you'd see as benefiting
> from a curated stack.

No, I don't think you'd benefit substantially from a curated stack - I
don't think any experienced Python user would. But think through your
own personal stack. Start from a Google search for "Python tutorial"
and see how easily you can figure out how and where to obtain all
those components.

Putting a sumo distribution front and centre on the website
drastically improves the out of the box experience for new users,
*without* introducing a huge maintainability issue for the standard
library. New users gain quick access to a much larger fraction of the
overall Python ecosystem, while on the back end software *production*
side of things, everything stays decoupled.

It also provides a clearer timeline for adoption of new versions of
Python - while the reference interpreter would go up immediately, the
sumo version would only be updated once all the contained projects had
been checked for compatibility with the new version.

> One thing I *would* suggest is that a lot of "corporate" use of Python
> (by which I mean semi-informal scripting and automation done as part
> of the infrastructure of larger projects written in more "enterprise"
> tools like Java or higher level CRM/eBusiness/etc packages) is not
> suitable for a curated stack (corporate IT policies would see that as
> a "3rd party tool" where the python.org distribution is just a
> project-internal utility). But the staff involved are typically not
> familiar with open source or its culture, and struggle to deal with
> things like package management (this is *not* the "legal approval"
> issue, as cut and paste of code from websites is common in this
> culture - it's "internal use only"). Within the context of your two
> categories, this may well be a third one (unless you stretch
> "application developers" way beyond what I think you are intending).

No, that is the case covered by 'creators of corporate "Standard
Operating Environment" definitions'. That's explicitly in the software
integrator category - whether those users formally have the
responsibility of defining an SOE, that's what they're doing in
practice.

Cheers,
Nick.

>
> Paul
>
> [1] By which I mean "looking at what I use Python for, how I see it
> used by others in my organisation, and how I would expect to promote
> Python to people who don't currently use it but whom I feel would
> benefit from it".



-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia