Over a million developers have joined DZone.

Nothing is Private: Python Closures (and ctypes)

· Web Dev Zone

Start coding today to experience the powerful engine that drives data application’s development, brought to you in partnership with Qlik.

As I'm sure you know Python doesn't have a concept of private members. One trick that is sometimes used is to hide an object inside a Python closure, and provide a proxy object that only permits limited access to the original object.

Here's a simple example of a hide function that takes an object and returns a proxy. The proxy allows you to access any attribute of the original, but not to set or change any attributes.

def hide(obj):
    class Proxy(object):
        __slots__ = ()
        def __getattr__(self, name):
            return getattr(obj, name)
    return Proxy()

Here it is in action:

>>> class Foo(object):
...     def __init__(self, a, b):
...         self.a = a
...         self.b = b
>>> f = Foo(1, 2)
>>> p = hide(f)
>>> p.a, p.b
(1, 2)
>>> p.a = 3
Traceback (most recent call last):
AttributeError: 'Proxy' object has no attribute 'a'

After the hide function has returned the proxy object the __getattr__ method is able to access the original object through the closure. This is stored on the __getattr__ method as the func_closure attribute (Python 2) or the __closure__ attribute (Python 3). This is a "cell object" and you can access the contents of the cell using the cell_contents attribute:

>>> cell_obj = p.__getattr__.func_closure[0]
>>> cell_obj.cell_contents
<__main__.Foo object at 0x...>

This makes hide useless for actually preventing access to the original object. Anyone who wants access to it can just fish it out of the cell_contents.

What we can't do from pure-Python is*set* the contents of the cell, but nothing is really private in Python - or at least not in CPython.

There are two Python C API functions, PyCell_Get and PyCell_Set, that provide access to the contents of closures. From ctypes we can call these functions and both introspect and modify values inside the cell object:

>>> import ctypes
>>> ctypes.pythonapi.PyCell_Get.restype = ctypes.py_object
>>> py_obj = ctypes.py_object(cell_obj)
>>> f2 = ctypes.pythonapi.PyCell_Get(py_obj)
>>> f2 is f
>>> new_py_obj = ctypes.py_object(Foo(5, 6))
>>> ctypes.pythonapi.PyCell_Set(py_obj, new_py_obj)
>>> p.a, p.b
(5, 6)

As you can see, after the call to PyCell_Set the proxy object is using the new object we put in the closure instead of the original. Using ctypes may seem like cheating, but it would only take a trivial amount of C code to do the same.

Two notes about this code.

  1. It isn't (of course) portable across different Python implementations
  2. Don't ever do this, it's for illustration purposes only!

Still, an interesting poke around the CPython internals with ctypes. Interestingly I have heard of one potential use case for code like this. It is alleged that at some point Armin Ronacher was using a similar technique in Jinja2 for improving tracebacks. (Tracebacks from templating languages can be very tricky because the compiled Python code usually bears a quite distant relationship to the original text based template.) Just because Armin does it doesn't mean you can though... Wink

Create data driven applications in Qlik’s free and easy to use coding environment, brought to you in partnership with Qlik.


Published at DZone with permission of Michael Foord, DZone MVB. See the original article here.

Opinions expressed by DZone contributors are their own.

The best of DZone straight to your inbox.

Please provide a valid email address.

Thanks for subscribing!

Awesome! Check your inbox to verify your email so you can start receiving the latest in tech news and resources.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}