|
|
Subscribe / Log in / New account

The next 20 years of Python

July 10, 2013

This article was contributed by Martin Michlmayr


EuroPython 2013

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
GuestArticlesMichlmayr, Martin
ConferenceEuroPython/2013


to post comments

The next 20 years of Python

Posted Jul 11, 2013 6:39 UTC (Thu) by vedantk (guest, #88435) [Link] (6 responses)

> Cutting corners is allowed, as you can always go back and improve it later.

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.

The next 20 years of Python

Posted Jul 11, 2013 9:43 UTC (Thu) by renox (guest, #23785) [Link] (5 responses)

>My impression is that the language is ambitious and improving. It should fare well during the foreseeable future.

Improving yes, but very slowly so I'm not that sure:
-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.

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

The next 20 years of Python

Posted Jul 11, 2013 12:15 UTC (Thu) by smitty_one_each (subscriber, #28989) [Link] (3 responses)

>languages with optional static typing

I'm curious how your comment differs from functionality available via
http://wiki.python.org/moin/PythonDecoratorLibrary#Type_E...

The next 20 years of Python

Posted Jul 11, 2013 12:26 UTC (Thu) by mpr22 (subscriber, #60784) [Link] (2 responses)

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

Posted Jul 11, 2013 14:09 UTC (Thu) by juliank (guest, #45896) [Link] (1 responses)

Well, it does, but it's still only a run-time check, and those are not very useful. And in Python 3, you can write things like:

def f(x: int, y: int, z: int) -> int:
return x * y * z

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.

The next 20 years of Python

Posted Jul 22, 2013 6:28 UTC (Mon) by smurf (subscriber, #17840) [Link]

Well, Python isn't compiled, strictly speaking, so that's hardly a surprise.

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.

The next 20 years of Python

Posted Jul 17, 2013 5:37 UTC (Wed) by Cato (guest, #7643) [Link]

Python seems to be gaining momentum not so much in the core language as the libraries and application areas - some very large web apps such as Instagram and Disqus (25,000 requests/sec) are built in Python.

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...
- PyCUDA: http://mathema.tician.de/software/pycuda

The next 20 years of Python

Posted Jul 11, 2013 8:12 UTC (Thu) by thedevil (guest, #32913) [Link] (6 responses)

I have not grown since I was 18. Am I dead?

The next 20 years of Python

Posted Jul 11, 2013 10:19 UTC (Thu) by sorpigal (guest, #36106) [Link] (2 responses)

How about: Languages which are not perceived as exciting do not gain new users as often as they lose them and are therefore doomed to eventual obscurity as fewer and fewer practitioners exist.

Actual growth isn't required, just a perception of "coolness" that continues to attract new blood.

The next 20 years of Python

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.

Java!

Posted Jul 11, 2013 14:46 UTC (Thu) by renox (guest, #23785) [Link]

Some of us remember Java's hype when its libraries were full of bugs..

The next 20 years of Python

Posted Jul 11, 2013 12:18 UTC (Thu) by smitty_one_each (subscriber, #28989) [Link]

[Die, Zombie! joke goes here]

The next 20 years of Python

Posted Jul 11, 2013 13:25 UTC (Thu) by kotnik (subscriber, #57300) [Link]

As programming language, yes: I don't remember hearing anybody coding in TheDevil for decades...

The next 20 years of Python

Posted Jul 11, 2013 23:06 UTC (Thu) by robert_s (subscriber, #42402) [Link]

If you hadn't been growing since you were 18 you would shrivel and die. The body is constantly regenerating itself.

And no, I'm not just making this point to be a pedant.

Tcl

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.

Tcl

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.

Tcl

Posted Jul 12, 2013 19:00 UTC (Fri) by jonabbey (guest, #2736) [Link] (1 responses)

Hm? I thought Ruby was well thought of?

Tcl

Posted Jul 12, 2013 19:09 UTC (Fri) by justincormack (subscriber, #70439) [Link]

It is, as is Lua.

Tcl

Posted Jul 13, 2013 1:27 UTC (Sat) by salimma (subscriber, #34460) [Link]

If Lua is a monstrosity, I don't know what you'd think of Perl.

Tcl

Posted Jul 14, 2013 15:14 UTC (Sun) by man_ls (guest, #15091) [Link]

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.

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.

Tcl

Posted Jul 14, 2013 22:03 UTC (Sun) by juliank (guest, #45896) [Link]

> Anyone using git probably uses Tcl/Tk in the form of gitk and git gui

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.

The next 20 years of Python

Posted Jul 11, 2013 14:52 UTC (Thu) by Wummel (guest, #7591) [Link] (1 responses)

The biggest challenge in the next years is the adoption of Python 3 without loosing too much momentum or users.

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

The next 20 years of Python

Posted Jul 13, 2013 0:48 UTC (Sat) by garrison (subscriber, #39220) [Link]

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

Posted Jul 12, 2013 8:02 UTC (Fri) by b7j0c (guest, #27559) [Link] (23 responses)

enough people know and seem to enjoy using python that it seems unlikely that it will go away in fifteen years, or even that people will wish it to go away.

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.

The next 20 years of Python

Posted Jul 12, 2013 10:34 UTC (Fri) by Cato (guest, #7643) [Link] (6 responses)

Unfortunately Go suffers from a severe GC problem on 32-bit architectures, see https://groups.google.com/forum/#!topic/golang-nuts/qxlxu... (bug 909) for details.

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.

The next 20 years of Python

Posted Jul 13, 2013 6:01 UTC (Sat) by b7j0c (guest, #27559) [Link] (2 responses)

twenty years from now you will only find 32-bit architectures in museums, so i'm not sure why you are bringing this up (everyone who works with go has heard it numerous times before and rightly sees it as a nonissue)

The next 20 years of Python

Posted Jul 13, 2013 9:12 UTC (Sat) by Cato (guest, #7643) [Link]

For people who have to build 32-bit apps now, this could be a real issue so it's worth flagging it. However, it seems to have been solved to some extent since I last looked at it.

The next 20 years of Python

Posted Jul 14, 2013 8:02 UTC (Sun) by dlang (guest, #313) [Link]

you mean like there are no 8 bit architectures being used any longer?

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"

The next 20 years of Python

Posted Jul 13, 2013 8:57 UTC (Sat) by lab (guest, #51153) [Link] (2 responses)

To be fair, this problem appears to be chipped away at consistently, and should already be much less of a problem than it has been. Quoting from http://code.google.com/p/go/issues/detail?id=909#c59 :

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

The next 20 years of Python

Posted Jul 13, 2013 9:15 UTC (Sat) by Cato (guest, #7643) [Link] (1 responses)

Thanks for this useful clarification - seems like progress is being made to fix this.

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.

The next 20 years of Python

Posted Jul 13, 2013 9:28 UTC (Sat) by lab (guest, #51153) [Link]

It would seem that for the vast majority of programs one should not even have to consider doing restarts, or taking other special measures. In other words: "It should just work now" (with Go 1.1 at least). Of course, when deploying a longrunning program written in *any* language, it will always be prudent to monitor it's behaviour, at least in the beginning, to see whether there are any problems or not. In other other words: There should no longer be any special reasons, to have special worries about Go programs. But as always, check it anyway.

The next 20 years of Python

Posted Jul 12, 2013 18:32 UTC (Fri) by MKesper (subscriber, #38539) [Link] (2 responses)

Python has types, even strong typing, since the beginning.
And what's the point of static typing?

The next 20 years of Python

Posted Jul 12, 2013 19:14 UTC (Fri) by mathstuf (subscriber, #69389) [Link]

The problem is that you need to run the program to find problems with your types and 100% runtime coverage isn't exactly a common thing. How likely is something like this[1] in Python versus Haskell?

[1]http://r6.ca/blog/20120708T122219Z.html

The next 20 years of Python

Posted Jul 13, 2013 9:43 UTC (Sat) by mpr22 (subscriber, #60784) [Link]

Static typing causes a whole category of defective programs to fail at parse-time instead of at an arbitrary moment in execution.

Go

Posted Jul 12, 2013 18:56 UTC (Fri) by yodermk (subscriber, #3803) [Link] (9 responses)

Yeah. When I was introduced to Go a month or so ago, I pretty much lost interest in Python for server programming almost overnight. Go is almost as easy to write as Python, has static types, and is MUCH more performant.

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.

Go

Posted Jul 13, 2013 6:14 UTC (Sat) by b7j0c (guest, #27559) [Link]

no one cares about the 32-bit (non)issue, but its usually brought up by people who are looking to hang something negative on go.

Go

Posted Jul 13, 2013 20:38 UTC (Sat) by Cato (guest, #7643) [Link] (7 responses)

Embedded systems and virtual server instances may be 32-bit for a while yet - e.g. Amazon micro and small instances have less than 1.7 GB RAM. Same goes for smartphones, connected devices, etc. 32-bit systems may outnumber 64-bit for some time, though on servers and desktops they are going away.

However it looks like the 32-bit GC issue is on the way to being fixed.

Go

Posted Jul 14, 2013 22:23 UTC (Sun) by juliank (guest, #45896) [Link] (5 responses)

But most likely not longer than 15 years, because they almost all have 32-bit time_t values. So, it's not that problematic.

Go

Posted Jul 15, 2013 0:19 UTC (Mon) by mathstuf (subscriber, #69389) [Link] (4 responses)

Doesn't x32 fix this?

Go

Posted Jul 15, 2013 11:30 UTC (Mon) by juliank (guest, #45896) [Link] (3 responses)

That's just one architecture, though; and one you could just run a 64-bit environment on easily. I was more talking about ARM (and other architectures like Mips exist as well, but Go is not ported to them AFAICT).

Go

Posted Jul 15, 2013 23:26 UTC (Mon) by lsl (subscriber, #86508) [Link] (2 responses)

You can compile your code with gccgo to run on MIPS and other GCC targets.

Go

Posted Jul 16, 2013 8:49 UTC (Tue) by juliank (guest, #45896) [Link] (1 responses)

But is gccgo compiled code affected by the same GC issues?

Go

Posted Jul 16, 2013 20:09 UTC (Tue) by lsl (subscriber, #86508) [Link]

Yes, as the runtime used in gccgo is (mostly) the same. But the issue isn't as bad as people make it sound. I wouldn't worry about it. The GC is constantly improving and even now, with Go 1.1 (in GCC 4.8.1), you shouldn't have any problems outside of some pathological cases

Also note that Go gives you enough control over memory that you can easily work around those cases, should you actually encounter them.

Go

Posted Jul 18, 2013 9:26 UTC (Thu) by farnz (subscriber, #17727) [Link]

There are two counterpoints, though:

  1. 32-bit starts to hit issues at under 1 GiB, and has to use highmem (with all its associated costs) to handle 1 GiB or more.
  2. While Amazon micro and small instances have less than 2 GiB RAM, both support 64-bit platforms; even on the micro instance, with 617 MiB RAM, you could still use a 64-bit OS if that gave you an advantage.

The next 20 years of Python

Posted Jul 14, 2013 15:25 UTC (Sun) by man_ls (guest, #15091) [Link] (2 responses)

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.

I seriously doubt scripting languages are now worse than they ever were. I count 7 scripting languages in GitHub top 10 languages.

The next 20 years of Python

Posted Jul 14, 2013 22:24 UTC (Sun) by juliank (guest, #45896) [Link] (1 responses)

This is caused by GitHubs users, and is not representative of the overall developer population.

Developer surveys

Posted Jul 14, 2013 22:41 UTC (Sun) by man_ls (guest, #15091) [Link]

The TIOBE software index shows five scripting languages in the top 10, although their positions are lower than in GitHub.

If you have a wider survey that shows current trends any please share it.

The next 20 years of Python

Posted Jul 13, 2013 17:04 UTC (Sat) by maxiaojun (guest, #91482) [Link] (6 responses)

Some complain about tkinter

tkinter based Apps looks retro on Ubuntu, for example, my toy app: https://github.com/maxiaojun/zip-fix/blob/master/gui.py
Same app looks much more native on OSX.

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.

The next 20 years of Python

Posted Jul 13, 2013 19:13 UTC (Sat) by Jandar (subscriber, #85683) [Link] (3 responses)

TCL supports Unicode since 8.1 released at 1999-04-30.

The next 20 years of Python

Posted Jul 14, 2013 6:41 UTC (Sun) by maxiaojun (guest, #91482) [Link] (2 responses)

The next 20 years of Python

Posted Jul 16, 2013 19:32 UTC (Tue) by Jandar (subscriber, #85683) [Link] (1 responses)

This tip is only about the quoted form of Unicode, not about the real Unicode characters themselfes.

The next 20 years of Python

Posted Jul 21, 2013 7:08 UTC (Sun) by maxiaojun (guest, #91482) [Link]

Try displaying a non-BMP character in a tkinter widget.

The next 20 years of Python

Posted Jul 14, 2013 22:27 UTC (Sun) by juliank (guest, #45896) [Link] (1 responses)

> And, finally, I'm not aware of complete, official
> and up-to-date reference documentation of tkinter (in Python)

You mean http://docs.python.org/2/library/tkinter.html is incomplete?

The next 20 years of Python

Posted Jul 15, 2013 2:06 UTC (Mon) by maxiaojun (guest, #91482) [Link]

Yes. It is just a quick skim of tkinter.


Copyright © 2013, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds