Guido van Rossum: Thoughts about Python Future | Hacker News Reader

Guido van Rossum: Thoughts about Python Future

mail.python.org

182 pointsfogus37 comments

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.)

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

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

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.

Agreed - they seem similar (monocle can even use twisted's reactor). But then I have some personal issues with twisted. IMHO it's simply not well organised. Every time I wrote something, I had to browse through the long list of classes in the API documentation to find what I need (and wonder about how many kinds of reactors are actually needed, and why are they split across so many modules, and ...). The way the docs are written also makes it not very inviting for new users (some pages just seem to say "here, yield does magic").

I chose diesel over twisted many times, simply because of how it's organised, but then again sometimes I had to use twisted, since diesel didn't have some features.

Monocle looks nice to me. If it does the same things twisted offers, I'll choose monocle. Then again, that was a very subjective opinion.

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.

How would PEP 380 improve Monocle style programming?

http://www.python.org/dev/peps/pep-0380/

I don't have enough experience to really understand.

Monocle works by wrapping a single generator and translating each yield-statement into a hand-off to the event loop or reactor and resuming when the value of the deferred becomes known.

Since the code is confined to a single generator, it's not easy to factor-out the steps into subroutines. PEP 380 provides a syntax for having sub-generators which can potentially be used to factor your code into smaller, reusable components.

PEP 380 is about providing better support for nested generators including the scaffolding with try/finally, g.send(), g.next(), g.throw(), and g.close().

In short, PEP 380 lets you nest, and nesting lets you factor your code.

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

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.

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).

Also with a model similar to Github where you fork the repository and submit pull requests, Python developers could cherrypick the best commits from anyone who is interested in contributing.

This probably doesn't scale, but you could certainly do it for just the predetermined contributors.

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.

You should check out Linus' tech talk at Google about Git. Not only is Linus a really good speaker, he explains how a DVCS like git changes the workflow when it comes to managing the 'main' repository.

Spoiler: He has a 'circle of trust'. He pulls and merges commits from people he thinks are really smart and those people in turn pull and merge from people they think are smart.

http://www.youtube.com/watch?v=4XpnKHJAok8

s/commit privileges/push privileges/g

From what I understand, a lot of the uncertainty isn't about committing, per se, but rather about changing the canonical repository.

Speaking of DVCS, Mercurial was chosen at PyCon 2009, although the implementation timeline appears TBD.

http://www.python.org/dev/peps/pep-0374/#decision

http://www.python.org/dev/peps/pep-0385/

http://mail.python.org/pipermail/python-dev/2009-March/08793...

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.

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

(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.

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).

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.

I agree. I think his opening commit bits and assigning a person per PEP is a great idea. That opens the development up and will hopefully maintain a high quality of commits because the SME will be heading up the PEP itself.

Agreed.

I guess being sarcastic isn't a favourable trait on HN.

I like everything he said in the message.

One thing that doesn't work well on the internet is poking fun at a group you belong to yourself. In real life, the rules are different when you include yourself in the joke. On the internet, that's theoretically still the case, but in practice people are a lot slower to realize it, and even if you explicitly state it, they may not believe you.

That's because the Internet is full of trolls and you can't tell the difference between someone poking fun at himself or some idiot who believes what he's saying.

September comes every year :)

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.

That's exactly the sort of problem that the language moratorium is supposed to address: http://www.python.org/dev/peps/pep-3003/

Really? Which niche things have we added?

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.

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.

I actually think it would be bad for GvR to retire. The thing that I feel is python's strength is the fact that we don't see "design by committee" very often.

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

From what I've seen, I concur. In fact, I'd say that the community has actually outgrown GVR's level of knowledge about programming language implementation and design years ago.

IMHO, the benefits of the "benevolent dictator" model are threefold:

    - avoid design by committee, keep things simple & clean
    - clear-cut resolution of group conflicts
    - cohesive and positive developer culture

So long as there is a way to keep or enhance these benefits, Python will do well. It won't be easy!

One of the things I really admire about Python is the willingness not only to add new features, but also to tidy up and remove elements that are redundant or in hindsight were a bad idea.

Doing this, I think, requires strong leadership, it needs someone like GvR who has the respect and political pull to make decisions that aren't going to be popular with everyone . If he's going to step down as "dictator," I hope he chooses a replacement.

Guido has never been that kind of "dictator". Sounds you haven't really been paying attention...

Reply on news.ycombinator.com