The next 20 years of Python
The EuroPython 2013 conference in Florence, Italy opened with a keynote by Van Lindberg about the next twenty years of Python. Lindberg, a lawyer with an engineering background, is the chairman of the Python Software Foundation (PSF) and the author of the book Intellectual Property and Open Source (reviewed by LWN in 2008). His keynote looked at the challenges facing the Python community and the work underway to ensure that Python will remain an attractive programming language and have a healthy community for the next twenty years (and beyond).
The design philosophy of Python
Lindberg began his keynote with a retrospective of the last twenty years of Python. He described the origins of Python as a skunkworks project, which led Guido van Rossum, the creator of Python, to a number of interesting design choices. One is that Van Rossum borrowed ideas from elsewhere, such as ALGOL 68 and C. Another design approach was to make things as simple as possible. This involved taking the same concepts and reusing them over and over again. Python also follows the Unix philosophy of doing one thing well, he said. Finally, perfection is the enemy of the good, as "good enough" is often just that. Cutting corners is allowed, as you can always go back and improve it later. Lindberg summarized that Van Rossum "got a lot right in the early days".
Lindberg noted that Van Rossum also succeeded in creating a community around Python. Lindberg identified four factors that were crucial for the success of Python. First, Python was an excellent language. This was a necessary basis because "otherwise there's nothing to gather and rally around". Second, Van Rossum chose an open source license even before the term "open source" was invented. Third, Van Rossum encouraged a sense of humor, naming the language after the Monty Python crew. Finally, Python had a sense of values.
The values behind Python, in particular, are what differentiates Python from
many other programming languages. Lindberg asked the audience whether they
knew about
"import this
". This is an Easter egg in
Python
which displays the Zen of
Python, the guiding principles
behind Python. Unlike Perl, which proudly proclaims that there's more
than one way to do
it,
Python encourages a certain programming style. This is reflected in the
Zen of Python, which says that there should be one — and preferably
only one — obvious way to do it.
Challenges for the Python community
Lindberg emphasized that Python is a remarkable story of success. There are hundreds of thousands, maybe even millions, of people using Python as part of their jobs. Python is widely deployed — it has become the de facto standard in the movie and animation industry, is overtaking Perl in bioinformatics, and is the implementation language of two of the leading cloud platforms. Python is also a significant player in education, "finally replacing Java as the primary teaching language for a lot of universities", he said.
Despite the success, Python is facing what Lindberg described as "market share challenges". JavaScript, which used to be stricken by buggy, browser-only, and inconsistent implementations, has become a fairly big competitor in the desktop and server spaces, and particularly in mobile. Lua is increasingly used as an embeddable extension language. Lindberg sees Go as another contender. What makes Go attractive is its concurrency and ability to create easily deployable binaries that you can just drop on a system and run. "Frankly, deployment is a challenge for us", admitted Lindberg, as are mobile and other areas with highly constrained space requirements. Lindberg also mentioned the statistical and graphic abilities of R as a potential competitor.
Asking "why do I care?", he explained that it's important to keep growing — otherwise Python will end up where Smalltalk and Tcl are today. He rhetorically asked the audience when the last time was that anyone did anything interesting in Tcl. Noting that these are fantastic languages, Lindberg argued that "they have died because they have not grown". It's not just the language, but also the community around it, that can die. He observed that in addition to technical challenges facing Python, there are also challenges with scaling the Python community that need to be addressed. Lindberg believes that ten or twenty years ago it was enough to focus on the programmer, whereas these days you have to form a culture around programming.
There is something special about the Python community, according to
Lindberg. He quoted the mission of the Python Software
Foundation, which is to "promote,
protect, and advance the Python programming language, and to support and
facilitate the growth of a diverse and international community of Python
programmers
", observing that "these are important words". Lindberg
argued that the current community is getting older and that actions have to
be taken that will create the Python community twenty years from now: "if
we don't build and grow the community, it will go away".
Big changes coming
Lindberg emphasized three areas that the Python Software Foundation is focusing on to grow the Python community, now and in the future. One is the Code of Conduct the PSF adopted in April. The Zen of Python has been important in defining Python, but its focus is on code. The Code of Conduct, on the other hand, captures what the community itself should be like — it should consist of members from all around the world with a diverse set of skills. He said that a member of the Python community is open, considerate, and respectful: members are open to collaboration, to constructive criticism, and to fostering an environment in which everyone can participate; they are considerate of their peers; and they are respectful of others, their skills, and their efforts. The Code of Conduct condenses what is great about the Python community. "It's about being the best people that we can be and being the best community that we can be", Lindberg said. Alluding to Python's reputation as the language with batteries included, he summarized that "Python is the language with community included".
The second focus for PSF is education. As we're all getting older, we have to think about where the next generation is coming from, Lindberg said. He told the story of Sam Berger, an eleven year old school boy from South Africa, who attended PyCon and participated in professional level tutorials and classes. This is an illustration of where the next generation of Python leaders is coming from. In order to encourage that next generation, the PSF is supporting initiatives to promote young coders, such as making a curriculum to teach kids Python available online. Lindberg is also very supportive of the Raspberry Pi. He reminisced about the 80s when computers booted into BASIC. The default way to interact with the computer was through programming. If you wanted to do something else, you had to make an explicit decision. This led to an entire generation that understood that computers are tools — tools that won't break if you play around with them.
Finally, the PSF itself is adapting to better serve the needs of the Python community. It is working on a new web site (a preview of which can be found at preview.python.org). The design goal of the new site is to make it easy for the community to get involved. It is also putting a lot of thought into representing the community, and there will be efforts to address various needs, such as learning Python or teaching Python. Lindberg also lamented that the PSF is not broad and inclusive enough. Membership in the PSF currently requires a nomination from an existing member, but Lindberg believes that every member of the Python community should be a member of the PSF. In April, the PSF voted to completely redo its membership program and to open up membership to anyone. Answering a question from the audience, Lindberg clarified that basic membership will be available to anyone who signs up. Further rights, such as voting privileges, will be given to those members who have demonstrated a commitment to the Python community, such as by contributing code, documentation, or test cases — or by organizing events.
Lindberg closed by saying that the PSF is "changing to be your home". It is fundamentally saying that "we need each of you" and that "this is all about you". This is the most significant change the Python community has seen since the formation of the PSF, according to Lindberg, and it's about building the next twenty years of Python.
Index entries for this article | |
---|---|
GuestArticles | Michlmayr, Martin |
Conference | EuroPython/2013 |
Posted Jul 11, 2013 6:39 UTC (Thu)
by vedantk (guest, #88435)
[Link] (6 responses)
Some of the aspects of Python that I've grown to love the most were introduced later on during its lifetime. Take the collections module for example (2.4), or the nifty "yield from" statement (3.3).
My impression is that the language is ambitious and improving. It should fare well during the foreseeable future.
Posted Jul 11, 2013 9:43 UTC (Thu)
by renox (guest, #23785)
[Link] (5 responses)
Improving yes, but very slowly so I'm not that sure:
That said, it is very,very hard for new languages to gather momentum so this should ensure that Python is used for a long time, but there's a difference between being very used but dying like Cobol/Perl(not a troll: that's *my* opinion YMMV) and being very used and growing..
Posted Jul 11, 2013 12:15 UTC (Thu)
by smitty_one_each (subscriber, #28989)
[Link] (3 responses)
I'm curious how your comment differs from functionality available via
Posted Jul 11, 2013 12:26 UTC (Thu)
by mpr22 (subscriber, #60784)
[Link] (2 responses)
Posted Jul 11, 2013 14:09 UTC (Thu)
by juliank (guest, #45896)
[Link] (1 responses)
def f(x: int, y: int, z: int) -> int:
Combined with a decorator or a meta-class, you can use this for run-time type checking as well. But it's still only at run-time, and not static, at compile-time.
Posted Jul 22, 2013 6:28 UTC (Mon)
by smurf (subscriber, #17840)
[Link]
However, once you do have those annotations, running an analyzer over the bytecode which verifies a large subset of them shouldn't be *that* hard to write.
Posted Jul 17, 2013 5:37 UTC (Wed)
by Cato (guest, #7643)
[Link]
Python is also gaining a lot of use in scientific computing where the ability to rapidly explore solutions is a big win and there are various compilers and JITs (Numba, Cython, PyPy). You can even run Python on CUDA based GPUs if your problem fits.
There is still the issue of migrating all major libraries to Python 3, but there's now a lot more experience and tooling for this.
Links:
- Disqus: world's largest Django app at 400m users - http://ontwik.com/python/pycon-2011-disqus-serving-400-mi...
Posted Jul 11, 2013 8:12 UTC (Thu)
by thedevil (guest, #32913)
[Link] (6 responses)
Posted Jul 11, 2013 10:19 UTC (Thu)
by sorpigal (guest, #36106)
[Link] (2 responses)
Actual growth isn't required, just a perception of "coolness" that continues to attract new blood.
Posted Jul 11, 2013 13:54 UTC (Thu)
by anselm (subscriber, #2796)
[Link] (1 responses)
Corollary: A language doesn't actually need to be good as long as it is hyped enough.
Posted Jul 11, 2013 14:46 UTC (Thu)
by renox (guest, #23785)
[Link]
Posted Jul 11, 2013 12:18 UTC (Thu)
by smitty_one_each (subscriber, #28989)
[Link]
Posted Jul 11, 2013 13:25 UTC (Thu)
by kotnik (subscriber, #57300)
[Link]
Posted Jul 11, 2013 23:06 UTC (Thu)
by robert_s (subscriber, #42402)
[Link]
And no, I'm not just making this point to be a pedant.
Posted Jul 11, 2013 14:51 UTC (Thu)
by dskoll (subscriber, #1630)
[Link] (6 responses)
I continue to do interesting things in Tcl to this day. For quick desktop GUI apps, Tck/Tk is unparalleled. Anyone using git probably uses Tcl/Tk in the form of gitk and git gui
Tcl is also very widely used in the Electronic Design Automation field. It has become a niche language, but it's not dead by any means.
Posted Jul 11, 2013 20:49 UTC (Thu)
by anselm (subscriber, #2796)
[Link] (3 responses)
By no means dead, but no longer politically correct. The hip kids these days
use unspeakable monstrosities like Ruby or Lua, and even like it.
Posted Jul 12, 2013 19:00 UTC (Fri)
by jonabbey (guest, #2736)
[Link] (1 responses)
Posted Jul 12, 2013 19:09 UTC (Fri)
by justincormack (subscriber, #70439)
[Link]
Posted Jul 13, 2013 1:27 UTC (Sat)
by salimma (subscriber, #34460)
[Link]
Posted Jul 14, 2013 15:14 UTC (Sun)
by man_ls (guest, #15091)
[Link]
Most people using git are probably using github web or github for Mac. I cannot talk about everyone else, but since Debian installs gitk and git-gui separately,
this graph may give you some data. Apparently gitk is installed on less than 20% of git machines, and git-gui even less.
Posted Jul 14, 2013 22:03 UTC (Sun)
by juliank (guest, #45896)
[Link]
I don't use gitk or git gui. I use git on the command line 99% of my time, and once or twice in a month use gitg to visualise the history.
Posted Jul 11, 2013 14:52 UTC (Thu)
by Wummel (guest, #7591)
[Link] (1 responses)
Posted Jul 13, 2013 0:48 UTC (Sat)
by garrison (subscriber, #39220)
[Link]
Posted Jul 12, 2013 8:02 UTC (Fri)
by b7j0c (guest, #27559)
[Link] (23 responses)
that said, i think the glory days of the 90s scripting language are over. support for types, and more importantly, type inference, means newer tools can provide more safety and performance. since they tend to rely heavily on native shared objects for library support, the 90s scripting languages will always manifest painful dependencies which make deployment a hassle and make concurrency hard.
compare python to go. with go, i get types, type inference, concurrency, and i deploy with scp to any target with the same architecture.
Posted Jul 12, 2013 10:34 UTC (Fri)
by Cato (guest, #7643)
[Link] (6 responses)
This means that many people can't really use it for long-running 32-bit desktop or server apps, including on smaller VPSs that may be 32-bit since they only need 1 or 2 GB RAM.
Posted Jul 13, 2013 6:01 UTC (Sat)
by b7j0c (guest, #27559)
[Link] (2 responses)
Posted Jul 13, 2013 9:12 UTC (Sat)
by Cato (guest, #7643)
[Link]
Posted Jul 14, 2013 8:02 UTC (Sun)
by dlang (guest, #313)
[Link]
ohh, I guess you haven't heard that there are more 8 bit processors being built and sold today than ever before, far more 8 bit processors are sold than 32 bit processors.
Now, it's true you don't see general purpose computers being sold with 8 bit processors any longer, but that's not the same as "only found in museums"
Posted Jul 13, 2013 8:57 UTC (Sat)
by lab (guest, #51153)
[Link] (2 responses)
"For a problem of this generality, "fixed" is a difficult word. The core problem is that the garbage collector is not fully precise. This can cause a value that does not contain a pointer to appear to be a pointer, which prevents the garbage collector from collecting the memory block to which the non-pointer appears to point. In practice this happens most often with floating point values; integers rarely appear to be pointers, but floating point value sometimes do.
So much for the background. In Go 1.1 the GC is far more precise than the GC in Go 1.0. That means that these sorts of problems are vastly less likely to occur when using Go 1.1 than they are with Go 1.0. In particular in Go 1.1 the heap is almost entirely precisely typed, and floating point values in the heap will never be mistaken for pointers.
However, the problem is not entirely fixed because even in Go 1.1 the GC is not entirely precise. In particular in Go 1.1 stack frames are not precisely typed. So if, for example, you have a bunch of floating point local variables, those variables can appear to be pointers while the function is live and cause the GC to fail to collect various memory blocks. This is not likely to be a problem for most programs, but it is certainly possible.
In Go 1.2 the GC will be even more precise than it is in Go 1.1. On tip the GC is already precise for function arguments and results. Go 1.2 may be precise for local variables on the stack. It may even be fully precise. But it's too early to tell whether this work, which is ongoing, will be complete for Go 1.2.
So the current status is that most programs that did not work with Go 1.0 should now work fine with Go 1.1. However, it is possible to construct test cases that will not work well with Go 1.1. And there is a very small chance that your real program will accidentally happen to be one of those test cases. But it's a very small chance. Also, if you are so unfortunate as to encounter that chance, you do have options in Go 1.1 that you did not have in Go 1.0: you can force your non-pointers that appear to be pointers off the stack into the heap. That will give you a bit more heap allocation, but in return the GC will collect more data."
Posted Jul 13, 2013 9:15 UTC (Sat)
by Cato (guest, #7643)
[Link] (1 responses)
In the short term, it may be enough for server apps on 32-bit to just restart after a number of transactions, or a period of time.
It's a bit harder to do such restarts on desktops when user is using the app - however, desktop app restarts are not so uncommon due to software updates, so perhaps a minor update could be pushed forcing an app restart.
Posted Jul 13, 2013 9:28 UTC (Sat)
by lab (guest, #51153)
[Link]
Posted Jul 12, 2013 18:32 UTC (Fri)
by MKesper (subscriber, #38539)
[Link] (2 responses)
Posted Jul 12, 2013 19:14 UTC (Fri)
by mathstuf (subscriber, #69389)
[Link]
Posted Jul 13, 2013 9:43 UTC (Sat)
by mpr22 (subscriber, #60784)
[Link]
Posted Jul 12, 2013 18:56 UTC (Fri)
by yodermk (subscriber, #3803)
[Link] (9 responses)
As for the 32-bit issue, who cares? Is anyone in their right mind still using 32-bit servers? (Ok, I'm sure someone will provide an example of someone who is, but even then they should be looking at migration to 64 bit sometime in the next few years.)
If we back up from Python and consider our entire community, this is a good thing. We don't (or shouldn't) necessarily want *Python*. We want a good solid language that is a joy to use and performs well. Python has been great, but I think Go rightly deserves to be its successor, in many applications anyway.
Posted Jul 13, 2013 6:14 UTC (Sat)
by b7j0c (guest, #27559)
[Link]
Posted Jul 13, 2013 20:38 UTC (Sat)
by Cato (guest, #7643)
[Link] (7 responses)
However it looks like the 32-bit GC issue is on the way to being fixed.
Posted Jul 14, 2013 22:23 UTC (Sun)
by juliank (guest, #45896)
[Link] (5 responses)
Posted Jul 15, 2013 0:19 UTC (Mon)
by mathstuf (subscriber, #69389)
[Link] (4 responses)
Posted Jul 15, 2013 11:30 UTC (Mon)
by juliank (guest, #45896)
[Link] (3 responses)
Posted Jul 15, 2013 23:26 UTC (Mon)
by lsl (subscriber, #86508)
[Link] (2 responses)
Posted Jul 16, 2013 8:49 UTC (Tue)
by juliank (guest, #45896)
[Link] (1 responses)
Posted Jul 16, 2013 20:09 UTC (Tue)
by lsl (subscriber, #86508)
[Link]
Also note that Go gives you enough control over memory that you can easily work around those cases, should you actually encounter them.
Posted Jul 18, 2013 9:26 UTC (Thu)
by farnz (subscriber, #17727)
[Link]
There are two counterpoints, though:
Posted Jul 14, 2013 15:25 UTC (Sun)
by man_ls (guest, #15091)
[Link] (2 responses)
I seriously doubt scripting languages are now worse than they ever were. I count 7 scripting languages in GitHub top 10 languages.
Posted Jul 14, 2013 22:24 UTC (Sun)
by juliank (guest, #45896)
[Link] (1 responses)
Posted Jul 14, 2013 22:41 UTC (Sun)
by man_ls (guest, #15091)
[Link]
If you have a wider survey that shows current trends any please share it.
Posted Jul 13, 2013 17:04 UTC (Sat)
by maxiaojun (guest, #91482)
[Link] (6 responses)
tkinter based Apps looks retro on Ubuntu, for example, my toy app: https://github.com/maxiaojun/zip-fix/blob/master/gui.py
Tcl doesn't support Unicode character outside BMP? WTF?
The widgets are quick to fire but there are glitches here and there.
And, finally, I'm not aware of complete, official and up-to-date reference documentation of tkinter (in Python). There are several incomplete and unofficial around the Internet.
Posted Jul 13, 2013 19:13 UTC (Sat)
by Jandar (subscriber, #85683)
[Link] (3 responses)
Posted Jul 14, 2013 6:41 UTC (Sun)
by maxiaojun (guest, #91482)
[Link] (2 responses)
Posted Jul 16, 2013 19:32 UTC (Tue)
by Jandar (subscriber, #85683)
[Link] (1 responses)
Posted Jul 21, 2013 7:08 UTC (Sun)
by maxiaojun (guest, #91482)
[Link]
Posted Jul 14, 2013 22:27 UTC (Sun)
by juliank (guest, #45896)
[Link] (1 responses)
You mean http://docs.python.org/2/library/tkinter.html is incomplete?
Posted Jul 15, 2013 2:06 UTC (Mon)
by maxiaojun (guest, #91482)
[Link]
The next 20 years of Python
The next 20 years of Python
-languages with optional static typing seems to have "the best of both world" that Python has not.
-performance: performance of Python on one processor isn't that great.
-performance bis: using several CPU in Python isn't that great either.
The next 20 years of Python
http://wiki.python.org/moin/PythonDecoratorLibrary#Type_E...
Static typing isn't just about detecting passing an int to something that expects a float (or vice versa), it's about detecting passing a Penguin to something that expects a Duck. I concede that it may be the case that the decorator you linked to supports the latter check and just has laughably simplistic examples.
The next 20 years of Python
The next 20 years of Python
return x * y * z
The next 20 years of Python
The next 20 years of Python
- PyCUDA: http://mathema.tician.de/software/pycuda
The next 20 years of Python
The next 20 years of Python
The next 20 years of Python
Java!
The next 20 years of Python
The next 20 years of Python
The next 20 years of Python
Tcl
Tcl
Tcl
Tcl
Tcl
Tcl
Anyone using git probably uses Tcl/Tk in the form of gitk and git gui
What? I just use the command line, I don't need anything else.
Tcl
The biggest challenge in the next years is the adoption of Python 3 without loosing too much momentum or users.
The next 20 years of Python
There has been a lot of work to simplify the transition since Python 3.0 came out in December 2008 (eg. allowing unicode literals in Python 3.3). If this trend continues (making the transition easier), things should be ok in 5-10 years. If not, I predict we will see another IPv6-like transition (over 10 years and counting...).
In the past year, the porting of major libraries to Python3 has really picked up steam. As a matter of fact, as of a few weeks ago every package I develop against (including various Django and scientific computing libraries) now supports Python3. I've been using Python3 exclusively for a month now without looking back. It's true that I still make sure any libraries I write work on Python2 as well, but Python3 is here and ready, and over the next year more and more people are going to realize it's possible to use it exclusively.
The next 20 years of Python
The next 20 years of Python
The next 20 years of Python
The next 20 years of Python
The next 20 years of Python
The next 20 years of Python
The next 20 years of Python
The next 20 years of Python
The next 20 years of Python
The next 20 years of Python
And what's the point of static typing?
The next 20 years of Python
Static typing causes a whole category of defective programs to fail at parse-time instead of at an arbitrary moment in execution.
The next 20 years of Python
Go
Go
Go
Go
Go
Go
Go
Go
Go
Go
The next 20 years of Python
that said, i think the glory days of the 90s scripting language are over.
Actually, JavaScript is the cool thing of the day between kids and Java refugees. Big enterprises are rewriting server stacks because of the flexibility JavaScript offers.
The next 20 years of Python
The TIOBE software index shows five scripting languages in the top 10, although their positions are lower than in GitHub.
Developer surveys
The next 20 years of Python
Same app looks much more native on OSX.
The next 20 years of Python
The next 20 years of Python
https://en.wikipedia.org/wiki/Plane_(Unicode)#Basic_Multilingual_Plane
http://www.tcl.tk/cgi-bin/tct/tip/388.html
The next 20 years of Python
The next 20 years of Python
The next 20 years of Python
> and up-to-date reference documentation of tkinter (in Python)
The next 20 years of Python