Migrating PyCups to Python CFFI for libcups 3.x

Migrating PyCups to Python CFFI for libcups 3.x

[Soumyadeep Ghosh]

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

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

[Zdenek Dohnal]

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
>
>
-- 
Zdenek Dohnal
Senior Software Engineer
Red Hat, BRQ-TPBC

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

[Soumyadeep Ghosh]

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
>>
>>

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

[Till Kamppeter]

On 4/3/25 10:52, 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).
> 

It is also in Ubuntu in Main (package python3-cffi, upstream version 1.17.1), so 
no problem using it.

> 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, Soumyadeep has posted it to the list twice because the first version got 
rejected. So in the list it is only once (I checked the archives). You see it 
twice because you got explicitly CCed.

    Till