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

Paul Moore p.f.moore at gmail.com
Fri Apr 18 23:19:24 CEST 2014


On 18 April 2014 21:59, Nick Coghlan <ncoghlan at gmail.com> wrote:
> 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.

For Windows users at least, I disagree. I have directed a lot of
people to the python.org Windows installers, and they have got up and
running without any issues (ignoring website usability "find the right
download" questions). Most of the time, they need nothing more than
the interpreter and the stdlib to become productive.

The downside to directing them at (say) conda is that 99.99% of the
documentation on the internet is not directed at conda users. Most of
the time, that's fine, because it's all generic stuff, but it's a trap
waiting to happen. I can't tell people to use conda myself as I'm not
a conda user, so I can't help them if they hit problems.

> 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.

Core python, plus a standalone copy of virtualenv (and on 3.4+ I don't
even need that). Everything else is installed from PyPI as needed.
Agreed that starting from a Google search won't get that at the
moment, but that's what the packaging initiatives are trying to solve
- get the infrastructure there so that more and more people say the
same things, and so google searches become more accurate.

My vision of the ideal is:

1. Install Python from python.org
2. py -m venv foo
3. foo\Scripts\activate
4. pip install <anything>

(Note that item 4 relies on pervasive availability of wheels for
packages like numpy, scipy, lxml, pywin32, etc)

Oh, and everyone needs to switch to Windows so this works :-)

More seriously, I genuinely think that this is the ideal solution for
*all* Windows users who don't have the sort of specialised needs that
mean a curated stack is right for them, and they know about it from
word of mouth via colleagues in the same situation.

I have no idea, and no opinion, on how practical it is to achieve this
level of simplicity on Unix or OSX. But I do think it's the right goal
to aim for for any cases where using "the system Python" is the wrong
answer.

>> 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.

OK. In which case that category is far broader than I anticipated, and
includes people who cannot even write a Windows batch file or use a
command line without instruction (I can name names!!! ;-)) If that's
your view, though, then all I can say is that I have no experience of
anyone who isn't in the "software integrator" category, so I'll take
your word that there is only one other category :-)

Paul


More information about the Python-Dev mailing list