there is a small Christmas present for those who use PyCLIPS: I finally started working on a 2.0 release. I preferred to start a major version switch because the 2.0 release will generally be *incompatible* with the previous one. The relevant change is that PyCLIPS 2.0 will *not* support most of the top-level functions and classes, and every "engine" will have to be run in a specifically created environment (the Environment class). While this may seem very drastic at first sight, in my opinion this will not have such an impact. Let's see why:
- from a memory management point of view, things don't change that much: in PyCLIPS 1.0 an environment was created anyway, the one (initially) devoted to top level operations;
- as a matter of "typing effort", it will not be so different (from the user perspective) to initialize an environment at the start (for instance, with a global statement such as "e = clips.Environment()", to make "e" visible to an entire module or script) and then write "e.FunctionOrClass(some, params, ...)" instead of "clips.FunctionOrClass(some, params, ...)".
I will try to provide a "compatibility module", that is, a wrapper that will make old PyCLIPS code run unmodified at the start (except for the "import" line, maybe): it is actually possible using statements such as "import clips as pyclips; clips = pyclips.Environment()" and some more operations to bring the remaining top level objects at the new "clips" level. It might be useful, though, to start writing code the "2.0 way": PyCLIPS 1.0 will run 2.0 code unmodified at the price of an unused Environment.
Of course there are some functions and objects that remain at the top level (memory management, external function creation, I/O streams), and some others are definitely gone: the functions to "set current environment" aren't present anymore, as there is no concept of "current environment" in PyCLIPS 2.0.
The reasons why I decided to make this move is that, while the drawbacks are quite limited, there are at least two big advantages: the first advantage consists in the removal of many complicated procedures and tests (for instance, the on-the-fly creation of the high level companion module, that would lead to errors and forced me to use a lot of "meta-code" just for translation purposes, as well as the low-level test for aliased environments). The second advantage is in size and load time for the module itself. Moreover, as a side effect (I understand :-) that this is an advantage just for me) the code is more maintainable. In my opinion this change also removes the implicit complexity that arises from the existence of top level functions and companion functions, by actually putting apart the whole concepts themselves.
The current test suite completely passes with PyCLIPS 2.0 with little modifications, which just reflect the environment-based nature of this PyCLIPS version: if you examine the test code, you'll notice that I just commented out a test based on SetCurrentEnvironment and associates, and instead of using "clips" and a created environment for tests, I just used two separate environments - leaving the rest of the code alone.
Next steps are to make PyCLIPS 2.0 compatible with Python 3.0, and to rewrite the documentation in order to reflect the changes. I'll use the new style (ReST and so on) for the documentation, in order to create a manual that is easier to use. For now, consider that the documentation is mostly still valid, apart from the fact that functions do not apply to the top level but just to created environments.
There is already a working revision in the pyclips-2.0 branch in the SVN repository. You can grab it using the following command:
(I prefer "export" instead of "checkout" because it just fetches code and no repository files and directories). In a few days I will release an official beta version in the file release area. For now, enjoy experimenting with the SVN code.
Log in to post a comment.