Re: Migrating PyCups to Python CFFI for libcups 3.x

Hello Zdenek,

I am glad that you like my proposal. Regarding finding the correct path 
of the shared library, I took some inspiration from PyZbar. There is a 
function in the ctypes library named find_library. It looks into the 
standard paths based on which system it is running on. You can find a 
bit of documentation about it here.

https://docs.python.org/3/library/ctypes.html#ctypes.util.find_library

We can use it for finding the correct path of the shared library and 
handle the exceptions accordingly.


Regarding the duplicate email. The first email was in html instead of 
plain-text. This mailing list doesn't allow html email body. But as 
you're in CC also, you got it twice. Sorry for that noise. I'll try to 
continue the discussion in this thread.


Thanks and Regards,

Soumyadeep Ghosh

On 03/04/25 14:22, Zdenek Dohnal wrote:
> Sounds good! cffi is present at least in Centos, so I don't have a 
> dependency issue - I'm not sure about other maintainers (added 
> Johannes and Thorsten I know of).
>
> What we have to make sure (based on the example) that path to .so file 
> is not hardcoded, but configurable during setup.
>
> Thank you for working on this!
>
>
> P.S. I see two mails in the list with almost the same content - is 
> there a difference?
>
> Zdenek
>
> On 4/2/25 15:49, Soumyadeep Ghosh wrote:
>> Hello everyone,
>>
>> This mail is after a long discussion with Till about various 
>> different approaches and possibilities. PyCups for libcups 2.4.x was 
>> written in C using the Python's C extensions
>>
>> The problem with that is:
>>
>> 1. Very low scope of automation
>> 2.Very less support from different python communities
>> 3.Only source of support is the original python documentation
>>
>> With libcups 3.x, I am planning to move to use Python CFFI. With 
>> this, there is also a scope for automating the bindings too. For an 
>> example, how this CFFI bindings work, sharing an example here
>>
>> #include
>>
>> const char* isPrime(int a){
>>    int i, flag=0;
>>    for(i=2;i
>>    {   if (a%i==0)
>>          (flag=1);
>>        else
>>          (flag=0);
>>    }
>>    if (flag==1)
>>      return ("Number is Non-prime.");
>>    else
>>      return ("Number is Prime.");
>> }
>>
>> int main()
>> {
>>      int n;
>>      printf("Enter any number:");
>>      scanf("%d",&n);
>>      isPrime(n);
>> }
>>
>> This is a C function, and now, we complie this as a shared object and 
>> call this from python
>>
>> from cffi import FFI
>>
>> class DeterminePrime:
>>      def __init__(self, library_path="../C 
>> programme/determine_prime.so"):
>>          self.ffi = FFI()
>>                  self.ffi.cdef("""
>>              const char* isPrime(int);
>>          """)
>>                  self.lib = self.ffi.dlopen(library_path)
>>
>>      def check_prime(self, number):
>>          result = self.ffi.string(self.lib.isPrime(number))
>>          return result.decode('utf-8')
>>
>>
>> As one can see, we just need the signature in many cases, to call the 
>> function properly. Please let me know what you think about this change.
>>
>>
>> Thanks and Regards,
>> Soumyadeep Ghosh
>>
>>