Here, a week later, are some of my thoughts from the summit, for the record:
2.8: The issue of a hyptothetical 2.8 never fails to entertain. However, I noticed that there seem to be at least two distinct missions of such a thing. 1. An aid in the conversion from 2.x series to 3.x series. Enabling a bunch of warnings and such by default. Perhaps allowing 3.x syntax in some places without fuss. The problem with this idea is that it is pointless. Why would anyone want to upgrade from 2.7 to 2.8 if all they get is some new warnings for 3.x? If people are willing to make a version upgrade just to get new warnings (i.e. no immediate feature benefit) they might as well go directly to 3.x and be done with it. 2. Feature enhancement to 2.8. Take a robust and popular version of python and add some of the language goodies that have been added to 3.x and that don’t have an inherent 3.x aspect. Yield from. New exception model. Stdlib enhancements such as futures. The argument goes like this: We have a very popular platform out there with lots of momentum. People want incremental enhancements to it. Why not give them what they want? Bread and games and all that? A Rockband cannot stay cooped up in a studio producing experimental concept albums all the time. That is death. Sometimes it needs to go on tour and play old hits for the fans! 3.5 features When asked what should we aim for in 3.5, there were mostly some very minor incremental changes suggested, IIRC. In my opinion, the reason 3.x has not caught on is that there is no real carrot there. There is no new vision, no killer feature. Nothing that a programmer sees and makes him say “Yeah! I want to program my next project using this feature, it will be super!”. In my opinion we should be thinking more boldly. Either for 3.x or for a version 4. We should be taking the language to a new level. Thinking about evolving the language. New paradigms. Look at what C# is doing, with each language revision. Look at Go. I’m no CS but here are some ideas on stuff we could visit: 1. Code blocks as a core language construct. Re-implement context managers as block executors. We shouldn’t let details such as syntax questions distract us. That’s like saying that we can’t eat spaghetti because our Italian is so poor. Proper code blocks would open up new avenues for exploration of expressability and paradigms. 2. Concurrency primitives built into the language. Again, see C# with its “async” keyword (a feature we’ve experimented with in stacklesslib, see e.g. stacklesslib.async in https://bitbucket.org/stackless-dev/stacklesslib ). Look at Go with its channels and more importantly, the select feature. ( see goless, http://goless.readthedocs.org/en/latest/index.html a 2014 sprint project). Don’t get distracted by the GIL. Concurrency is as much about orchestration of operations as it is about parallel execution of code. Let’s learn from the success of stackless, gevent, go, and build on top of it by absorbing tried and tested research from more than 30 years of CS. These are the immediate ideas rolling off the top of my head. Notice how I don’t mention “removing the GIL” here since that is not a “language feature” as such, not something inspiring new thinking and invention. Of course a non-GIL implementation is also desirable, even if it would involve completely rethinking the C API. For a version 4 of python. But I think we thinking beyond that, even. Let’s keep on truckin’! K From: Python-Dev [mailto:python-dev-bounces+kristjan=ccpgames....@python.org] On Behalf Of Guido van Rossum Sent: 10. apríl 2014 01:08 To: Python-Dev Subject: [Python-Dev] Language Summit notes To anyone who took notes at the language summit at PyCon today, even if you took them just for yourself, would you mind posting them here? It would be good to have some kind of (informal!) as soon as possible, before we collectively forget. You won't be held responsible for correctness. )
_______________________________________________ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
