Python creator, Guido van Rossum took time to come talk to us
about his creating a new language. He talked about his reasons for
creating Python as well as where he saw the language going in the future.
He even compared Python to other languages and discussed its strenths and
weaknesses. If you missed the event, then here's the log to catch the
inside scoop about Python.
<Wintersun> I noticed, thanks. :)
<gvanrossum> OK, send those questions to LcModerator!
<Wintersun> How about we go ahead and wait about 5 minutes before starting the event? Give people a few more minutes to join.
<gvanrossum> Anybody here who flamed me recently on c.l.py? :-)
<gvanrossum> Sure.
<LcModerator> if guests want they can /msg me questions now and I will just ask them once we start
<LcModerator> Duffy that is not up to us unfortunatly thats up to the sys admins of OPN as to it being a wallop or global
<Wintersun> Okay, let's go ahead and get this event started
<Wintersun> First of all, I'd really like to thank everyone for coming out today
<LcModerator> all set
<gvanrossum> Hi there!
<Wintersun> I'd also like to thank Guido van Rossum for taking some time from the O'Reilly Convention to be with us today. :)
<gvanrossum> Actually, due to a medical emergency I'm at home.
<Wintersun> We still appreciate you talking with us.
<gvanrossum> You're welcome. It's more relaxed here than it San Diego, I'm sure. :)
<Wintersun> Guido, would you like to start by saying something about Python and what you've been up to lately?
<Wintersun> And, in the meantime, please /msg any questions you have to LcModerator
<Wintersun> Thanks!
<gvanrossum> I would hope everybody here knows Python, at least by reputation: an object-oriented scripting language with a very clean syntax and a large standard library...
<gvanrossum> Python has been around for 11 years by now...
<gvanrossum> What I've been up to: released Python 2.2a1 and defended PEP 238, a proposal for a change to the division operator...
<gvanrossum> It turned out to be, eh, "divisive" in the community. But I think we've worked out a solution.
<LcModerator> What inspired you to create Python, was it because other languages lacked what you wished to do
<gvanrossum> (over)
<gvanrossum> While I'm waiting for followup questions, I'll give a brief overview of what's new in 2.2
<gvanrossum> - nested scopes are now standard
<gvanrossum> - iterators and generators
<gvanrossum> - type/class unification (e.g. subclass dictionary!)
<gvanrossum> - UCS-4 support (config time option)
<gvanrossum> - xmlrpclib standard module
<gvanrossum> - IP v6 support (config time option if platform kernel supports it)
<LcModerator> gvanrossum: we just have some server lag is all so takes a second for the ?'s to appear
<LcModerator> What inspired you to create Python, was it because other languages lacked what you wished to do?
<gvanrossum> Definitely. This was 11 years ago and I needed a scripting language to run on an experimental distributed OS that was very different from Unix, so porting existing Unix languages like sh, Perl, Tck was not an option.
<LcModerator> <Skatters> Is Python a better beginner language than Perl?
<gvanrossum> The other motivation was that I had experience in language design and implementation: in 83-86 I worked on the ABC team, a language for education that greatly influenced Python.
<gvanrossum> Skatters: Python is definitely better for beginners. There are fewer rules to learn and fewer surprising effects.
<LcModerator> <X86BSD> Why did you spend so much effort and go so far out of your way to appease the FSF to be "GPL compliant" with the Python License?
<gvanrossum> There are also several beginners tutorials and at least one textbook...
<gvanrossum> See http://www.python.org/doc/Intros.html
<gvanrossum> X86BSD: because the *original* Python license (up to 1.5.2) was GPL compliant and many users regretted the change. Also e.g. the Debian folks really wanted GPL compliance back.
<LcModerator> <eAndroid> Guido, I tried to get this asked on your /. interview but was largely ignored: how (and why) do you deal with flames so well?
<gvanrossum> eAndroid: good question (and thanks!). I don't always deal so well, but I've learned over the years that for every flamer there's also someone who respect me, and that puts it in perspective. I used to be a real usenet nerd myself in the early 90s.
<LcModerator> <radix> have you heard of Twisted? Did you know that TwistedMatrix Laboratories is the only feared enemy of the PSU?
<gvanrossum> Maybe also it's just in my nature, and if I hadn't dealt with flames well Python wouldn't have made it to where it is now. :)
<gvanrossum> radix: I've heard of Twisted and even downloaded his code once, but I couldn't understand one bit of it. Twisted, if you're here, sorry, but that's a fact.
<gvanrossum> The PSU, of course, doesn't exist.
<LcModerator> <Mike_L> Guido, do you have any plans to strengthen Python's sandbox capabilities?
<gvanrossum> Mike_L: not really. 6 years ago I was all excited about restricted execution, and created the rexec module, but it hasn't proved to be an important application area, so far.
<gvanrossum> Let me take that back...
<gvanrossum> In Zope, sandboxed execution is very important, but they have taken a different approach. They analyze the source code (or the bytecode, depending on which version)...
<gvanrossum> and insert security assertions in the code that gets executed. This is a very different approach than rexec, and possibly safer...
<gvanrossum> Certainly more flexible in the security policies that can be implemented, and that is very important for Zope (not ever Zope user has the same permissions).
<LcModerator> So all guests are aware I have a ton of ?'s so if yours is not posted right away I do them in order if not already asked. Also many of you have multiple ?'s so will take a bit of time for them to appear
<LcModerator> <snibril> guido, when will you stop calling python a scripting language? ;)
<gvanrossum> snibril: as soon as the users stop doing so. It's much more than that, but many people understand it better if we describe it as a scripting language. :)
<LcModerator> <banned-it> for people who don't know much about python where could they get documentation to learn about it
<gvanrossum> banned-it: http://www.python.org/doc/.
<LcModerator> Guido: What do you think about .NET and the common bytecode language? Do you see Python outputting this type of bytecode? I dream of the day that Ruby, Perl and Python could use each other's modules, something that perhaps would be possible with a common bytecode :)
<gvanrossum> Go to the Introductions link, there are lots of tutorials there.
<gvanrossum> I don't expect that all computers of the world (or even most) will be using .NET...
<gvanrossum> I've seen too many companies attempt to come up with the ultimate language/runtime/operating system to end all debates over which language/runtime/OS you should choose, and all they end up doing is adding one more choice to the list.
<gvanrossum> (more)
<gvanrossum> On the other hand, Python already runs on .NET, and I think some limited form of cross-language component invocation is already possible...
<gvanrossum> But I don't know much about that, the work is all done at ActiveState.
<LcModerator> does python support parallel programming, and if so, how well, and comparasions with perl on this would be nice:)
<gvanrossum> I don't know anything about Perl parallel programming...
<gvanrossum> Python supports multiple operating system threads pretty well...
<gvanrossum> There are also folks who use Python on massively parallel machines...
<gvanrossum> Python's thread model is somewhat similar to Java's, but you must manipulate your own locks (there's no "synchronized" keyword).
<LcModerator> <zilch> I know you're a big fan of the tkinter module, but what do you think about the bindings for other UI Toolkits like PyGTK, PyQT, WxWindows?
<gvanrossum> zilch: I'm a big fan of wxPython too, and appreciate PyGTK and PyQT. Basically, they all serve different purposes, e.g. their portability is different and the supported widget sets differ. Tkinter is simply the oldest and in a sense a baseline...
<gvanrossum> Also, Tkinter's text and canvas widgets are unsurpassed.
<LcModerator> <runyaga> What are ExtensionClasses and when will they go away?
<gvanrossum> runyaga: ExtensionClasses are a very neat hack by Jim Fulton; they use a loophole in the class statement to allow a third party extension to define its own class implementation...
<gvanrossum> I expect I will support them for one or two revisions yet, but they are made redundant by the type/class unification in Python 2.2, which makes subclassable extension types a standard part of the language. I encourage everybody who is using ExtensionClasses now to look into converting to the new mechanisms in 2.2.
<LcModerator> <datagrok> can you suggest any specific reading material (books, code, etc,) for those who wish to become python masters? How did you build your own skills as a programmer?
<gvanrossum> datagrok: for books, see the python bookstore at http://www.python.org/psa/bookstore/ ...
<LcModerator> <JALH> I don't like the face that python depends so much on white-space, why not use {} like everyone else?
<LcModerator> <JALH> guido, have you still got that afro?
<gvanrossum> It is also a good idea to study the source code of the standard library. It has lots of examples of well-written code (some even by me :-) from which you can learn...
<LcModerator> sorry about that guido mouse went wonkey on me
<gvanrossum> My own skills were developed doing it for over 25 years.
<gvanrossum> JAHL: Sorry, we disagree on esthetics. There's not much you can do about that. I find whitespace creates more readable code than {}.
<gvanrossum> What afro?
<LcModerator> <Kilroy> What from ABC did you use in the design of python?
<LcModerator> <Kilroy> Are ther any more functional programming concepts that you would consider including in python - for example haskell pattern matching for functions?
<gvanrossum> Kilroy: indentation and the colon; the desire for a small number of statements; the desire for a small number of powerful datatypes; the dictionary type; long ints; the 'in' operator; and even the `...` notation. Probably more.
<gvanrossum> Kilroy<2>: no, I think Python should not develop more functional features, and the ones that are already there were a mistake.
<gvanrossum> E.g. lambda, map, filter, reduce mostly create hard-to-read code. List comprehensions are much etter.
<gvanrossum> s/etter/better/
<LcModerator> <Acapnotic> How does the weather look for Interfaces in Python? Can we expect a more reliable way to ask "is this a file-like object" than checking for attribute names?
<gvanrossum> Acapnotic: not in 2.2, but I think thereafter I'll give it a try. I am not very much in favor of the Interfaces PEP (245). The notation there looks very unPythonic to me...
<gvanrossum> Maybe I'll develop a class hierarchy that can be used to answer these questions; but Jim Fulton (Zope's architect) thinks that classes represent only implementation and should not be used to represent interfaces. The discussion is still open.
<LcModerator> 2 part ? coming up Guido as they are somewhat related if you don't mind
<LcModerator> where do you see Python in two years from now, as far as language features and performance?
<LcModerator> <jwr_> What are your future plans for Python? Are there any major features you would like to introduce to the core language?
<gvanrossum> Strangely enough, 2 years is beyond my horizon!...
<gvanrossum> I expect we'll be in the middle of the design for Python 3.0, and may even have alpha or beta releases out, but 2.x will be what most people still use...
<gvanrossum> In and after 2.2 I want to work on performance, but since that's not the area where I excel most, I will need help...
<gvanrossum> Re features, I think I'll try to stabilize the language, and concentrate on finishing the type/class unification work...
<gvanrossum> Oh, we'll be working on a unified numeric model (PEP 228) plus possibly the introduction of rationals (PEP 239/240)...
<gvanrossum> Does everybody know where to find PEPs? http://www.python.org/peps/.
<LcModerator> <Skatters> Is python available for Mac OS X?
<gvanrossum> Skatters: it certainly is. I think the MacPython page has it. It also builds from source there in the Unix environment (so I've herd).
<LcModerator> will the global interpreter lock go away? in future releases or do you think it is required and must stay
<gvanrossum> Removing the global interpreter lock would mean making every data structure and data type thread-safe. This probably means adding a lock to each object, which will probably SLOW THINGS DOWN. If you have a multiprocessor, FORK a Python process for each processor. Note that on a single CPU, multiple threads run nicely interleaved because the global lock is released every 10 byte code ops.
<LcModerator> <chillywilly> Have all GPL issues been resoved?
<gvanrossum> (The slowing down is not a hypothesis -- Greg Stein did this for Python 1.4 or 1.5, and it was about 50% slower.)
<gvanrossum> chillywilly: yes, all GPL issues have been resolved. Python 2.0.1, 2.1.1 and 2.2 are all GPL-compatible. (Note: it's not released under the GPL itself -- it just allow combining with GPL-licensed software.)
<LcModerator> <jmd> what main area(s) do you think python could be the most beneficial, but hasn't yet really caught on, or perl is the more popular choice? Web CGIs, GUI apps, scientific work, learning tool...
<LcModerator> and do you know PERL at all
<gvanrossum> I don't know much Perl (I can recognize it but usually I can't read it and I certainly can't write it)...
<gvanrossum> I think for scientific work and learning, Python is already more popular.
<LcModerator> <dalf2> Do you think that a decent Python compiler will be done, or do you think there are intrisic limitations ?
<gvanrossum> Python is better for larger applications -- I cannot imagine writing something as complicated as Zope in Perl. Look at Mailman vs. Majordomo (now almost dead).
<gvanrossum> dalf2: I am optimistic that eventually someone will come up with a decent way to compile Python into C...
<gvanrossum> Recently someone posted an early prototype that already got impressive results with little effort...
<gvanrossum> But it will be a massive task.
<LcModerator> <VaiX> - What type of unicode support is currently available - is it stable?
<gvanrossum> VaiX: yes, Unicode support is stable, in the sense that the released code is as bugfree as you can ask for. It is supported since 2.0. In 2.2 we will add UCS-4 support as a compile-time option, and some new codec APIs, but old code will continue to work.
<LcModerator> <mkm> do you see Python ever becoming more proficient in the use of low level programming as far as the kernel/hardware level?
<gvanrossum> mkm: no, I don't think Python needs to compete for that niche.
<LcModerator> Are there existing XML libs/tools/interfaces for python?
<gvanrossum> XML: YES! Python 2.0 and later have XML parsers and a DOM implementation, and there's a XML-SIG that maintains a superset of that code as an add-on. See http://www.python.org/sigs/xml-sig/
<LcModerator> <Mike_L> Guido, have you tested Stackless Python? Do you intend to add continuations or other threading alternatives to Python?
<gvanrossum> Mike_L: I have played briefly with Stackless. It has a touch of genius but the code is brittle. I have never been able to understand a single piece of code that used continuations, so they are not in my plans for the future; however, I like coroutines...
<gvanrossum> In 2.2 we will have generators, which do 80% of what coroutines can do (limited to a single stack frame, which is a it of a limitation, but also avoids many of the restrictions in Stackless).
<LcModerator> <Erwin> Do you see more static typechecking ever appearing in a future Python version? I know that attempts have been underway for several years now without any seeming results. How about implied types, a la ML, where the compiler detects the type of expressoin based on what types you use in it?
<gvanrossum> I'm ambivalent about static typechecking, unless we get some academics interested. Tye type-sig has had so many false starts that I don't have high hopes any more. Implied types are different than what Python currently uses; I know very little about ML but I seem to recall that it is so mathematically oriented that it requires an IQ of about 150 to be able to use successfully. I'm not going after that niche. :)
<LcModerator> <hineste> Are there any plans for the future concerning garbage collection in python (e.g. going from the reference counting scheme to mark/sweep)?
<gvanrossum> hineste: as of Python 2.0, we have GC *in addition* to reference counting. It works really well.
<LcModerator> <Rainy-Day> are you thinking about splitting python with radical newbie-friendly features like case insensitivity and stuff like that?
<LcModerator> as in a newbie-friendly branch
<gvanrossum> Rainy-Day: no, that would be a mistake. It's better to have a special IDE for newbies, but the underlying language should be the same...
<gvanrossum> Eventually a newbie becomes an expert, and it would be annoying to have to learn different rules. Also it would be condescending to learn a dumbed-down language. Special tools are more like training wheels: you can get rid of them when you're ready.
<LcModerator> <datagrok> you stated earlier that lambda, map, filter, reduce mostly create hard-to-read code. Can you give a pseudocode example of your preferred replacement for, say, for (ite