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.)
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.
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.
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.
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).
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.
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.
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.
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.
(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.
I still believe multi-threading has its value, and I don't think it's wise dismissing it.
The main problem scripting languages like Python have is that their standard libraries are written in C ... this is a technical debt and always the main culprit for the slow evolution of their VMs. As far as Python is concerned, many people aren't using Jython/IronPython/PyPy because NumPy won't run on those.
I believe the future lies in projects like Rubinius / PyPy ... but it will be an uphill struggle ... it's easier to get rid of scabies than to get rid of that GIL. And they've missed that opportunity with Python 3.
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.
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.
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 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!
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.
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.
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.
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.
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.)