Supporting with-statements

[erikbgithub]

As the library already has a class, an open() method and a close() method, it would make sense to add the small steps needed to make it callable in a with statement. However, as it's a c-Extension I currently don't feel confident that I could write the code alone.

In Python I would add this:

class SpiDev(...):
    def __init__(self, param1, ...):
        ...
        self.param1 = param1
    ...
    def __enter__(self):
        self.open(self.param1)

    def __exit__(self):
        self.close()

    def __del__(self):
        self.close()

When the with statement is entered, the connection is opened. When it is left, the connection gets closed. Even in case of an exception. And just in case, the connection gets closed on object deletion as well.

More explanation regarding the value of supporting with.

Is there someone who has experience in transferring that idea to the C codebase here?

PS: Locally, I might simply add a wrapper class that gets the new methods added.

[yochem]

It seems like this is currently implemented:

py-spidev/spidev_module.c

Lines 1409 to 1432 in ac2671e

	PyObject *SpiDev_enter(PyObject *self, PyObject *args)
	{
	if (!PyArg_ParseTuple(args, ""))
	return NULL;
	Py_INCREF(self);
	return self;
	}
	static
	PyObject *SpiDev_exit(SpiDevObject *self, PyObject *args)
	{
	PyObject *exc_type = 0;
	PyObject *exc_value = 0;
	PyObject *traceback = 0;
	if (!PyArg_UnpackTuple(args, "__exit__", 3, 3, &exc_type, &exc_value,
	&traceback)) {
	return 0;
	}
	SpiDev_close(self);
	Py_RETURN_FALSE;
	}

This should support something like:

with spidev.SpiDev() as spi:
   ...

However, with my level of understanding Python C modules, it seems like you would still need to call the open() method in the with-statement, and only the close() method is called for you:

How I think it would currently work:

with spidev.SpiDev() as spi:
   spi.open(0, 0)
   spi.max_speed_hz = 4_000_000
   spi.writebyte([0x00])

I am currently also not able to test this.

How I wish it would work:

with spidev.SpiDev(bus=0, device=0, max_speed_hz=4_000_000) as spi:
   spi.writebyte([0x00])

@doceme In general, would it be an idea to document the interface for this package? Maybe autogenerate API documentation? I also feel the current readme is not sufficient, as it for example lacks documentation about this feature. If you would be interested, I could investigate the possibilities.

[fschrempf]

@yochem If you are still interested, feel free to go ahead and suggest changes to the documentation or the code. There is definitely some room for improvements.

[yochem]

I can look into it, but I currently don't have acces to a linux box and SPI devices. Would you be able to test PRs?

[fschrempf]

@yochem Thanks! Yes, I think I could do some testing and reviewing.

[yochem]

Would it be an idea to lift most of the user-interfacing code to a .py file while keeping the spidev interface in C? This would reshape the project like:

py-spidev/
├── pyproject.toml
├── README.md
├── LICENSE
└── spidev/
    ├── __init__.py
    ├── _spidev.c
    └── spidev.py

Some benefits I can think of:

• Allows for contributions from Python programmers inexperienced with writing Python C modules (like me :))
• Separates Python nice-to-haves, like context managers, and the core functionality
• The Python code can include type hints to make this a typed library

[fschrempf]

@yochem Personally, I got some experience with Python and with C, but almost none with Python C modules, which is why I find it difficult too, to tell what would be the best way. But at first glace it makes sense to separate the low-level C code and the higher-level Python wrapper. Type hints for example would be really nice to have in my opinion.

If @doceme or anyone else doesn't have any objections, I would assume it is worth looking into it.