5 ms·

Guido van Rossum: Thoughts about Python Future

182 points by fogus 16y ago

jerome_etienne 16y ago
About Commit privileges, using distributed version control system would help reduce the fear of commit.
- JoachimSchipper 16y ago
  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 16y ago
    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).
    - mgrouchy 16y ago
      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.
    - JoachimSchipper 16y ago
      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.
  - tkahn6 16y ago
    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 http://www.youtube.com/watch?v=4XpnKHJAok8
- callahad 16y ago
  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.
- jcsalterego 16y ago
  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-0374/#decision http://www.python.org/dev/peps/pep-0385/ http://www.python.org/dev/peps/pep-0385/ http://mail.python.org/pipermail/python-dev/2009-March/087931.html http://mail.python.org/pipermail/python-dev/2009-March/08793...
agentultra 16y ago
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 16y ago
  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.
  - sigzero 16y ago
    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.
  - agentultra 16y ago
    Agreed. I guess being sarcastic isn't a favourable trait on HN. I like everything he said in the message.
    - dkarl 16y ago
      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.
hugs 16y ago
Here's a link to the monocle project that Guido mentioned: http://github.com/saucelabs/monocle http://github.com/saucelabs/monocle
- j_baker 16y ago
  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.
  - viraptor 16y ago
    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.
  - sah 16y ago
    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.
nailer 16y ago
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 16y ago
  [Still OT] There's a good reason for mailman being monospace: quite a few mailing lists see ASCII diagrams now and then.
  - nailer 16y ago
    (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.
dododo 16y ago
the article mentions a python implementation of CSP which is here http://code.google.com/p/pycsp/ 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 16y ago
  For a good summary of this whole area, see Russ Cox's http://swtch.com/~rsc/thread/ http://swtch.com/~rsc/thread/ page.
deleted 16y ago
[deleted]
- njharman 16y ago
  Read more carefully. They weren't his predictions on hardware architecture. And from my reading he's saying "(hopefully) we don't need no stinking multi-threading cause multiprocessing will be how it's done".
  - bad_user 16y ago
    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.
    - jnoller 16y ago
      We didn't miss an opportunity; no one came up with a patch, or an acceptable fix.

182 points by fogus 16y ago

jerome_etienne 16y ago

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

JoachimSchipper 16y ago
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 16y ago
  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).
  - mgrouchy 16y ago
    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.
  - JoachimSchipper 16y ago
    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.
- tkahn6 16y ago
  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 http://www.youtube.com/watch?v=4XpnKHJAok8
callahad 16y ago
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.
jcsalterego 16y ago
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-0374/#decision http://www.python.org/dev/peps/pep-0385/ http://www.python.org/dev/peps/pep-0385/ http://mail.python.org/pipermail/python-dev/2009-March/087931.html http://mail.python.org/pipermail/python-dev/2009-March/08793...

agentultra 16y ago

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 16y ago
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.
- sigzero 16y ago
  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.
- agentultra 16y ago
  Agreed. I guess being sarcastic isn't a favourable trait on HN. I like everything he said in the message.
  - dkarl 16y ago
    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.

hugs 16y ago

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

j_baker 16y ago
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.
- viraptor 16y ago
  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.
- sah 16y ago
  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.

nailer 16y ago

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 16y ago
[Still OT] There's a good reason for mailman being monospace: quite a few mailing lists see ASCII diagrams now and then.
- nailer 16y ago
  (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.

dododo 16y ago

the article mentions a python implementation of CSP which is here http://code.google.com/p/pycsp/ 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 16y ago
For a good summary of this whole area, see Russ Cox's http://swtch.com/~rsc/thread/ http://swtch.com/~rsc/thread/ page.

deleted 16y ago

[deleted]

njharman 16y ago
Read more carefully. They weren't his predictions on hardware architecture. And from my reading he's saying "(hopefully) we don't need no stinking multi-threading cause multiprocessing will be how it's done".
- bad_user 16y ago
  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.
  - jnoller 16y ago
    We didn't miss an opportunity; no one came up with a patch, or an acceptable fix.