Given Python's limited lambda implementation and Guido's distaste for FP I find it odd that Python should be chosen to teach SICP let alone replace Scheme as a teaching language.
There's a lot of pressure to teach languages that are widely used in industry, which is why so many students come out of university knowing mostly Java. There's also a lot of bias against "old" languages, and for newer, trendy languages.
Teaching SICP in Python is just a further development of that trend.
Software engineering is a very trend-following, path of least resistance, bandwagon-jumping profession. If "everyone" is using language X, that's where most engineers (and managers) want to be. Universities are just satisfying that need.
It's a wonder that Scheme lasted in universities as long as it did. It'll be interesting to see how long Python lasts.
There's always Clojure. Best of both worlds, i.e. Scheme-ish with Java host. We had a SICP Clojure group here in London last year and I think someone has written an adaptation of SICP in Clojure. If it was any other text I'd have nothing to say but SICP without the Scheme/Lisp doesn't make sense. If universities choosing Python or Java as their teaching language they should also switch to texts based on OOP.
Why doesn't it make sense without any LISP? I read only the first chapters and found the concept of composition immediately applicable in C and as a C programmer I would write the same way in python, probably.
Remember, all of those "old" languages, when they became notable or influential, were younger than Python is now.
Scheme, when SICP was written, was only 15 years old. It was young and trendy at the time.
C was less than 20 years old when I learned is as part of a required course for my CS degree. I've no doubt that part of the reason was that it was widely used in industry.
C++ was the trendy thing by the time I left school. It was less than 10 years old.
Perl was 10-15 years old when it was used as the "Swiss Army chainsaw" for a lot of the first era of web development.
While this appears to solidify your observation that software engineering is very trend-following, I listed them to point out that Python seems to be the oldest language when it made the jump. It's surely older than most of the students and even TAs for the course.
Python has been a common teaching language for at least a decade now, it's just that this particular course has now switched to it as well. Still took 15 years for it to get that momentum, though.
You won't see a CS course taught in Go or Rust anytime soon.
Lambdas are anonymous functions so an inner def is not the same thing. The fact that you have to "adapt" Python to get non-crippled lambdas suggests it should have been the last choice for teaching a text like SICP.
The reason lambdas are powerful -- one of the only reasons -- is because it's a closure. The fact that you can reference variables outside of the function is the power, not whether it has a name. A label is just a convenience. (Or in this case, an inconvenience.)
If my understanding is flawed, I'd like it to be corrected, though.
Higher-order functions (funargs) do not equal first-class functions (lambdas). It happens to be that any language which supports first-class function must also support higher-order functions, but the reverse is not necessarily true.
That does not match my understanding of first class functions, nor Wikipedia's.[1] Python's inner defs are not anonymous functions (which is what people usually mean by lambdas) but they are definitely first class - they can be returned from a function, stored in a data structure and so on. I agree with the grandparent that the need to label the closure is just an inconvenience, not a disqualification.
You can't have anonymous lambdas that aren't first class (how would you reference them?) but you can have first class functions that are not technically anonymous.
From TFWikipedia: "Some programming language theorists require support for anonymous functions (function literals) as well."
I suppose I wasn't aware that that wasn't a universal requirement, but count me in with that group. I think it's useful to make a distinction between "higher-order" and "first-class" for this very reason (i.e., we can talk about languages that do make a distinction without resorting to overloaded terms).
I mean, consider a language where this is the case:
> "hello," .. " world"
==> "hello, world"
> 2 + 2
==> SYNTAX ERROR
> def a = 2
==> #<number "a">
> a + a
==> 4
Would you consider such a language to have first-class integers?
Sort of on a tangent, but while I'm reminded of it: as far as Python's "lambdas" go, they're brutally gimped compared to Python's notion of a function, since what is allowed (and even required) of a function body in Python is much different than what is allowed of a "lambda" body.
It's no secret that Guido has a little bit of a distaste for functional paradigms. From the man himself:
"About 12 years ago, Python aquired lambda, reduce(), filter() and map(), courtesy of (I believe) a Lisp hacker who missed them and submitted working patches. But, despite of the PR value, I think these features should be cut from Python 3000."
Teaching SICP in Python is just a further development of that trend.
Software engineering is a very trend-following, path of least resistance, bandwagon-jumping profession. If "everyone" is using language X, that's where most engineers (and managers) want to be. Universities are just satisfying that need.
It's a wonder that Scheme lasted in universities as long as it did. It'll be interesting to see how long Python lasts.