Economists are expected to know how to program, and they do. They just have a tendency to reserve writing programs for complex models and prefer spreadsheets for what they consider "simple" data analysis.
On the point about transcription errors: Using python could have avoided some transcription errors. If the error was in copying a single constant from a source into the program, then in python it might be buried as an unlabeled magic number deep in the source tree, but it also might be labeled as a top level constant identifier. In the former case it would have the same problem as in a spreadsheet, but in the latter, a typo would likely be caught by someone reading over the code at some point. Or if some of the data came in a file format that excel couldn't automatically import, maybe he could have used a python library instead of manually transcribing 50 data points. It's hard to think of a situation where using python would have lead to more transcription errors.
I don't know where this sentiment that economists (who are not trained as programmers) are expected to know computer programming languages comes from.
Both Harvard and Stanford economics degrees do not list Computer Science 101 as a core requirement to graduate.
Compare Stanford's requirements for Economics[1] with Electrical Engineering[2]. The engineering major has core classes including computing and programming. The economics major does not. (Whether or not economics studies should include it (and therefore Stanford is "wrong" in leaving it out) is a separate conversation.)
Since Thomas Piketty is from France, is there a tradition of European schools requiring computer programming language courses in their training?
As for the Python vs Excel comparisons, I say people are overestimating Python's syntax to avoid errors and underestimating Excel's visual spatial grid of cells & near-universal collaboration to also avoid certain classes of errors. For non-programmers, the rows-columns grid displayed visually at all times is almost a perfect 1-to-1 correspondence to their mental model. For Python loops, it takes programmer training to mentally "unroll" loops and see how data is munged. This visual "blindness" in programming languages ends up creating its own class of errors.
I've done programming in MS Excel + Excel macros/VBA, MS Access, Oracle PL/SQL, MS Transact-SQL, C++ Qt, C# ADO.NET/LINQ, Python,etc and I'm not convinced the syntax of programming languages leads to reduced errors. It's just a different class of errors.
On the point about transcription errors: Using python could have avoided some transcription errors. If the error was in copying a single constant from a source into the program, then in python it might be buried as an unlabeled magic number deep in the source tree, but it also might be labeled as a top level constant identifier. In the former case it would have the same problem as in a spreadsheet, but in the latter, a typo would likely be caught by someone reading over the code at some point. Or if some of the data came in a file format that excel couldn't automatically import, maybe he could have used a python library instead of manually transcribing 50 data points. It's hard to think of a situation where using python would have lead to more transcription errors.