New Features

• Support for new compiler: Microsoft Visual C++.

  You can now use Visual Studio 2008 or Visual Studio 2010 for compiling under Windows.

• Support for NetBSD.

  Nuitka works for at least NetBSD 6.0, older versions may or may not work. This required fixing bugs in the generic "fibers" implementation.

• Support for Python3 under Windows too.

  Nuitka uses Scons to build the generated C++ files. Unfortunately it requires Python2 to execute, which is not readily available to call from Python3. It now guesses the default installation paths of CPython 2.7 or CPython 2.6 and it will use it for running Scons instead. You have to install it to" C:Python26" or "C:Python27" for Nuitka to be able to find it.

• Enhanced Python 3.3 compatibility.

  The support the newest version of Python has been extended, improving compatibility for many minor corner cases.

• Added warning when a user compiles a module and executes it immediately when that references __name__.

  Because very likely the intention was to create an executable. And esp. if there is code like this:

  if __name__ == "__main__":
     main()
  

  In module mode, Nuitka will optimize it away, and nothing will happen on execution. This is because the command

  nuitka --execute module
  

  is behavioral more like

  python -c "import module"

  and that was a trap for new users.

• All Linux architectures are now supported. Due to changes in how evaluation order is enforced, we don't have to implement for specific architectures anymore.

Bug Fixes

• Dictionary creation was not fully compatible.

  As revealed by using Nuitka with CPython3.3, the order in which dictionaries are to be populated needs to be reversed, i.e. CPython adds the last item first. We didn't observe this before, and it's likely the new dictionary implementation that finds it.

  Given that hash randomization makes dictionaries item order undetermined anyway, this is more an issue of testing.

• Evaluation order for arguments of calls was not effectively enforced. It is now done in a standards compliant and therefore fully portable way. The compilers and platforms so far supported were not affected, but the newly supported Visual Studio C++ compiler was.

• Using a __future__ import inside a function was giving an assertion, instead of the proper syntax error.

• Python3: Do not set the attributes sys.exc_type, sys.exc_value, sys.exc_traceback.

• Python3: Annotations of function worked only as long as their definition was not referring to local variables.

New Optimization

• Calls with no positional arguments are now using the faster call methods.

  The generated C++ code was using the () constant at call site, when doing calls that use no positional arguments, which is of course useless.

• For Windows now uses OS "Fibers" for Nuitka "Fibers".

  Using threads for fibers was causing only overhead and with this API, MSVC had less issues too.

Organizational

• Accepting Donations via Paypal, please support funding travels, website, etc.
• The User Manual has been updated with new content. We now do support Visual Studio, documented the required LLVM version for clang, Win64 and modules may include modules too, etc. Lots of information was no longer accurate and has been updated.
• The Changelog has been improved for consistency, wordings, and styles.
• Nuitka is now available on the social code platforms as well
  • Bitbucket
  • Github
  • Gitorious
  • Google Code
• Removed "clean-up.sh", which is practically useless, as tests now clean up after themselves reasonably, and with git clean -dfx working better.
• Removed "create-environment.sh" script, which was only setting the PATH variable, which is not necessary.
• Added check-with-pylint --emacs option to make output its work with Emacs compilation mode, to allow easier fixing of warnings from PyLint.
• Documentation is formatted for 80 columns now, source code will gradually aim at it too. So far 90 columns were used, and up to 100 tolerated.

Cleanups

• Removed useless manifest and resource file creation under Windows.

  Turns out this is no longer needed at all. Either CPython, MinGW, or Windows improved to no longer need it.

• PyLint massive cleanups and annotations bringing down the number of warnings by a lot.

• Avoid use of strings and built-ins as run time pre-computed constants that are not needed for specific Python versions, or Nuitka modes.

• Do not track needed tuple, list, and dict creation code variants in context, but e.g. in nuitka.codegen.TupleCodes module instead.

• Introduced an "internal" module to host the complex call helper functions, instead of just adding it to any module that first uses it.

New Tests

• Added basic tests for order evaluation, where there currently were None.
• Added support for "2to3" execution under Windows too, so we can run tests for Python3 installations too.

Summary

The release is clearly major step ahead. The new platform support triggered a whole range of improvements, and means this is truly complete now.

Also there is very much polish in this release, reducing the number of warnings, updated documentation, the only thing really missing is visible progress with optimization.

New Features

• Support for new compiler: Microsoft Visual C++.

  You can now use Visual Studio 2008 or Visual Studio 2010 for compiling under Windows.

• Support for NetBSD.

  Nuitka works for at least NetBSD 6.0, older versions may or may not work. This required fixing bugs in the generic "fibers" implementation.

• Support for Python3 under Windows too.

  Nuitka uses Scons to build the generated C++ files. Unfortunately it requires Python2 to execute, which is not readily available to call from Python3. It now guesses the default installation paths of CPython 2.7 or CPython 2.6 and it will use it for running Scons instead. You have to install it to" C:Python26" or "C:Python27" for Nuitka to be able to find it.

• Enhanced Python 3.3 compatibility.

  The support the newest version of Python has been extended, improving compatibility for many minor corner cases.

• Added warning when a user compiles a module and executes it immediately when that references __name__.

  Because very likely the intention was to create an executable. And esp. if there is code like this:

  if __name__ == "__main__":
     main()
  

  In module mode, Nuitka will optimize it away, and nothing will happen on execution. This is because the command

  nuitka --execute module
  

  is behavioral more like

  python -c "import module"

  and that was a trap for new users.

• All Linux architectures are now supported. Due to changes in how evaluation order is enforced, we don't have to implement for specific architectures anymore.

Bug Fixes

• Dictionary creation was not fully compatible.

  As revealed by using Nuitka with CPython3.3, the order in which dictionaries are to be populated needs to be reversed, i.e. CPython adds the last item first. We didn't observe this before, and it's likely the new dictionary implementation that finds it.

  Given that hash randomization makes dictionaries item order undetermined anyway, this is more an issue of testing.

• Evaluation order for arguments of calls was not effectively enforced. It is now done in a standards compliant and therefore fully portable way. The compilers and platforms so far supported were not affected, but the newly supported Visual Studio C++ compiler was.

• Using a __future__ import inside a function was giving an assertion, instead of the proper syntax error.

• Python3: Do not set the attributes sys.exc_type, sys.exc_value, sys.exc_traceback.

• Python3: Annotations of function worked only as long as their definition was not referring to local variables.

New Optimization

• Calls with no positional arguments are now using the faster call methods.

  The generated C++ code was using the () constant at call site, when doing calls that use no positional arguments, which is of course useless.

• For Windows now uses OS "Fibers" for Nuitka "Fibers".

  Using threads for fibers was causing only overhead and with this API, MSVC had less issues too.

Organizational

• Accepting Donations via Paypal, please support funding travels, website, etc.
• The User Manual has been updated with new content. We now do support Visual Studio, documented the required LLVM version for clang, Win64 and modules may include modules too, etc. Lots of information was no longer accurate and has been updated.
• The Changelog has been improved for consistency, wordings, and styles.
• Nuitka is now available on the social code platforms as well
  • Bitbucket
  • Github
  • Gitorious
  • Google Code
• Removed "clean-up.sh", which is practically useless, as tests now clean up after themselves reasonably, and with git clean -dfx working better.
• Removed "create-environment.sh" script, which was only setting the PATH variable, which is not necessary.
• Added check-with-pylint --emacs option to make output its work with Emacs compilation mode, to allow easier fixing of warnings from PyLint.
• Documentation is formatted for 80 columns now, source code will gradually aim at it too. So far 90 columns were used, and up to 100 tolerated.

Cleanups

• Removed useless manifest and resource file creation under Windows.

  Turns out this is no longer needed at all. Either CPython, MinGW, or Windows improved to no longer need it.

• PyLint massive cleanups and annotations bringing down the number of warnings by a lot.

• Avoid use of strings and built-ins as run time pre-computed constants that are not needed for specific Python versions, or Nuitka modes.

• Do not track needed tuple, list, and dict creation code variants in context, but e.g. in nuitka.codegen.TupleCodes module instead.

• Introduced an "internal" module to host the complex call helper functions, instead of just adding it to any module that first uses it.

New Tests

• Added basic tests for order evaluation, where there currently were None.
• Added support for "2to3" execution under Windows too, so we can run tests for Python3 installations too.

Summary

The release is clearly major step ahead. The new platform support triggered a whole range of improvements, and means this is truly complete now.

Also there is very much polish in this release, reducing the number of warnings, updated documentation, the only thing really missing is visible progress with optimization.

Principle philosophy: a way to discuss our rules and beliefs that govern our actions. He tells it from his personal experience.

His parents wanted to raise him as a good person. So they thought him good principles (like don't be a quitter, don't steal, etc). This is quite black/white though. We are all more gray/gray.

What about the question "how can I be a good programmer"? Programmers use logic, which sounds black/white again: write tests, don't repeat yourself. Sigh.

Talking about things like this is impossible without Immanuel Kant. He differentiates between reason and instinct. If "be happy" were our life goal, we'd just follow our instincts. So what is reason for, then, apart for doing good? Reason has to do with moral. There are three ways of looking at "doing good":

• Duty. Good things can come from duty. Duty can also lead to non-good things, though. Hm, so this is not it.
• Make a difference between the goal and the outcome. The outcome might be bad even though the goal could be worthy.
• Universal lawfullness. Only do something if you know that everybody thinks it is a good idea.

Does this help with a question like "is testing good"?

Gandhi said that a man is the sum of his actions.

In a sense we are the sum of our experiences. So increase the amount of experience that you have. Either have the experiences yourself, or share them like on this conference. Everything looks different from the trenches: learn from eachother.

Some lessons he learned from a little baseball league experience (where he sucked) as a kid:

• Swing for the fences. Aim for a home run. It allows you take great risks (because you have great goals). It motivates you.
• Set reasonable goals, too. Incremental intermediate goals. Those intermediate goals help you progress.
• You suck... and that's totally OK. You're not good at everything. It gives you a different perspective. And you can still give it your best. Also to that almost-unused old project that you get a bug report for.

Some take-aways:

• Build a strong foundation of principles.
• One size doesn't fit all
• Learn from your experiences and share them.
• Build a great network.
• Ask all the right questions.

Principle philosophy: a way to discuss our rules and beliefs that govern our actions. He tells it from his personal experience.

His parents wanted to raise him as a good person. So they thought him good principles (like don't be a quitter, don't steal, etc). This is quite black/white though. We are all more gray/gray.

What about the question "how can I be a good programmer"? Programmers use logic, which sounds black/white again: write tests, don't repeat yourself. Sigh.

Talking about things like this is impossible without Immanuel Kant. He differentiates between reason and instinct. If "be happy" were our life goal, we'd just follow our instincts. So what is reason for, then, apart for doing good? Reason has to do with moral. There are three ways of looking at "doing good":

• Duty. Good things can come from duty. Duty can also lead to non-good things, though. Hm, so this is not it.
• Make a difference between the goal and the outcome. The outcome might be bad even though the goal could be worthy.
• Universal lawfullness. Only do something if you know that everybody thinks it is a good idea.

Does this help with a question like "is testing good"?

Gandhi said that a man is the sum of his actions.

In a sense we are the sum of our experiences. So increase the amount of experience that you have. Either have the experiences yourself, or share them like on this conference. Everything looks different from the trenches: learn from eachother.

Some lessons he learned from a little baseball league experience (where he sucked) as a kid:

• Swing for the fences. Aim for a home run. It allows you take great risks (because you have great goals). It motivates you.
• Set reasonable goals, too. Incremental intermediate goals. Those intermediate goals help you progress.
• You suck... and that's totally OK. You're not good at everything. It gives you a different perspective. And you can still give it your best. Also to that almost-unused old project that you get a bug report for.

Some take-aways:

• Build a strong foundation of principles.
• One size doesn't fit all
• Learn from your experiences and share them.
• Build a great network.
• Ask all the right questions.

What is PyPy?

PyPy is a very compliant Python interpreter, almost a drop-in replacement for CPython 2.7. It's fast (pypy 2.0 and cpython 2.7.3 performance comparison) due to its integrated tracing JIT compiler.

This release supports x86 machines running Linux 32/64, Mac OS X 64 or Windows 32. Support for ARM is progressing but not bug-free yet.

Highlights

• fix an occasional crash in the JIT that ends in RPython Fatal error: NotImplementedError.
• id(x) is now always a positive number (except on int/float/long/complex). This fixes an issue in _sqlite.py (mostly for 32-bit Linux).
• fix crashes of callback-from-C-functions (with cffi) when used together with Stackless features, on asmgcc (i.e. Linux only). Now gevent should work better.
• work around an eventlet issue with socket._decref_socketios().

Cheers, arigo et. al. for the PyPy team

What is PyPy?

PyPy is a very compliant Python interpreter, almost a drop-in replacement for CPython 2.7. It's fast (pypy 2.0 and cpython 2.7.3 performance comparison) due to its integrated tracing JIT compiler.

This release supports x86 machines running Linux 32/64, Mac OS X 64 or Windows 32. Support for ARM is progressing but not bug-free yet.

Highlights

• fix an occasional crash in the JIT that ends in RPython Fatal error: NotImplementedError.
• id(x) is now always a positive number (except on int/float/long/complex). This fixes an issue in _sqlite.py (mostly for 32-bit Linux).
• fix crashes of callback-from-C-functions (with cffi) when used together with Stackless features, on asmgcc (i.e. Linux only). Now gevent should work better.
• work around an eventlet issue with socket._decref_socketios().

Cheers, arigo et. al. for the PyPy team

A plane flew over (noisily) at the start of his presentation. He put our work in perspective by saying that that was a 80 ton plane and that we're just building websites :-)

A plane flew over (noisily) at the start of his presentation. He put our work in perspective by saying that that was a 80 ton plane and that we're just building websites :-)

He shows us three kinds of (more or less) open source projects.

He shows us three kinds of (more or less) open source projects.

Metaclasses are a handy feature of Python and Django makes good use of them.

When you create certain kinds of classes in Django, a metaclass will do something to the class before it is created. For forms, the various attributes of the class are converted into a base_fields dictionary on the class.

Similarly, a subclass of Model also fires up a metaclass that does some registering. A foreignkey to another model adds a relation back on that other model, for instance.

As a recap, a class is something that can be instantiated into an object. It can have an __init__() method that does something upon instantiation. type(your_instance) will return the class.

Did you know that you can create classes dynamically? See for yourself:

>>> name = 'ExampleClass'
>>> bases = (object,)
>>> attrs = {'__init__': lambda self: print('Hello from __init__')}
>>> ExampleClass = type(name, bases, attrs)
>>> example = ExampleClass()
Hello From __init__
>>> type(example)
<class '__console__.ExampleClass'>

So... we can actually control how classes are created! You could create a create_class() method that calls type but that modifies, for instance, the name. Or we could take all the attributes and add them to a base_fields dictionary on the instance. Hey, that's what we saw in the first Django form example!

Now, what is type exactly? It is a class that creates classes.

This also means we can subclass it! The most useful thing to override in our subclass is the __new__() method. The __init__() method creates instances from the class, the __new__() creates classes. So again we can modify the name and/or the attributes.

How do you use it in practice? Normally you'd set a __metaclass__ attribute on a class. This tells python to use that metaclass for creating the class. The same for subclasses. This is how our Django form classes use the metaclass specified in Django's base Form class.

Django uses metaclasses in five places: admin media, models, forms, formfields, form widgets. Grep for metaclass in your local django source code once to get a better feel for how Django uses it.

Note on python 3: it uses a slightly different syntax for specifying metaclasses. So Django 1.5 uses six to support both ways in a single codebase.

Warning: don't overuse metaclasses. They can make code difficult to debug and follow. Use Django as a good example of how to use metaclasses. Django saves you a lot of work by using metaclasses in a few locations.

See https://github.com/inglesp/Metaclasses

Nice way of giving a presentation, btw. Some sort of semi-interactive python prompt. The software is online at https://github.com/inglesp/prescons

Metaclasses are a handy feature of Python and Django makes good use of them.

When you create certain kinds of classes in Django, a metaclass will do something to the class before it is created. For forms, the various attributes of the class are converted into a base_fields dictionary on the class.

Similarly, a subclass of Model also fires up a metaclass that does some registering. A foreignkey to another model adds a relation back on that other model, for instance.

As a recap, a class is something that can be instantiated into an object. It can have an __init__() method that does something upon instantiation. type(your_instance) will return the class.

Did you know that you can create classes dynamically? See for yourself:

>>> name = 'ExampleClass'
>>> bases = (object,)
>>> attrs = {'__init__': lambda self: print('Hello from __init__')}
>>> ExampleClass = type(name, bases, attrs)
>>> example = ExampleClass()
Hello From __init__
>>> type(example)
<class '__console__.ExampleClass'>

So... we can actually control how classes are created! You could create a create_class() method that calls type but that modifies, for instance, the name. Or we could take all the attributes and add them to a base_fields dictionary on the instance. Hey, that's what we saw in the first Django form example!

Now, what is type exactly? It is a class that creates classes.

This also means we can subclass it! The most useful thing to override in our subclass is the __new__() method. The __init__() method creates instances from the class, the __new__() creates classes. So again we can modify the name and/or the attributes.

How do you use it in practice? Normally you'd set a __metaclass__ attribute on a class. This tells python to use that metaclass for creating the class. The same for subclasses. This is how our Django form classes use the metaclass specified in Django's base Form class.

Django uses metaclasses in five places: admin media, models, forms, formfields, form widgets. Grep for metaclass in your local django source code once to get a better feel for how Django uses it.

Note on python 3: it uses a slightly different syntax for specifying metaclasses. So Django 1.5 uses six to support both ways in a single codebase.

Warning: don't overuse metaclasses. They can make code difficult to debug and follow. Use Django as a good example of how to use metaclasses. Django saves you a lot of work by using metaclasses in a few locations.

See https://github.com/inglesp/Metaclasses

Nice way of giving a presentation, btw. Some sort of semi-interactive python prompt. The software is online at https://github.com/inglesp/prescons

Amjith Ramanujam recently wrote a thread profiler in Python and it was rediculously simple. He works for New Relic, which is all about performance and expecially performance measuring.

Python comes with batteries included, so it also includes a C profiler that works pretty well. But it doesn't work nice for django because the output is so huge. If you use the GUI RunSnakeRun, it is more managable that way.

Additional problem with cProfile: it has about 100% overhead, so you can't run it in production (which they need).

You can do more targeted profiling. For instance in Django. The way a web framework processes requests is normally always in the same way. You can use that during profiling.

There are two important stages: interrupt and inquire.

Interrupt

A statistical profiler looks how often a function is called and by who. For this it needs to interrupt the regular process. You could set an OS-level signal to call your profiler every x miliseconds so that it can do something. It only works in linux, btw. Another way is to create a python background thread that wakes up every x miliseconds. It is cross-platform and mod_wsgi compatible. It is less accurate for CPU tasks and it cannot interrupt C extensions.

Inquire

You can use sys._current_frames() to get yourself the frames ("stack trace") from the current thread. Here you can extract the filename, line number and so of the most interesting frames. He's building a "call tree" structure, mapping how often a function is called, preserving the parent/child relation between functions. The tricky part was visualizing it :-) In the end they did it with d3.js.

There's some 3% overhead in the thread approach, so that's real good. They can switch it on for a type of request and it'll profile the next 100 requests of that type.

Amjith Ramanujam recently wrote a thread profiler in Python and it was rediculously simple. He works for New Relic, which is all about performance and expecially performance measuring.

Python comes with batteries included, so it also includes a C profiler that works pretty well. But it doesn't work nice for django because the output is so huge. If you use the GUI RunSnakeRun, it is more managable that way.

Additional problem with cProfile: it has about 100% overhead, so you can't run it in production (which they need).

You can do more targeted profiling. For instance in Django. The way a web framework processes requests is normally always in the same way. You can use that during profiling.

There are two important stages: interrupt and inquire.

Interrupt

A statistical profiler looks how often a function is called and by who. For this it needs to interrupt the regular process. You could set an OS-level signal to call your profiler every x miliseconds so that it can do something. It only works in linux, btw. Another way is to create a python background thread that wakes up every x miliseconds. It is cross-platform and mod_wsgi compatible. It is less accurate for CPU tasks and it cannot interrupt C extensions.

Inquire

You can use sys._current_frames() to get yourself the frames ("stack trace") from the current thread. Here you can extract the filename, line number and so of the most interesting frames. He's building a "call tree" structure, mapping how often a function is called, preserving the parent/child relation between functions. The tricky part was visualizing it :-) In the end they did it with d3.js.

There's some 3% overhead in the thread approach, so that's real good. They can switch it on for a type of request and it'll profile the next 100 requests of that type.

His goal: teach programmers to be more creative.

He's got a love/hate relationship with creativity. The first part of his talk was impossible to summarize. You'll have to watch the video later on :-)

• Artists tell him he's not artistic because he works on developing technical skills.
• Guitarists tell him he's not a real guitarist as he doesn't play in a band. And 'cause he builds his own guitars he's a programmer, not a Real Guitarist.
• Writers tell him he's not a writer because he writes technical books.
• Programmers tell him he's not a programmer because he doesn't work on their project. And by the way, he's a (technical) writer now, so he's not a programmer.

He's not creative enough. Or so the others say. Or he's not acceptable. How to deal with creativity? In a way, you can re-phrase creativity. Programmers are always making something from nothing, right? Isn't that the pinnacle of creativity?

Here are four hypothetical persons:

• Technique, no imagination: a stereotypical programmer.
• Imagination, no technique: stereotypical biz dude.
• No imagination, no technique. Probably doesn't exist.
• Both imagination and technique. Zed's goal.

Zed's imaginative programmer process. Everyone has a process (if they're good), here's the one he proposes to help you be more creative:

• You start with an idea.
• You establish a concept that helps form the idea. It gives your idea clothes.
• Research techniques or tools. Do some research or you'll pay for it later on.
• Refine the concept through composition. So put a box around the vast world of available possibilities. Just mark which features are inside and outside the concept.
• Explore through prototypes. Throw away code or use paper prototypes for instance. This saves you so much time later.
• You make it real.

We are programmers, so we should iterate this process.

He tried this process with http://projectzorn.com/, going through all the stages. And he's probably going to work on it

His goal: teach programmers to be more creative.

He's got a love/hate relationship with creativity. The first part of his talk was impossible to summarize. You'll have to watch the video later on :-)

• Artists tell him he's not artistic because he works on developing technical skills.
• Guitarists tell him he's not a real guitarist as he doesn't play in a band. And 'cause he builds his own guitars he's a programmer, not a Real Guitarist.
• Writers tell him he's not a writer because he writes technical books.
• Programmers tell him he's not a programmer because he doesn't work on their project. And by the way, he's a (technical) writer now, so he's not a programmer.

He's not creative enough. Or so the others say. Or he's not acceptable. How to deal with creativity? In a way, you can re-phrase creativity. Programmers are always making something from nothing, right? Isn't that the pinnacle of creativity?

Here are four hypothetical persons:

• Technique, no imagination: a stereotypical programmer.
• Imagination, no technique: stereotypical biz dude.
• No imagination, no technique. Probably doesn't exist.
• Both imagination and technique. Zed's goal.

Zed's imaginative programmer process. Everyone has a process (if they're good), here's the one he proposes to help you be more creative:

• You start with an idea.
• You establish a concept that helps form the idea. It gives your idea clothes.
• Research techniques or tools. Do some research or you'll pay for it later on.
• Refine the concept through composition. So put a box around the vast world of available possibilities. Just mark which features are inside and outside the concept.
• Explore through prototypes. Throw away code or use paper prototypes for instance. This saves you so much time later.
• You make it real.

We are programmers, so we should iterate this process.

He tried this process with http://projectzorn.com/, going through all the stages. And he's probably going to work on it

Brandon Rhodes mentions Nicolai Kopernik, a famous Polish scientist. He "lifted Earth into Heaven" by his book where he put the sun in the center of our universe instead of Earth. We're no longer at the bottom.

The near-earth environment was pretty well mapped out. 300BC, the size of the spherical earth was already known. Around 100BC the distance to the moon was known.

But what about those planets? They were harder. Stars did move around the sky more or less linearly. But those planets. They seemed to move back and forth a bit. Did they need to have a different model? The sun-centric model was already known, but it didn't catch on. The reason? Medieval science was too emperic: the earth cannot be moving, it seems to stay in place. Throw a ball and it falls down again towards the earth, it doesn't career off into space. The church wasn't totally idiotic by later convicting Galileo: there was just no solid emperical evidence :-)

One of the pieces of evidence that was missing was that there was no observable stellar parralax; visible movement between stars because of earth movement. It was only in 1838 that the instruments were good enough to actually observe parralax. Only then did we figure out how far away the stars were. So it took 200-300 year to get real evidence.

So why did Kopernik trust his theory despite the lack of evidence? Because of beauty. Brandon showed Kopernik's theory as Python code; an algorithm for planet movements. And showed his theory as a code refactoring. The end result was quite simple and nice once you factored out Earth's motion. The code looks nicely ordered.

There's truth in beauty.

Brandon proposes a new term: Kopernican refactoring: making a system simpler by moving something new into the center.

It is so easy to behave according to a rule that's not even really there. You look at a problem in a certain way and you're stuck. Once you put something else in the center, you look at the problem in a different way.

For instance, you can use argparse to generate a help message when you pass --help. You can also do it the other way around: using docopt which generates a parser from your help message! You get a much nicer help message.

So if you're stuck, think of Copernicus and his refactoring.

Brandon Rhodes mentions Nicolai Kopernik, a famous Polish scientist. He "lifted Earth into Heaven" by his book where he put the sun in the center of our universe instead of Earth. We're no longer at the bottom.

The near-earth environment was pretty well mapped out. 300BC, the size of the spherical earth was already known. Around 100BC the distance to the moon was known.

But what about those planets? They were harder. Stars did move around the sky more or less linearly. But those planets. They seemed to move back and forth a bit. Did they need to have a different model? The sun-centric model was already known, but it didn't catch on. The reason? Medieval science was too emperic: the earth cannot be moving, it seems to stay in place. Throw a ball and it falls down again towards the earth, it doesn't career off into space. The church wasn't totally idiotic by later convicting Galileo: there was just no solid emperical evidence :-)

One of the pieces of evidence that was missing was that there was no observable stellar parralax; visible movement between stars because of earth movement. It was only in 1838 that the instruments were good enough to actually observe parralax. Only then did we figure out how far away the stars were. So it took 200-300 year to get real evidence.

So why did Kopernik trust his theory despite the lack of evidence? Because of beauty. Brandon showed Kopernik's theory as Python code; an algorithm for planet movements. And showed his theory as a code refactoring. The end result was quite simple and nice once you factored out Earth's motion. The code looks nicely ordered.

There's truth in beauty.

Brandon proposes a new term: Kopernican refactoring: making a system simpler by moving something new into the center.

It is so easy to behave according to a rule that's not even really there. You look at a problem in a certain way and you're stuck. Once you put something else in the center, you look at the problem in a different way.

For instance, you can use argparse to generate a help message when you pass --help. You can also do it the other way around: using docopt which generates a parser from your help message! You get a much nicer help message.

So if you're stuck, think of Copernicus and his refactoring.