So here's my idea: an anti-framework. I'm interested in the idea of building a framework, because it would be nice to provide a nice, standard set of libraries and modules to work in (much like the standard library, but extended to cover the scientific domain). However, the problem with building frameworks is basically the competing standards problem.
So here's my new idea. An anti-framework, build out of a relatively small number of de facto standard scientific components for Python (like numpy, scipy, matplotlib, I imagine there are some others) and call it something zingy. Any framework or environment which passes its unit tests in the anti-framework is then "zingy-name-compatible". You don't run with a zingy-name framework, because lots of people need more than what's in the standard framework for all sorts of reasons. It's perfectly okay for some-other-framework to extend zingy-name-framework, so long as it remains backwards-compatible with zingy-name framework.
Then, anyone building a relevant application, framework, or whatever can be zingy-compatible if they will support any tool written only using the zingy core libraries.
3 comments:
I realise some of that didn't make perfect sense. I meant that extending frameworks would guarantee to pass any tests for code written solely using the zingy-name core framework, not the other way around. The extended frameworks could include additional libraries or modules, but would not break compatibility.
So, how about doing a scientific Python distribution type thingy? Like the EPD (Enthought Python Distribution) or Python(x,y), only that you're going to collect a set of useful modules/libraries with their version numbers and give it a code name & version number to identify the "standardised set" of tools.
You might also as well just define whatever is shipped in the tool collection of a current Ubuntu the canonical default ... ;-)
Post a Comment