
Guido van Rossum: Thoughts about Python Future - fogus
http://mail.python.org/pipermail/python-dev/2010-July/102306.html
======
dododo
the article mentions a python implementation of CSP which is here

<http://code.google.com/p/pycsp/>

Invented by the same guy that brought us quicksort, CSP is actually a really
nice framework for describing interacting processes. It's used a lot in formal
proofs of correctness of programs, so it's nice to see real-world
implementation with such clear syntax. (Of course, Go uses the same formalism,
as opposed to Actors that are used by Erlang/Scala/etc.)

~~~
ralph
For a good summary of this whole area, see Russ Cox's
<http://swtch.com/~rsc/thread/> page.

------
hugs
Here's a link to the monocle project that Guido mentioned:
<http://github.com/saucelabs/monocle>

~~~
j_baker
On precursory first glance, I don't see anything that isn't done via twisted.
Why would I use this as opposed to twisted's inlineCallbacks?

This isn't a rhetorical question either. I really want to know what the
benefits are.

~~~
sah
Well, monocle is headed in its own direction. We're abstracting the generator-
style concurrency stuff out from the underlying I/O framework, so monocle
works with both Twisted and Tornado, and we're prepared to interoperate with
other frameworks in the future. On top of that base, we're developing a
framework for working in this style; there are some early ideas in
monocle.experimental. We're also building simplified base networking APIs in a
way that only makes sense if you're committed to this style of concurrency.

I think the question is really whether you're more compelled by generator-
style concurrency, or Twisted itself. If you want to work deeply with Twisted,
inlineCallbacks lets you use generator-style where you want, and is maintained
along with Twisted. If you want to use generator-style concurrency to its full
advantage in simplifying complex evented servers, that's where monocle is
going.

------
jerome_etienne
About Commit privileges, using distributed version control system would help
reduce the fear of commit.

~~~
JoachimSchipper
Why? The "main" git repository is as important as the "main" Subversion
repository. git is easier to work with for distributed development, but
whatever is branded Python still shouldn't suck.

~~~
cdavid
With a DVCS, you don't need commit privileges to benefit from all the
advantages of using a VCS in the first place. So even if you keep the exact
same list of comiters, "second-class" contributors can develop things much
more easily.

It also means that you can "screw-up" until you push (and as such can put
things for review, etc... more easily).

~~~
JoachimSchipper
It's a bit more convenient, but svn plus private repositories, or SVK, or git-
svn work equally well.

Again, I'm not saying git isn't more convenient - it is; the point is that
even git-using projects end up with a "main repository" to which only a small
number of people can commit. Increasing the number of people with commit
rights can be useful even when using git.

------
nailer
OT: Reminder to develop a quick JS bookmarket to fix unnecessary monospace
apps like mailman - Readability doesn't work. Assuming an 80 character wide
display was dumb 10 years ago, it's even worse now we have mobile web.

~~~
JoachimSchipper
[Still OT] There's a good reason for mailman being monospace: quite a few
mailing lists see ASCII diagrams now and then.

~~~
nailer
(Looks at downmods) I'm surprised that HN seems to be against any
accessibility technology.

ASCIIs art's useful, but it's not quite so popular as it once was, and doesn't
justify forcing presentation. Reading Guido's post on a phone was completely
painful.

------
agentultra
Guido stepping down from his dictator role? What will the fanboys do?

Sounds like the community is growing up. It's good news for Python developers
(and people who write Python for a living).

~~~
kaens
Guido has been talking about retiring from the dictator role for a bit now.

I think that the language is in a spot where it's got a dedicated enough and
competent enough community to move on from the "GVR as benevolent dictator"
model of development without sacrificing much. The language and its community
is indeed maturing -- in fact, it's one of the most mature communities around
in my experience, at least in the "scripting" language world.

I think the future is pretty bright for Python. It's not a language that is
breaking ridiculous new ground or anything, but it has a nice balance of
readability, power, and a fairly sane standard library, which makes it my (and
many others) go-to language for a lot of tasks.

~~~
njharman
Actually I dread this. Python is already showing signs of design by committee.
Gaining niche new features/constructs/syntax. It use to all fit nicely in my
head. That won't be true in a couple years at current bloat increase rate.

~~~
jnoller
Really? Which niche things have we added?

~~~
njharman
Ternary op, with statement, new string formatting/templeting. A few of the
standard libs are crap and should not have been added.

Not against new stuff ('with' is proly worth it) But the pace of change is too
much and accelerating (or was until moritorium). Instead of taking away more
than one way to do things such as [] as synonym for list(), more than one way
to do things are being added.

3.0 is move in right direction, unfortunately it's a move I have to wait for
major communities(Django) to make before I can.

~~~
jnoller
I disagree that anything you list is a niche feature. As for the standard lib
- I'm interested to hear what you think has been added recently which are
"crap".

Given the amount of debate, discussion, and work that goes into every single
language change we make, I'm rather proud that we've largely avoided making a
complete mess of things.

