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

[Daniel Holth]

On Fri, Apr 18, 2014 at 12:55 PM, Paul Moore <p.f.moore at gmail.com> wrote:
> On 18 April 2014 16:58, Nick Coghlan <ncoghlan at gmail.com> wrote:
>> 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):
>
> Interesting perspective. However, I'm not convinced it's complete.
> Specifically, there's one group of people who I encounter relatively
> often, who don't seem to me to fit well into either category you're
> proposing. That is, (Windows in my experience, but maybe Linux as
> well) users who want to write "simple scripts" and for whom batch
> files or similar are not sufficient. Such people typically don't have
> the sort of "single application area" focus that your "end user"
> category seems to imply, but on the other hand they don't really fit
> the "software integrators" role in the sense of necessarily being
> comfortable setting up their own development environment.
>
> I worry that your classification risks ignoring that group (maybe
> because Unix users are well served with other alternatives than Python
> for this type of task, or because on Unix "use the system Python" is
> the right answer).
>
> Your list of "end user" targeted distributions seem to be limited to:
>
>   - Linux distribution vendors
>   - Vendors focused on the essentially scientific community (in the
> broadest sense)
>   - Embedded Python
>
> That's very far from being complete coverage of all the people *I'd*
> like to be able to recommend Python to. Specifically, unless we're not
> interested in "generic" Windows users, I think we need to offer *some*
> form of equivalent of the OS-packaged Python on Linux for Windows
> users. That's what the python.org builds, plus pip, wheels and PyPI,
> give for Windows users now. Hmm, if we assume that supporting that
> remains a priority, is what you're really saying that we *don't* try
> to extend that to work for Linux/OSX, as doing so competes with the OS
> vendors - but rather we see python.org binaries and binary
> infrastructure like wheels as being focused on the Windows user
> experience?
>
> (I wish I'd been at PyCon, this would have been a very interesting
> discussion to have face to face. Email isn't ideal for this...)

One more group that I find interesting is application users. These
people should not need to notice that Python is in use at all, in
contrast to the "build a virtualenv / install / pass through fire and
death / use" workflow that is sometimes promoted. They are well served
by good tools that make single-file zip distributions or py2exe etc.
from a collection of wheels or sdists. Application users are using
Python because a best-in-class program is written in Python and not
because a Python program integrates better with other Python
libraries.


Conda is interesting because it is a system package manager, except it
installs everything into what they sometimes describe as "C-level
virtualenvs" rather than /. They've come up with a design that works
well with Python programs but isn't particularly Python-specific at
all.