[python-advocacy] Obstacles to the adoption of Python

[Rex C. Eastbourne]

Thanks for the great replies, everyone!

Jeff, that was really insightful. Is there a page on the Python wiki
that contains all those things you outlined? I feel it would be useful
if all the things people mentioned were compiled and put into a wiki
page so that newcomers could identify where help is needed most. What
do you guys think?

Rex

On Sat, Mar 22, 2008 at 4:34 AM, Jeff Rush <jeff at taupro.com> wrote:
> Rex Eastbourne wrote:
>  >
>  > I am new to this list. I am a longtime Python user and like it quite a
>  > bit; I am interested in getting involved in advocacy.
>
>  Welcome Rex!
>
>
>
>  > I've been thinking recently about the best way to increase the adoption
>  > rate of Python. I suppose one valuable thing to do would be to do
>  > research on the reasons -- real or imagined -- that people are *not*
>  > adopting it. For instance, I saw the following blog post yesterday:
>  >
>  > http://coffeeghost.net/2008/03/19/your-ignorance-does-not-make-a-programming-language-suck/
>  >
>  > Has anyone done an analysis of the main practical issues holding Python
>  > back?
>
>  Not that I know of, in a rigorous way.  As an advocate of Python, I have in my
>  head one high-level map of its strengths and weaknesses.
>
>
>
>   > Off the top of my head, here are two commonly cited obstacles:
>  >
>  > -Lack of a popular, mature add-on repository (I know there is PyPI, but
>  > it doesn't seem to be as mature as CPAN)
>
>  At PyCon that wrapped up this week, this issue has been elevated and I and
>  others with experience in repositories outside the Python community are just
>  starting to lay the groundwork for major improvements.  I agree that the ease
>  of identifying cool software, of grabbing it, along with the necessary
>  dependencies and installing with minimal hassle is an important factor for
>  language adoption.  If you want to get involved, join the distutils-sig
>  mailing list:
>
>     http://mail.python.org/mailman/listinfo/distutils-sig
>
>
>  > -Documentation (I have no big problem with it, but many people feel the
>  > online Python documentation is not up to par with what other languages
>  > have, like perldoc)
>
>  Documentation could use work in a variety of areas.  We're moving from 2.5
>  LaTeX based docs to 2.6 ReST based docs, with a much nicer website.  Compare:
>
>     http://docs.python.org/
>
>  to the newer:
>
>
>     http://docs.python.org/dev/
>
>  However, there are still modules that are undocumented or underdocumented.
>  There are many pages that need actual examples that people can clip and use.
>
>  You can see here, the raw content,
>
>     http://svn.python.org/view/python/trunk/Doc/
>
>  suitable for grabbing, patching and submitting for review, here:
>
>     http://bugs.python.org
>
>  if you don't have commit privileges directly.
>
>  We need high-level guides to help in choosing the correct module for the job
>  at hand.  Having ten tools that do something slightly different is great for
>  the expert who knows why, but the novices need explanations of how to choose.
>   We need guides on testing methodologies, web and GUI framework selection,
>  monetary currency issues (decimal + locale + Python cookbook), concurrent
>  programming tradeoffs (threads, processes, event-based, GIL discussion),
>  database tradeoffs (RDBMS, ZODB/Durus, pickle/shelf).
>
>  Some aspects of it are at:
>
>      http://www.python.org/about/apps/
>
>  It'd be cool if the docs were is such a form that, when installed onto a local
>  machine, the act of installing packages caused additional chapters to appear
>  in the manuals.  This is an interplay between Python packaging and Python
>  documentation projects.
>
>  There is no agreement in the markup to use within docstrings, although there
>  are several competing styles, with most people not using any, hindering the
>  automatic generation of common docs beyond basic introspection metadata.
>
>
>  > Specifically, it is "logistical" issues like the above that interest me
>  > more than the technical issues (execution speed, language syntax) that
>  > seem to be getting most of the attention. For one, these logistical
>  > issues can be more straightforward to implement.
>
>  More straightforward... ;-) the logistical ones have more politics and are
>  less objective, making it harder to move forward.  But often there is not
>  resistance so much as a lack of volunteer energy and "coming together".
>  Python's popularity means so many of us are very busy.
>
>
>
>  > Does anyone have stuff to add to this list?
>
>  A confusing array of multimedia options, both in the standard library and
>  outside, with varying qualities of cross-platform integration and unclear
>  tradeoffs in realtime performance, flexibility and licensing.
>
>  A need for a well-written guide on how to debug and profile your Python
>  programs - one of the most common requests from newbies on various lists and
>  screencast sites.  Bug of the Week, Find the Ten Bugs in This Program.
>
>  A lack of a security sandbox, similar to Java.  It prevents the use of Python
>  as a first-class scripting language in browsers, makes difficult the use of
>  Crunchy teaching software and drags some on thru-the-web webframeworks.  There
>  is a prototype capability-based solution that is cool, but it needs community
>  involvement.
>
>    http://mail.python.org/pipermail/python-dev/2006-September/068673.html
>
>  No searchable, maintained place, w/reviews, where to buy, in/out print, for
>  someone to locate a book about Python appropriate to their skill level and
>  area of use.  Bonus if it can be sub-queried such that various Python teams
>  like Django and Zope can embed it on their websites and provide bracketed book
>  location service for just their interests.
>
>  No geocoded, searchable registry of Python usergroups, speakers or consultants.
>
>  See anything you'd like to get involved in? ;-)
>
>  -Jeff
>