×òî äàëüøå?

Ìåëî÷è è ïîä÷èñòêà

• eval() è exec(), ïîëíàÿ âåðñèÿ (simple_stmts.html, functions.html, functions.html)

• ?TypeError: media_is_eligible() takes at least 2 arguments (2 given)?

• ?

Âîïðîñû áûñòðîäåéñòâèÿ

• 1 ms vs. 1 ?s
• Áûñòðîäåéñòâèå è ÇÁ×
• Áûñòðîäåéñòâèå è âû÷èñëèòåëüíàÿ ñëîæíîñòü
• Áûñòðîäåéñòâèå è äçåí Python (ñì. äàëåå)
• Äåéñòâèòåëüíûå ñëó÷àè ïîòåðè áûñòðîäåéñòâèÿ

Python Patterns - An Optimization Anecdote (äîâîëüíî ñòàðîå ýññå Ãâèäî, çäåñü îí åùå ëþáèë reduce() ):

• Rule number one: only optimize when there is a proven speed bottleneck. Only optimize the innermost loop. (This rule is independent of Python, but it doesn't hurt repeating it, since it can save a lot of work. )

• Small is beautiful. Given Python's hefty charges for bytecode instructions and variable look-up, it rarely pays off to add extra tests to save a little bit of work.

• Use intrinsic operations. An implied loop in map() is faster than an explicit for loop; a while loop with an explicit loop counter is even slower.

• Avoid calling functions written in Python in your inner loop. This includes lambdas. In-lining the inner loop can save a lot of time.
• Local variables are faster than globals; if you use a global constant in a loop, copy it to a local variable before the loop. And in Python, function names (global or built-in) are also global constants!

• Try to use map(), filter() or reduce() to replace an explicit for loop, but only if you can use a built-in function: map with a built-in function beats for loop, but a for loop with in-line code beats map with a lambda function!

• Check your algorithms for quadratic behavior. But notice that a more complex algorithm only pays off for large N - for small N, the complexity doesn't pay off. In our case, 256 turned out to be small enough that the simpler version was still a tad faster. Your mileage may vary - this is worth investigating.

• And last but not least: collect data. Python's excellent profile module can quickly show the bottleneck in your code. if you're considering different versions of an algorithm, test it in a tight loop using the time.clock() function.

Ðàçáîð êàêèõ-òî çàäà÷?

Äçåí Python

import this:

• The Zen of Python, by Tim Peters (structured by FrBrGeorge CO)

  1. Beautiful is better than ugly.
  2. Explicit is better than implicit.
  3. Simple is better than complex.
     • Complex is better than complicated.
  4. Flat is better than nested.
  5. Sparse is better than dense.
  6. Readability counts.
  7. Special cases aren't special enough to break the rules.
     • Although practicality beats purity.
  8. Errors should never pass silently.
     • Unless explicitly silenced.
  9. In the face of ambiguity, refuse the temptation to guess.
  10. There should be one ? and preferably only one ? obvious way to do it.
      • Although that way may not be obvious at first unless you're Dutch.
  11. Now is better than never.

      • Although never is often better than right now.

  12. If the implementation is hard to explain, it's a bad idea.

      • If the implementation is easy to explain, it may be a good idea.

  13. Namespaces are one honking great idea -- let's do more of those!

Äàëüíåéøåå äâèæåíèå

• Èçó÷åíèå àëãîðèòìè÷åñêîãî ïðîãðàììèðîâàíèÿ íà Python:

  • Ïðîåêò ?Interactivepython?: Problem Solving with Algorithms and Data Structures è ïåðåâîä (!): http://aliev.me/runestone/ (via Èâàí Ìîðîçîâ)

• Èíñòðóìåíòàëüíàÿ ðàçðàáîòêà è ïðîìûøëåííîå ïðîãðàììèðîâàíèå
• ?Àêàäåìè÷åñêîå? ïðîãðàììèðîâàíèå
• Ñàì Python è åãî ðåàëèçàöèè

EE: import antigravity