Guido van Rossum Interviewed 226
Qa1 writes "Guido von Rossum, creator of Python, was recently interviewed by the folks at O'Reilly Network.
In this interview he discusses his view of the future of Python and the Open Source community and programming languages in general. Some more personal stuff is also mentioned, like his recent job change (including the Slashdot story about it) and a little about how he manages to fit developing Python into his busy schedule."
Python (Score:2, Interesting)
Re:Python (Score:2)
Start here (Score:5, Informative)
Re:Python (Score:5, Informative)
Re:Python (Score:5, Informative)
I second that (Score:3, Informative)
Re:Python - Python in a nutshell (Score:3, Interesting)
My recomendation:
Python in a Nutshell by Alex Martelli
Hands dow the best introduction to Python from a programmer's prespective. That is if you are already familiar with basic programming concepts. The great thing about the book is that covers just about every aspect in an extremely concise way that does not bore you to death.
I'm a certified Java and XML developer, gave up on Perl long time ago, discovered Python, somehow got over my initial suspicions regarding the whitespace ... within two weeks
Re:Python - Python in a nutshell (Score:2, Informative)
Python on the Zaurus (Score:2)
Re:Python on the Zaurus (Score:2, Informative)
Can anyone (Score:3, Interesting)
The MAJOR advantage is simplicity (Score:5, Informative)
Sure you can do the same things in other languages, at the end all general languages are Turing Machine equivalent. The difference is that Python is EASY to read [pm.org] (according to Master Yoda). It is bottom-up designed to be.
So it is good not only for scripting, but too for prototyping and for everything which needs to be flexible and not too much efficiency-critical. The logic of some videogames is encoded in Python, you know.
Re:The MAJOR advantage is simplicity (Score:3, Funny)
Re:The MAJOR advantage is simplicity (Score:2, Insightful)
I think that Python is a lot easier to read than Ruby or Java. Ruby allows a lot of the same punctuation-based idioms that make Perl so difficult to read and Java is too verbose to be easy to read. Consider the Java version of hello world:
Cheers,
Brian
Re:The MAJOR advantage is simplicity (Score:2)
Of course. Python is executable pseudocode, but Perl is executable line noise. (First saw this on the Slashdot "wisdom line". :-))
PHP is not easy to read, in most cases (Score:4, Insightful)
PHP suffers readability not in syntax, but in archetecure design. With global namespaces for module functions (say, for example, to FTP a file), you do not have the ability to trace the logic between source files and modules in someone else's code. In addition, PHP encourages the inlining of code in presentation, and most PHP code is not modular (some is) - but on top of that the most popular mechanism for code reuse is eval() and include(), which simply pop more crap into the global namespace without being explicit what they do.
All this impacts readability. Python does not have these problems becuase it encourages explicit namespaces for all objects/modules/packages/classes/etc. Python also enforces readabilty by simple (easy) use of whitespace (this is a good thing.
Re:PHP is not easy to read, in most cases (Score:2)
As for you other critisims I think they are offbase. Both languages use include() hell all languages have some sort of an Include. PHP does not "encourage" inlining of code, smarty is an official part of PEAR but neither does it force people to use smarty. Finally speaking for myself I don't think I have ever used eval() nor seen it used in any major proj
Re:Can anyone (Score:3, Interesting)
If you are using Java then python is a step up because it offers first class functions and some other incredibly power constructs.
Unfortunately, although Python's effort is applaudable, it really is
Re:Can anyone (Score:5, Funny)
Re:Can anyone (Score:4, Insightful)
I look around and it seems to me like most "new" things in CS have been around for 20 years. Why is everybody so intent on rewriting smalltalk and lisp? Does it seem strange to you that every language eventually starts looking like smalltalk and lisp?
Re:Can anyone (Score:4, Funny)
Because they get embarrassed trying to make smalltalk with a lisp.
Re:Can anyone (Score:4, Interesting)
More and more, I'm thinking corporate America is decades behind what the academic world takes for granted. XSLT, for example, is something that never should have happened. And its not just Lisp. Take, for example, DAML+OIL. Its an XML-based language that can make statements in first order logic that can be verified by a theorem prover. Its so complicated and verbose, that its nearly impossible to write by hand, and most people use GUI tools to work wih it. In the next version, they're adding support for limited execution capability (ala XSLT). Meanwhile, I'm thinking, "hello --- Haskell?"
*> My impression of this mainly comes from comp.lang.lisp. I find some of the people who hang out there to be among the rudest I've seen on the Internet. Some pricks, like Eric Naggum (search for "arrogant" on c.l.c in Google Groups and see who gets the first 20 hits...) are actually revered for their rudeness! It might just be there are more math/pure-science types on that board, and while they're definately smart, they can also be rather rude.
Re:Can anyone (Score:2)
All languages nowadays are slowly adding individual pieces of Lisp functionality. Why not just use Lisp (no reason to wait a decade for all the "popular" languages to finally come fill circle and become Lisp dialects).
At first:
Lisp alone is only Lisp, if at all, some should use a lisp with oo extensions.
Even the simplest pascal algorith is hard to be coded in "pure" lisp, as you have to do the trick of converting all "record" like data structures in list/lisp like equivalences.
Second:
Some people thin
Well, (Score:2)
Re:Unfortunately... Re:Don't fully agree. (Score:4, Insightful)
You don't have to do any kind of language design when you do Lisp programming. You can get a long way with just using plain function definitions. Yet you can easily define new syntaxes, control structures and stuff.
Back when I was the proud owner of a Commodore C 128, I used to think similar things about useless stuff like GOSUB. Why can't we just stay with the more familiar GOTO that everyone understands?Get over it. Learning new tools is usefull, but it's work. Get a good book on Lisp macros [paulgraham.com], and dive in.
You are not alone. And, given that you can actually define a new syntax, many people tried to come up with alternatives to raw s-expressions. And indeed succeeded. However, none of these alternatives ever got too popular (the most successfull attempt might by the Dylan language, which started with s-expressions, but dropped them). People could have used alternative syntaxes, but the vast majority chose not to.Re:Unfortunately... Re:Don't fully agree. (Score:2)
(when i say y
LISP misconceptions (Score:3, Informative)
You've been fed a batch of bad Kool-Aid. Fortunately, it's not too late to come around.
It's what LISP brings to the table above and beyond being a programming language (as most programmers think of the term) w
Re:LISP misconceptions (Score:2)
So you admit it!!! ;-)
I think that's the crucial problem with Lisp syntax. It's not mean to be easily read, but easily accessed from the language itself. My point is that Lisp is a 40 years old programming language, and that has its burdens. Everything discovered later about user friendliness is lacking. Lisp syntax is too simple for most everyday tasks as, for example, reading other people's code.
If you have to remove the main attribute of the language in order t
Re:LISP misconceptions (Score:2)
It is easily read. Just invest the time getting over the initial hurdle of the parentheses and it's a very easy-to-read language.
My point is that Lisp is a 40 years old programming language
John McCarthy first started working on LISP in the 50s. It's older than 40 years.
Lisp syntax is too simple for most everyday tasks as, for example, reading other people's code.
This would be true if LISP programmers generally had diff
Think Different!! Re:LISP misconceptions (Score:2)
Your example
(define _merge (l1 l2 cmp)
(cond
((null l1) l2)
((null l2) l1)
((cmp (car l1) (car l2))
(cons (car l1) (_merge (cdr l1) l2 cmp)))
(t
(cons (car l2) (_merge l1 (cdr l2) cmp)))))
is excellent.
a) I'm at first german, and english I learned in school. So: That above is completely unreadable to me!
the
Re:Think Different!! Re:LISP misconceptions (Score:2)
It's unreadable in English, too. It's perfectly legible when thinking in terms of formal computational theory. English, German or other natural languages are not good choices for programming; there's too much context sensitivity, too much implicit meaning, for it to reduce well to mathematics.
the only word in my english german dictionary where I can find a translation is null.
Your dictionary doesn't h
Re:Don't fully agree. (Score:2)
See: grunge.cs.tu-berlin.de/~tolk/vmlanguages.html
angel'o'sphere
Re:Don't fully agree. (Score:2)
ML is strongly typed which means its immediately useless. OOP can viewed as a relaxation from strong types (in C) to slightly dynamic types. You watch, eventually most languages will be dynamically typed).
One of the problems I had when I tried to learn Lisp was that it needs special editor support. This meant, as far as I could tell, I had to learn emacs.
First off, emacs is butter. Emacs is gorgoes. Emacs is so extensible and so effic
Re:Or you can meet Lisp's cousin, Dylan. (Score:2)
when I looked at dylan, around 1995, it looked like pure lisp and I ditched it.
Then it seems the dylan lovers ditched it because of the infix notation and more keywords
angel'o'sphere
Re:Can anyone (Score:2)
I came to Python from Perl, dealing mainly with text manipulation and glue-type applications, in which both Perl and Python are very adept languages. For me, Python was a breath of fresh air, - no more curly braces, indentation became an integral part of the code, rather than an annoyance (when it went wrong), and mainly, Python is OO by design, whereas in P
Re:Can anyone (Score:5, Interesting)
o Python uses indentation to denote code blocks, rather than curly brackets {} or other methods. This, along with a few other layout rules, makes Python code very strictly laid out. This makes it both easy to read and code, and you really don't miss being able to use your own crazy layouts (ahhh, perl
o Python is totally object orientated, and very intelligently designed in this department. Whereas in Perl (5) you have to jump through hoops to create objects, especially OO modules, in Python it's as easy as assigning a variable a new value.
o Python has quite a few very useful built in object types, including strings, ints, floats, lists, tuples, dictionaries, functions, classes, and more. This makes things easy if you don't want to make complex matrices. It is also easy to make more complicated types by embedding C...
o It is really easy to embed C/C++ code in Python, and vice versa, so where Python suffers on performance you can boost it with C/C++, or use a Python tool appropriately called "boost"
Generally, Python is very handy for anything from one-time dirty scripts to full applications (there are some good GUI toolkit ports about.. PyGtk, PyQt, PyKDE, wxWindows, etc), and is also very handy when developing prototypes.
But what really makes me like Python (as I'm not a language nerd by any measure) is that it is just *easy* and *fast* to code in... it doesn't get in your way.
(Pimping out...)
Re:Can anyone (Score:3, Informative)
Python is totally object orientated, and very intelligently designed in this department. Whereas in Perl (5) you have to jump through hoops to create objects, especially OO modules, in Python it's as easy as assigning a variable a new value.
Alright, lets set something straight here. The world is on a huge object oriented high. As has been said about strict types, object oriented programming is a hammer and everything all of a sudden looks like a nail.
Any language that is
Re:Can anyone (Score:2, Informative)
From the Learning Python book [oreilly.com] (see sec. 1.1.1.1):
So, while Python supports object oriented programming, it doesn't force you to use it.
Re:Can anyone (Score:2)
You don't have to use Python's object oriented features. For example, you can find all of the 22-character long English words with only the tiniest sprinkling of OO:
>>>for w in filter(lambda x: len(x) == 22, file('/usr/share/dict/words').readlines()): print w
electroencephalograph
Mediterraneanizations
OTOH, people high on OO could write:
>>> print 22. __add__(3)
25
Python gives you both
Re:Can anyone (Score:2)
File "<stdin>", line 1
print 2.__add__(3)
^
SyntaxError: invalid syntax
>>>
Hum, seems you cannot do that. Of course, in Ruby you can do 10.+(29)
Re:Can anyone (Score:2)
Try: .__add__(3)
2
or even: .__add__(3)
2.
Re:Can anyone (Score:3, Informative)
It's available if you want to use it, but you're not forced to
use it when it's not appropriate.
Re:Can anyone (Score:2, Informative)
ANYTHING that you can do in Lisp/Ocaml (and other functional languages), you can do in Python. Go read a bit. Python does not force you into any style. You're free to use whatver you want.
Re:Can anyone (Score:2)
Personally I think this is a flaw and not a feature. One of my pet peeves is scrolling to the end of some function and seeing this.
}
}
}
With python you don't even have that.
I like the php alternative best.
endif;
endwhile;
endforeach;
}
Re:Can anyone (Score:3, Informative)
Not really. 2.2 and up get a little closer to that, but Python is really a procedural language with a very nice but very optional set of OO features. (Internally, the Python and Perl OO implementaions are very similar, even if Perl's hideous object syntax does a good job of hiding it.) This is a nice pragmatic approach, akin to what Objective C does.
If OO purity is one of those things that appeals to you, Ruby or Smalltalk might be fun toys.
Re:Can anyone (Score:5, Informative)
Re:Can anyone (Score:5, Informative)
1. Python as a scripting language has several features seen in Objective C(and other similar languages) not found in C++. Class members can be detected and bound at runtime, further it's possible to search a classes members for information.
2. Pydoc and documentation strings. Python has built in support for documentation strings, and a great utility for automatically generating documentation. Documentation is actually a part of the programming language, and not an after-market add-on.
3. Dictionary objects, tuples, lists - are all part of the basic language. Dictionary objects allow interesting hash tables to be created without much effort at all. This feature is seen in Perl.
4. Maybe a miss feature, but enforced indentation creates much easier to read code.
5a. The shelf object. This essentially allows any object to have it's runtime information stored in an easy and effecient matter. It can then be reloaded after a run.
5b. The pickle object again allows objects to easily be stored in files.
6. Python is _EXTREMELY_ easy to extend using the Python C API.
7. Python includes functional programming aspects such as mapping and lambda forms.
8. Python includes an extremely complete library that does just about everything one would desire to be able to do. Using the python runtime library allows your code to be easily portable without the headaches involved in C/C++ porting.
9. Using psyco, it's possible to have Python code JIT on i386 processors. This gives a significant performace boost.
10. A development community and support community second to none.
There are other aspects that I haven't touched on here, but these are the major things I've found helpful so far.
Re:Can anyone (Score:5, Interesting)
Python, Perl and Ruby are all very good interpreted, flexible, rapid-prototyping languages. They all have their relative strengths and weaknesses, but all are good enough that if you are choosing between them, it boils down pretty much to your own preferences and what coworkers and other people around you use (or on what animal you prefer on the cover of your reference literature:) ).
If you mean this class of languages as opposed to C, C++, Java and so on, well, it becomes a matter of what you want to accomplish. The great benefits of these interpreted languages are that they make development very fast, compared to the more traditional languages (yes, Java is interpreted, but it is still designed as a traditional language). You spend more time solving your task and less time managing the mechanics of development. Also, they really make use of the benefits of being interpreted with things like closures, dynamic code evaluation and so on. And they typically have very complete, transparent access to the surrounding system - why spend two days writing some hairy functionality when you can trivially filter your data through an external application that already does the whole job for you? Do not underestimate "scripting type glue".
They do make a pretty good fit running large systems - the Swedish pension management system is all written in Perl, for instance, and Zope is written in Python. They are also quite efficient; they are on the whole as fast as a Java implementation, and occasionally (when the task plays to the specific language's strengths), quite a bit faster.
I typically use C/C++ and Perl for development, and every time I've been using Perl for a while, I get bouts of frustration with traditional languages for the lack of such things as hash datatypes and inline regular expressions. But for some tasks, traditional languages are the way to go.
Re:Can anyone (Score:5, Interesting)
I'm a professional C++ programmer, and a devout pythonista. What I miss most in C++ are the easy-to-instantiate datatypes like tuples. It's so much easier to pass a relatively simple datatype as a tuple, as opposed to introducing a whole new class and even *gasp* a new file to do the trick.
For example I can trivially code a function that returns an array of (name, address) tuples, and I can easily manipulate such an array:
tuples = get_address_entries()
for name,address in tuples:
print name,"lives in",address
After doing Python for a while, one sees how much static typing gets in your way of doing things the "proper" way, and very often one tries to avoid doing the damn thing at all... resulting in a sub-optimal design. Python allows you to be all you can be
C++ and tuples (Score:3, Informative)
And regarding your example code, the same can be done trivially in C++ with the added significant bonus of strong static typing:
Re:C++ and tuples (Score:3, Interesting)
Yes, I have written code like this, and generally like STL (too bad I can't use any of it for my work). However, it requires quite a lot of typing, and the resulting code is not as easy to understand.
Three lines of Python, three lines of C++ (barring the typedef, which is only there to make the rest of it easier to read).
And therein lies the catch, typedef is needed.
Re:C++ and tuples (Score:2, Informative)
You should always use the prefix increment ++i when using STL iterators (although in the case of vector they might just be typedefs for pointers).
The reason is that since the postincrement must return the previous value, the iterator has to be copied.
Re:C++ and tuples (Score:2)
Explicit typing (Score:2, Informative)
However, you're right about the 'easy to instantiate' part, but I don't think static typing is really the problem. The problem with types in C++ is that you have to explicitly mention them, when a lot of the time the compiler could figure them out itself. In your example, you could do:
std::vector<std
Re:Explicit typing (Score:2)
Not built-in enough; In python I can do:
mylist = [("hello",3),("world",4)]
Additionally, some environments shun STL (and templates in general) because it leads to code bloat.
There's been some discussion about introducing type-inference into the language, so you could say:
auto entries = get_address_entries();
Like that is ever going to happen... I don't even think any C++ compiler has achieved ISO C++
Re:Can anyone (Score:2)
No. That's a big advantage, but the really great advantage is that you can modify things on the fly. You can add methods to a class, or to objects of a class, during the execution of the program. You can create code that you then execute, etc. (I know that you *can* do that in C... but just try it!)
Lisp has most of the advantages that I mentioned in the preceeding paragraph, but it is
Java is not interpreted (Score:2, Informative)
Re:Java is not interpreted (Score:2, Insightful)
Actually, it's not FUD.
For string processing, database access, and pretty much...well...everything, Perl *smokes* Java. Python is slower than Perl, but Guido acknowledges that.
Also, though one can buy into the Java Marketing Machine and proclaim that there is indeed a "Virtual Machine" and "Java is not interpreted", in fact, very few languages are actually "interpreted" i
(OT) Hello, world! (Score:2)
You can write "Hello, world!" in only 500k?
I'm impressed. In my youth, we did it using feeble tools like x86 assembler on MS-DOS, and it required a massive 25 bytes, more than half of them taken by the string in question.
I know about apples and oranges, but I can't help wondering if the w
Re:Java is not interpreted (Score:2)
Links to studies? Statistics?
Java bytecode is produced from source, but this bytecode, too, must be executed as data, not as a native instruction.
If you'd read the actual post you responded to, you'd learn that bytecode is nowadays compiled to native instructions.
All of this is relatively meaningless; arguing that Java's "virtual machine" is not an interpreter does not say anything for the language
Of
Re:Can anyone (Score:3, Interesting)
Python, Perl and Ruby are all very good interpreted, flexible, rapid-prototyping languages. They all have their relative strengths and weaknesses, but all are good enough that if you are choosing between them, it boils down pretty much to your own preferences and what coworkers and other people around you use (or on what animal you prefer on the cover of your reference literature:) ).
I don't think that is really true. How cheap and easy is it to make a COM object or Java class in Perl? What if you want
Why I like Python (Score:2, Insightful)
1) Indentation instead of bracing. Yes, I know some people hate it but for me it makes the structure so clear.
2) Object orientation. I did OO with C++. I actually understood it with Python.
3) The smoothest ever integration to low level languages like C. Gotta love it.
4) Easy to learn. Write ab initio code with C/Fortran and never-programmed-before people interface it with Python [fysik.dtu.dk]. Then, grind out those MSc and PhD theses...
Re:Why I like Python (Score:2)
No suprise here:) C++ implimentation of OO is marginal to say the least. The syntax agrees to the letter of OO design, but not the spirit. The result is that most C++ code consists of procedural function dressed up in OO clothing. Many of the advantages of OOD can not be realised in C++ without some ugly code ( uglier then it already is). I learned OOP in the late 80s the hard way, by implementing all of the concepts and all of
Re:Why I like Python (Score:2)
Third party modules (Score:2)
I don't have much experience with other scripting languages, but I've found python to have a lot of very easy to use modules. I've found modules for polynomial fitting to data, large data sets, polygons operations - just out there when I looked for them. And many a useful library in C or C++ has been wrapped in Python. For example, I've written some CAD software (for very specific design operations we do where I work), and needed a way to me
Re:Can anyone (Score:2)
Anyone who can't get use to indentation based block delimiters within a few minuets, ought not be programming in PERL. It demonstrates a complete lack of the programming discipline that is crucial for creating maintainable PE
From the interview (Score:3, Funny)
Guido: I smoked a lot of crack that day.
Re:Dump the significant whitespace! (Score:2, Insightful)
Proper indentation of a program is considered good style in all computer languages, including Perl. It is simply goo
Re:Dump the significant whitespace! (Score:2, Interesting)
In python, it is always 8 spaces. It's considered bad style to use tab. If you use emacs, then emacs will automatically use the correct settings in python mode.
The simple fact is that if you ignore the usual style guidelines for any programming language, there are obvious gotchas. The whitespace gotchas you mention are relatively harmless, as they are caught by the compi
Python vs. the others (Score:3, Interesting)
Many people use Python for tasks they used to do in Perl, but I don't see Python replacing Perl. They serve different purposes, for the most part.
Ruby is also an interesting language, although I don't personally know much about it, except that it aims to be truly OO. Again, slightly different purposes, but I don't think Ruby will ever be very widespread.
Re:Python vs. the others (Score:2)
Could you please explain how PERL and Python serve different purposes?
I'm curious because I use Python for exactly the kind of stuff that I used
to use PERL for. The whole reason I found Python was because I was looking
for a substitute for PERL. After having used Python for some time, I've
discovered that certain things are easier in Python than PERL, and vice
ver
Re:Python vs. the others (Score:3, Interesting)
For one thing, Perl is much more used by UNIX (*BSD and GNU/Linux included) system administrators. Some people think Perl is more in the UNIX spirit than Python.
Python focuses more on OO issues and the Pythonic way. Perl is more versatile in terms of syntax.
Basically, there's some differences in the overall design philosophy.
But you are right. You can easily use Python for things you used to do in Perl and vice versa. But there ar
Re:Python vs. the others (Score:3, Funny)
Difficult and surly? ;-)
Re:Python vs. the others (Score:3, Informative)
Perl is a better shellscript than shellscript. Systems administrators who are tired of dealing with the horrors of shell script like perl. Perl is also great for text manipulation. One can write insanely powerful and terse code for this in perl (like sed on steroids). People who yank a lot of text around (web developers, sys admins) often like perl for this reason.
Python is more of a "programmers language". You can't write insanely t
Is Python still lacking a macro system? (Score:3, Interesting)
I haven't been following python for a long time, though I've used it for a few projects. I know a lot of Lisp-like features such as lambda, eval, etc. have been added to it. (Java's adding a *lot* of features that Dylan has had since its inception, such as keyword arguments... but adding those features to Java makes the language even more ugly.) But what about a real macro system (and I don't mean a C style macro system)? I assume that it would be difficult to incorporate into Python because the Python syntax is not as consistent as the Lisp-family languages.
I assume that Python is still not efficiently compilable either, right? I think Guido was discussing a sealing mechanism for Python similar to Dylan's. Gywdion Dylan can produce code that's as fast as code written in C... and there's still many more optimizations that can be implemented into the compiler.
Re:Is Python still lacking a macro system? (Score:5, Interesting)
You don't need macros since Python is dynamically typed and even functions are first-class objects. At least I know I never missed the C preprocessor after moving to Python
I assume that Python is still not efficiently compilable either, right?
Not quite. There is however a dynamic compiler called Psyco [sourceforge.net], which works by creating static versions of functions at run-time to reduce type-checking.
My own experience is that Psyco makes Python code about 400% faster in real applications. Still an order of magnitude worse than C, but comparable to or better than other languages when it comes to tasks that Python used to do significantly slower.
Re:Is Python still lacking a macro system? (Score:2, Informative)
> typed and even functions are first-class objects.
You don't even know what you are missing.
Lisp and Dylan are dynamically typed with functions as first class objects. However those features are orthogonal to a true macro system... They're not related. A true macro system allows a capable programmer to extend the language itself. Need a new control struct to lock a resource and then automatically unlock it at the end of the block of code? W
Re:Is Python still lacking a macro system? (Score:2)
Not necessarily a good solution, but it might work.
Not necessarily a bad one. (Score:2)
The only difference I think it would have is that it would run at execution time, not compile time. But I'm sure that a not too far away future version of Python will do that...
Re:Is Python still lacking a macro system? (Score:5, Insightful)
Macros would indeed be more difficult to implement in Python, because data and code are not as interchangable as in Lisp (e.g., (car 1 2) being code, '(car 1 2) being data). Macro-like manipulations of Python code would be rather difficult. But there has been discussions about ways of achieving the same flexibility without quite so much generality.
In a related example, some people feel that code blocks, ala Ruby or Smalltalk, are the right way to do control structures. Indeed they are very general. Python instead has developed notions of iteration, generation, and the use of first-class functions, and together they are all quite general as well -- you can do what you need to do. While more eclectic than anonymous functions/lambdas/closures, they are arguably more transparent -- you don't know what a function might do with a code block, and it can greatly effect surrounding code.
So it is with macros -- they are extremely general, and can do unexpected and magic things, (which is not in fitting with core Python principals). As Python grows alternatives, more things need to be built into the languages, but the result is a set of predictable and well-known idioms. Python is a full language, not the basis for other languages, as Lisp can become.
As far as performance, there are a number of things like Psyco, Pyrex, Numeric, and Weave/SciPy, which can handle performance problems (noting that in most application performance is not a problem). The result is again somewhat eclectic, but pragmatic. There's a wide variety of ways to optimize a Python program, many of which are just normal programming optimization (caching, making a process persistent, lazy loading, etc), as well as Python modules written in C or other compiled languages (potentially aided by things like SWIG, Pyrex, or ctypes)
Re:Is Python still lacking a macro system? (Score:2)
Java is adding keyword arguments? Any pointers for that? How does it work with
Re:Is Python still lacking a macro system? (Score:2)
The ICFP competitions for the last few years make an interesting testing ground. While not large scale developments in the grand scheme of things, the requirements are non-trivial and well-specified. There have been entries in many languages, and performance comparisons can
Favorite quote (Score:2, Interesting)
This is mine (Score:3, Interesting)
GvR: That's a deep philosophical question. I'm optimistic about that in theory.
[...]
Given that I believe everybody can learn to read and write, given the right education and circumstances--obviously if your parents have no money and you're sent to work when you're seven ye
Python is great. (Score:5, Informative)
My experiences (Score:3, Interesting)
I've been a Python user myself and I find it quite remarkable how it has evolved since its 1.5.2 to the pointer where they are now 2.3. More and more (interesting) software is being written for it. But evenly important is the code base of Python. It's C implementation is very clean written and very easy to use so one can write extension modules very fast.
Why python rules (Score:3, Informative)
Re:Why python rules (Score:2)
GPL (Score:2)
WTF? The GPL didn't exist in 1991? I guess I was hallucinating when I was using GNU Emacs and GCC in the 80s.
Inaccuracy about GPL (Score:3, Informative)
van Rossum :
parent poster (Slothrup) :
Yes, I was also surprised at this large factual error.
GPL Version 2 [fsf.org] : Jun
Please change "Von" to "Van" (Score:2, Informative)
"Von" is the German version. Dutch people don't like to be taken for Germans, for historical reasons..
My favorite quote from the article (Score:3, Funny)
GvR: ...I do it myself by staying where I am and giving keynotes at conferences and making my personal life the subject of discussions on Slashdot. ...
ORN: Perhaps they should get lives of their own instead of discussing yours?
I think he's talking about us...Great for the occasional programmer (Score:4, Interesting)
I don't get to program much, since I have a day job, and to make matters worse, my formal training with computers was brief. Basically, I learned Python on public transport, communiting to and from work (the Python Cookbook causes people to turn their heads, by the way). I tried learning Java at one point, but the problem is that there are too many details and formalisms that you have to remember to even get anything off the ground.
Not so with Python. Basically, you just write what you want to code. Want to know if there are characters in a string?
(This is new in Python 2.3, and I can't get the indentation to work here). Fantastically intuitive.
The only "problem" is the way the library keeps growing from release to release: Something that you had to code yourself a while back suddenly is a trivial feature. More of an embarrassment of riches than a real problem, but it does make you feel like a fool sometimes. "Why code that socket server? Just use..."
One other nice thing about learning Python is how amazingly friendly and helpful their tutor list [python.org] is. I've asked some amazingly stupid questions in my time, and they have been very gentle and kind.
Re:Welcome to our Overlords (Score:2)
Re:Welcome to our Overlords (Score:2)
Re:New processors (Score:2, Informative)
Re:extensible AI game programming inputs? (Score:2)
PHP: Capable != Appropriate (Score:3, Insightful)
A more appropriate introduction for this
Re:Fool! (Score:3, Funny)
Re:YAPLWDN (Score:2)