metaclass with dynamic creation of properties

Meteclass with dynamic properties creation: Written as helper class for my graph implementation (metaclass for nodes, edges and graph itself).

yet another Observer pattern in python

Observer sniffing a particular attribute from Observable class. This little spy is notified every time watched attribute is changing its value.

Observers are hold in weakref.WeakValueDictionary to avoid crashes in case they would disappear (i.e. being collected and deleted by gc). And here is the source code:

one type list in python

Handy list-like class holding only one type of items.

python traced class

With metaclass programming in python you can easily created a class tracing all updates to its attributes: All objects using Traced metaclass are able to tell you which attributes have been changed. To get list of updated attributes (or keys when using TracedDict or indexes in case of TracedList) just call updated member function. There is only one shortage: attributes defined and set inside __init__ (real instance attributes like instanceAttribute in TracedTest class) will be put into updated list when calling constructor. To avoid this behavior and trace changed during lifetime of object you need at call at ther very last line in constructor self.updated( reset = True ) (or uncomment last line in above example).

multiprocessing process pool again

Final implementation is quite different and much more smart:

And here is the source code:

python multiprocessing handy template with callbacks

Here is a handy implementation of process pool I wrote a few days ago. All workers are created in pool and are running in daemonic mode, reading and executing ProcessTasks, which is made up using any python callable together with callback and exception callback definition.

The process pool is using two queues: first for tasks to be processed and second holding task results for callbacks. It could be executed in daemon mode too, processing results in a separate thread. Once you decide the job is done, you need to call ProcessPool::finalize (or ProcessPool::processAllResults), which is sending dummy assassins (in fact just a True value) to the workers (so they could return from their run method), terminating them once they are not alive any more and closing tasks and results queues. Blah, blah, blah... Code that was published below was kinda buggy. Error-free version can be found here.

Dear Python, can I create global variables in functions or methods?

Yeeee... no. Global variables in python are global on module level only. So, the answer is noooo... yes, you can.

Having a problem of a sub-process that has to execute just a callable (function, lambda or class with __call__ defined), and following DRY, I've put common functionality in base class and then created a set of children. As this code is part of much bigger project, DIRAC, where have to follow conventions and use everywhere a set of of global variables (references to services, clients, some global functions, etc.). Of course I was going to import them in a base class, but then what?

Globals are visible at the module level, so if I put them to base class, I would be able to use them in base class module (all functions and methods over there). But what I really want, was to use them in inherited classes to.

No problem, you can always store them as a member of base... Yuck! But then instead of just calling "gGlobalVar.doSomethingForMe()" I have to call it by "self.gGlobalVar.doSomethingForMe()". Awkward! Ugly! Bad!

What come to my mind is a python sequence for looking up symbols. There is always __builtins__ module, right? And this one is first in a line of r lookup, right? So what about storing them over there?

So here is an example:

• let's say this is our module storing "globals", say testGlobals.py:
• and here is a base class, say testBase.py: Notice, we can't put there anything outside baseClass, as it wouldn't be visible in inherited classes at all. I'm using built-in setattr or __builtins__.__setattr__, cause in pure python __builtins__ is visible as module, but when you import baseClass elsewhere, it would be just a dictionary. If you don't believe just execute this one: once in interactive session:
  
  and then in batch:
• and here it is, a testChild.py
  
• at least some testing:
  
  
• and its output:
  

Once you put your stuff to __builtins__, it is visible everywhere. So in fact it's a global symbol created on the fly. Of course, you can do the same with whatever object you like, i.e. os module. It would be imported in baseClass and then once you put it to the __builtins__, it would be visible in testChild.

Dear Python, if you knew how to cook and clean...