Re: [Python-ideas] Python 3000 TIOBE -3% (Massimo Di Pierro)
I completely agree with Massimo again. :-)
I think it is odd to encourage users to go to use open source distros, but if they have installation problems (which is really common - Massimo/Titus/Audrey/Zed/etc seem to back me up here) to recommend 'somewhere' to go to commercial-but-free distros. If we should be pointing new users to ActiveState or Enthought, maybe we should just change the python.org default installers to what they provide. Tell you what, I'll take this matter off-list and bring it up with Jesse Noller and the rest of the board working on the python.org RFP. -- 'Knowledge is Power' Daniel Greenfeld http://pydanny.blogspot.com
On Thu, Feb 9, 2012 at 2:50 PM, Daniel Greenfeld <pydanny@gmail.com> wrote:
Why is that odd? Those distros are an integral part of the ecosystem that is enabled by open source. I see no philosophical problems (unless you are of the GNU religion of course -- but then you should have said FOSS instead of open source :-).
Again, why? The commercial distributors often lag way behind what python.orgoffers -- and for very good reasons.
Tell you what, I'll take this matter off-list and bring it up with Jesse Noller and the rest of the board working on the python.org RFP.
-- --Guido van Rossum (python.org/~guido)
On Thu, Feb 9, 2012 at 2:59 PM, Guido van Rossum <guido@python.org> wrote:
I may have not said this as well as I thought. :P I don't follow the GNU religion but I do make Python a very good friend. :-) I think it's wonderful that ActiveState and Enthought are providing distributions for free. I got kickstarted on ActiveState back in 2005. However, for people coming into the language, they should be able to expect an easy installation from the core site regardless of their operating system. I'm wondering that rather than pointing all the new Windows users at ActiveState/Enthought sites, if their distros are easier to install, maybe the links should be to those distros. There are probably all sorts of really good reasons why this is not possible, but if you ever have to see 10 instructors at once waste a couple hours of installation on 75 students you won't care about those reasons anymore.
Just trying to find an easier path for instructors get students kickstarted in our favorite programming language. -- 'Knowledge is Power' Daniel Greenfeld http://pydanny.blogspot.com
Sadly, it's quite frequent that works really well in an educational setting shouldn't be recommended in a professional programming environment, and vice versa. I'm not sure how to answer this except by creating, maintaining and promoting some wiki pages aimed specifically at instructors. On Thu, Feb 9, 2012 at 3:09 PM, Daniel Greenfeld <pydanny@gmail.com> wrote:
-- --Guido van Rossum (python.org/~guido)
On Thu, Feb 09, 2012 at 04:02:34PM -0800, Guido van Rossum wrote:
Perhaps I am brainfried ATM, but I cannot imagine what you are talking about here. Do you have any examples you can share that illustrate what you mean? thanks much, --titus
On Thu, Feb 9, 2012 at 9:00 PM, C. Titus Brown <ctb@msu.edu> wrote:
Simplest example: many educators seem delighted with Python 3 because it solves a bunch of beginner's pitfalls, and their students learn in a greenfield situation. (Though this is not the case for Massimo.) Professionals OTOH don't seem to like Python 3 because it means they have to change a pile of software that took them a decade (and an army of programmers) to create. Educators also often give their students a simple library of convenience functions and tell them to put the magic line "from blah import *" at the top of their module (or session). Again something that most professionals loathe, but it works well for the first steps in programming -- certainly better than the Java approach "copy these ten lines of gobbledygook [the minimal "hello world" in Java] into your file, don't ask what they mean, and above all be careful not to accidentally edit any of them". OTOH when educators want their students to install some 3rd party package it is often something hideously complex like pygame, rather than something simple and elegant like WebOb or flask. -- --Guido van Rossum (python.org/~guido)
On Fri, Feb 10, 2012 at 8:50 AM, Daniel Greenfeld <pydanny@gmail.com> wrote:
The reason I encourage budding developers to switch to an open source base as soon as they can is because it comes with an entire open source ecosystem around it. With open source code that needs to interact with OS level APIs, the development flow is often Linux first (it's completely open source, POSIX compatible and very popular), then OpenSolaris and the *BSD variants (also open source, POSIX compatible, but significantly less popular) then Mac OS X (at least it offers a decent POSIX layer), then Windows (from my perspective, the win32 API and NTFS stand tall as a couple of the worst cases of NIH syndrome in the history of computing). In other words, it's almost the exact reverse of the situation in the proprietary desktop software world (which usually goes Windows->Mac OS X->Linux based on desktop market share). With POSIX compatible code covering pretty much every platform other than Windows, and with win32 API programming being such an alien (and verbose) experience to anyone used to the file descriptor based POSIX world, volunteers that are willing to develop and maintain such code on their own time are pretty thin on the ground. As aresult, it's frequently necessary to turn to proprietary vendors to get a smooth, Windows-appropriate user experience. Given that Windows itself is a proprietary OS, suggesting that people use a free-as-in-beer-but-not-as-in-speech package that lets them skip the boring bits and get straight to coding sounds quite reasonable to me. Sure it's not perfect, but unless you can wave your hand and create a larger pool of volunteer developers that decide to stick with Windows for their hobbyist development instead of embracing a completely open platform like Linux or a POSIX-compatible open core one like Mac OS X, Windows support is always going to lag (including in the installation-and-deployment space). My experience on Linux is that most things, up to and including pip installation of C extension modules, *just works* (the exception being that some C extensions have broken build processes and require a bit of cajoling - it would be nice if someone actually sat down and wrote a bdist_simple PEP instead of just talking about it on this list). Automating the setup of these platforms is fairly straightforward because they come with tools like Python and wget preinstalled, so you can just use them without needing to worry about giving the user instructions on obtaining them. In contrast, on Windows, you have to do a lot of work up front to be able to compile C extensions at all, and installing pip is a far cry from being able to just do "yum install python-pip". You don't even have access to "wget" to fetch a script that handles the setup for you. Getting set up to do software development on Windows is hard because Windows is built on the assumption that the world can be cleanly divided into "Developers" that build their own copies of software from source code (basically, people that are willing to pay for a copy of Visual Studio, or at least download and install one of the Express editions) and "Users" that only run software that someone else built (everyone else). The Linux distros (and other open source platforms), on the other hand, make the tools to *build* the software just as readily available as the software itself (although, these days, they also do their best to make sure you don't *need* to build stuff from source). Cross platform tools like Python can make an attempt to paper over those fundamental philosophical differences between the platforms, but really, there's only so much any given third party can do about it (and, for most people, trying to do so doesn't qualify as a fun hobby). Suppose Python core gets our packaging story on Windows fixed. What then? Well, NumPy still runs into problems due to BLAS. What's installing Postgres, MySQL or MongoDB on Windows like? (I genuinely don't know, I've never tried). Are there Windows installers for PyPy? These kinds of road blocks are endemic in Windows open source development, and they'll likely stay that way unless MS release a native Windows POSIX compatibility layer that isn't horrible (I personally expect that to happen somewhere around the time the Earth gets swallowed by the Sun).
No, because the python.org installers are what the redistributor's use to create their own sumo packages. It may be reasonable for us to point new users that aren't already experienced Windows software developers directly to the sumo distributions, though. For example, as far I know, Python(X, Y) does a nice job of dumping a comprehensive Python environment on a Windows system without relying on a proprietary vendor. Cheers, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia
On Thu, Feb 9, 2012 at 2:50 PM, Daniel Greenfeld <pydanny@gmail.com> wrote:
Why is that odd? Those distros are an integral part of the ecosystem that is enabled by open source. I see no philosophical problems (unless you are of the GNU religion of course -- but then you should have said FOSS instead of open source :-).
Again, why? The commercial distributors often lag way behind what python.orgoffers -- and for very good reasons.
Tell you what, I'll take this matter off-list and bring it up with Jesse Noller and the rest of the board working on the python.org RFP.
-- --Guido van Rossum (python.org/~guido)
On Thu, Feb 9, 2012 at 2:59 PM, Guido van Rossum <guido@python.org> wrote:
I may have not said this as well as I thought. :P I don't follow the GNU religion but I do make Python a very good friend. :-) I think it's wonderful that ActiveState and Enthought are providing distributions for free. I got kickstarted on ActiveState back in 2005. However, for people coming into the language, they should be able to expect an easy installation from the core site regardless of their operating system. I'm wondering that rather than pointing all the new Windows users at ActiveState/Enthought sites, if their distros are easier to install, maybe the links should be to those distros. There are probably all sorts of really good reasons why this is not possible, but if you ever have to see 10 instructors at once waste a couple hours of installation on 75 students you won't care about those reasons anymore.
Just trying to find an easier path for instructors get students kickstarted in our favorite programming language. -- 'Knowledge is Power' Daniel Greenfeld http://pydanny.blogspot.com
Sadly, it's quite frequent that works really well in an educational setting shouldn't be recommended in a professional programming environment, and vice versa. I'm not sure how to answer this except by creating, maintaining and promoting some wiki pages aimed specifically at instructors. On Thu, Feb 9, 2012 at 3:09 PM, Daniel Greenfeld <pydanny@gmail.com> wrote:
-- --Guido van Rossum (python.org/~guido)
On Thu, Feb 09, 2012 at 04:02:34PM -0800, Guido van Rossum wrote:
Perhaps I am brainfried ATM, but I cannot imagine what you are talking about here. Do you have any examples you can share that illustrate what you mean? thanks much, --titus
On Thu, Feb 9, 2012 at 9:00 PM, C. Titus Brown <ctb@msu.edu> wrote:
Simplest example: many educators seem delighted with Python 3 because it solves a bunch of beginner's pitfalls, and their students learn in a greenfield situation. (Though this is not the case for Massimo.) Professionals OTOH don't seem to like Python 3 because it means they have to change a pile of software that took them a decade (and an army of programmers) to create. Educators also often give their students a simple library of convenience functions and tell them to put the magic line "from blah import *" at the top of their module (or session). Again something that most professionals loathe, but it works well for the first steps in programming -- certainly better than the Java approach "copy these ten lines of gobbledygook [the minimal "hello world" in Java] into your file, don't ask what they mean, and above all be careful not to accidentally edit any of them". OTOH when educators want their students to install some 3rd party package it is often something hideously complex like pygame, rather than something simple and elegant like WebOb or flask. -- --Guido van Rossum (python.org/~guido)
On Fri, Feb 10, 2012 at 8:50 AM, Daniel Greenfeld <pydanny@gmail.com> wrote:
The reason I encourage budding developers to switch to an open source base as soon as they can is because it comes with an entire open source ecosystem around it. With open source code that needs to interact with OS level APIs, the development flow is often Linux first (it's completely open source, POSIX compatible and very popular), then OpenSolaris and the *BSD variants (also open source, POSIX compatible, but significantly less popular) then Mac OS X (at least it offers a decent POSIX layer), then Windows (from my perspective, the win32 API and NTFS stand tall as a couple of the worst cases of NIH syndrome in the history of computing). In other words, it's almost the exact reverse of the situation in the proprietary desktop software world (which usually goes Windows->Mac OS X->Linux based on desktop market share). With POSIX compatible code covering pretty much every platform other than Windows, and with win32 API programming being such an alien (and verbose) experience to anyone used to the file descriptor based POSIX world, volunteers that are willing to develop and maintain such code on their own time are pretty thin on the ground. As aresult, it's frequently necessary to turn to proprietary vendors to get a smooth, Windows-appropriate user experience. Given that Windows itself is a proprietary OS, suggesting that people use a free-as-in-beer-but-not-as-in-speech package that lets them skip the boring bits and get straight to coding sounds quite reasonable to me. Sure it's not perfect, but unless you can wave your hand and create a larger pool of volunteer developers that decide to stick with Windows for their hobbyist development instead of embracing a completely open platform like Linux or a POSIX-compatible open core one like Mac OS X, Windows support is always going to lag (including in the installation-and-deployment space). My experience on Linux is that most things, up to and including pip installation of C extension modules, *just works* (the exception being that some C extensions have broken build processes and require a bit of cajoling - it would be nice if someone actually sat down and wrote a bdist_simple PEP instead of just talking about it on this list). Automating the setup of these platforms is fairly straightforward because they come with tools like Python and wget preinstalled, so you can just use them without needing to worry about giving the user instructions on obtaining them. In contrast, on Windows, you have to do a lot of work up front to be able to compile C extensions at all, and installing pip is a far cry from being able to just do "yum install python-pip". You don't even have access to "wget" to fetch a script that handles the setup for you. Getting set up to do software development on Windows is hard because Windows is built on the assumption that the world can be cleanly divided into "Developers" that build their own copies of software from source code (basically, people that are willing to pay for a copy of Visual Studio, or at least download and install one of the Express editions) and "Users" that only run software that someone else built (everyone else). The Linux distros (and other open source platforms), on the other hand, make the tools to *build* the software just as readily available as the software itself (although, these days, they also do their best to make sure you don't *need* to build stuff from source). Cross platform tools like Python can make an attempt to paper over those fundamental philosophical differences between the platforms, but really, there's only so much any given third party can do about it (and, for most people, trying to do so doesn't qualify as a fun hobby). Suppose Python core gets our packaging story on Windows fixed. What then? Well, NumPy still runs into problems due to BLAS. What's installing Postgres, MySQL or MongoDB on Windows like? (I genuinely don't know, I've never tried). Are there Windows installers for PyPy? These kinds of road blocks are endemic in Windows open source development, and they'll likely stay that way unless MS release a native Windows POSIX compatibility layer that isn't horrible (I personally expect that to happen somewhere around the time the Earth gets swallowed by the Sun).
No, because the python.org installers are what the redistributor's use to create their own sumo packages. It may be reasonable for us to point new users that aren't already experienced Windows software developers directly to the sumo distributions, though. For example, as far I know, Python(X, Y) does a nice job of dumping a comprehensive Python environment on a Windows system without relying on a proprietary vendor. Cheers, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia
participants (4)
-
C. Titus Brown -
Daniel Greenfeld -
Guido van Rossum -
Nick Coghlan