Slashdot Mirror


Interviews: Q&A With Guido van Rossum

Guido van Rossum is best known as the creator of Python, and he remains the BDFL (Benevolent Dictator For Life) in the community. The recipient of many awards for his work, and author of numerous books, he left Google in December and started working for Dropbox early this year. A lot has happened in the 12 years since we talked to Guido and he's agreed to answer your questions. As usual, ask as many as you'd like, but please, one question per post.

4 of 242 comments (clear)

  1. Python 3 Regrets by n1ywb · · Score: 3, Insightful

    If you could go back in time, what, if anything, would you do differently WRT to developing and releasing Python 3?

    --
    -73, de n1ywb
    www.n1ywb.com
  2. functional programming by ebno-10db · · Score: 4, Insightful

    Some people claim that Python is, at least partly, a functional language. You disagree, as do I. Simply having a few map and filter type functions does not make for a functional language. As I understand it those functions were added to the libraries by a homesick Lisper, and that several times you've been tempted to eliminate them. In general it seems you're not a fan of functional programming, at least for Python.

    Question: do you feel that the functional programming approach is not very useful in general, or simply that it's not appropriate for Python? It would be nice to hear your reasons either way.

  3. Re:Multi-line lambdas by DriedClexler · · Score: 4, Insightful

    Solution:

    1) Make it a named function.
    2) Place the name where you'd otherwise put the lambda.

    It works, although you have to deal with the horror of a reusable function defined a few lines up.

    --
    Information theory is life. The rest is just the KL divergence.
  4. Re:BC Breaking changes in 3 by gr8_phk · · Score: 3, Insightful

    This is my #1 reason for not using Python. Why use a language that has no commitment to backwards compatibility when there are plenty that do?

    Why use a language that is interested in "backwards compatibility" when Python is into "forward compatibility". You can "import from future *" to make your code use features that are not yet in the latest release. Why embrace legacy ways of doing things when you can be focused on the future instead? I find the push to make it more perfect for the future a plus even if it means short term pain.