[Python-ideas] Python 3000 TIOBE -3%

[Mike Meyer]

On Fri, 10 Feb 2012 03:16:00 +0800
Matt Joiner <anacrolix at gmail.com> wrote:

> > If threading is the only acceptable concurrency mechanism, then Python
> > is the wrong language to use. But you're also not building scaleable
> > systems, which is most of where it really matters. If you're willing
> > to consider things other than threading - and you have to if you want
> > to build scaleable systems - then Python makes a good choice.
> Yes but core Python doesn't have any other true concurrency mechanisms
> other than native threading, and they're too heavyweight for this
> purpose alone. On top of this they're useless for Python-only
> parallelism.

Huh? Core python has other concurrency mechanisms other than native
threading. I don't know what your purpose is, but for mine (building
horizontally scaleable systems of various types), they work
fine. They're much easier to design with and maintain than using
threads as well. They also work well in Python-only systems.

If you're using "true" to exclude anything but threading, then you're
just playing word games. The reality is that most problems don't need
threading. The only thing it buys you over the alternatives is easy
shared memory. Very few problems actually require that.

> > Personally, I'd like to see a modern threading model in Python,
> > especially if it's tools can be extended to work with other
> > concurrency mechanisms. But that's a *long* way into the future.
> Too far. It needs to be now. The downward spiral is already beginning.
> Mobile phones are going multicore. My next desktop will probably have
> 8 cores or more. All the heavyweight languages are firing up
> thread/STM standardizations and implementations to make this stuff
> more performant and easier than it already is.

Yes, Python needs something like that. You can't have it without
breaking backwards compatibility. It's not clear you can have it
without serious performance hits in Python's primary use area, which
is single-threaded scripts. Which means it's probably a Python 4K
feature.

There have been a number of discussions on python-ideas about this. I
submitted a proto-pep that covers most of that to python-dev for
further discussion and approval. I'd suggest you chase those things
down.

> > That said, it's perfectly reasonable to suggest changes you think will
> > improve the popularity of the language. But be prepared to show that
> > they're actually good, as opposed to merely possibly popular.
> This doesn't apply to "enabling" features. Features that make it
> possible for popular stuff to happen. Concurrency isn't popular, but
> parallelism is. At least where the GIL is concerned, an good
> alternative concurrency mechanism doesn't exist. (The popular one is
> native threading).

No, the process needs to apply to *all* changes. Even changes to
implementation details - like removing the GIL. If your implementation
that removes the GIL causes a 50% slowdown in single-threaded python
code, it ain't gonna happen.

But until you actually propose a change, it won't matter. Nothing's
going to happen until someone actually does something more than talk
about it.

      <mike
-- 
Mike Meyer <mwm at mired.org>		http://www.mired.org/
Independent Software developer/SCM consultant, email for more information.

O< ascii ribbon campaign - stop html mail - www.asciiribbon.org