On 18 April 2014 16:27, Paul Moore <p.f.mo...@gmail.com> wrote: > On 18 April 2014 20:18, Nick Coghlan <ncogh...@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 | ncogh...@gmail.com | Brisbane, Australia _______________________________________________ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
