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

[Nick Coghlan]

On 16 Apr 2014 21:03, "R. David Murray" <rdmurray at bitdance.com> wrote:
> There is an 'Installing Python on Windows' link further down the google
> results that links to a fairly good page from python-guide.org, whose
> first link lets you download the 2.7.6 msi.  I guess that's the 32
> bit version.  But it then tells you go to python.org to make sure you
> get the latest release, and tells you to click on a link that doesn't
> exist any more (the "windows installer" link).
>
> So, yeah.
>
> Usability.

As part of thrashing out the respective distribution ecosystem roles
of pip and conda (still a work in progress), we're at least converging
on the notion that there are actually now *two* main ways of consuming
Python: as a "software integrator" (the way most of us have
traditionally consumed it, and the way that dominates most project
documentation outside the scientific Python community) and as an "end
user" (the way Linux system administrators have long consumed it, and
the way scientists, financial analysts and folks just learning Python
are likely best off consuming it).

Making these different personas explicit is a process that has barely
begun (this email is mostly based on some conversations I had in
person at PyCon and via email during the sprints), but here's the gist
(based on listing examples):

Software integrators:

* Linux distributions and other operating system vendors
* Sumo redistributions (commercial or otherwise)
* "Python based environments" (PTVS, Enthought Canopy, wakari.io,
Python Anywhere, etc)
* Software-as-a-Service developers
* Device manufacturers
* PC OEMs
* creators of corporate "Standard Operating Environment" definitions
* System integrators (IBM, Boeing et al)
* Application developers (from simple CLI tools to OpenStack)

End users:
* system administrators
* scientists (whether in academia or corporations)
* financial analysts
* engineers
* data miners
* graphic artists
* animation designers
* <<< Folks trying out Python for the first time >>>

For end users, Python is likely consumed as *part of something else*.
For Linux admins, it's a way of scripting the system, for graphic
artists and animators, it's likely embedded as part of a tool like
Blender or Maya, for scientists, financial analysts, engineers and
data miners, it likely makes sense to use it as part of a larger
visualisation environment like IPython Notebook, Python (x, y),
Enthought Canopy, or a hosted system like Wakari or Python Anywhere.

Folks just learning Python are also in the latter list, and we
currently ask them (on the python.org download pages) to jump straight
into the "software integrator" role to get their environment set up,
rather than setting out to impress them by recommending one of the
pre-integrated sumo distributions that offers quick and easy access to
powerful visualisation and data analysis tools. While providing access
to the CPython default interactive prompt in the browser is cool, it's
less impressive as the default experience we provide after someone has
downloaded and installed the interpreter. Instead, we likely want to
*really* impress them by making it easy for them to explore the full
power of things like IPython Notebooks. My own current preferred
approach for that is the fully open source "Anaconda" distribution
from Continuum Analytics, specifically because it *is* fully open
source, and you can "pip install conda" to bootstrap their package
manager in other contexts. And, importantly, because conda
environments can *manage the Python runtime itself*, it is able to
work more consistently across different platforms than the upstream
tools by reliably isolating itself from the system Python on POSIX
platforms. It should even by possible to get conda to manage alternate
Python implementations like Stackless, PyPy, Jython, IronPython, etc
(although I don't believe anyone is using it that way as yet).

However, conda *isn't* optimised for the software integrator use case
- the additional work it does to improve cross platform consistency
actually *gets in the way*, when you're trying to integrate Python
closely with a larger system (like a Linux distribution), and "a large
set of automatically provided libraries" isn't actually a feature in
that context. While conda does offer some options (like miniconda) to
make that kind of integration task easier, I strongly believe that
realm is better handled by consuming CPython and the standard library,
along with pip and related tools, directly, and accepting the
additional platform specific details that come along with that.

Making this "software integrator" and "end user" split deliberately
and consciously, and pushing the former toward consuming things in a
more DIY fashion, and the latter towards a pre-assembled sumo
distribution should help greatly in allowing us to better balance the
starkly different needs of the two groups, and provide an extremely
high quality "out of the box" experience for new users, while still
allowing software integrators to dive in and customise things to suit
their own needs.

>From a Python 2->3 migration perspective, blessing at least one sumo
distribution also provides a way to make it easy to gain ready access
to backports from the Python 3 standard library (for example, Anaconda
currently includes at least the backports.ssl_match_hostname module).

Regards,
Nick.