Re: [Pyme-help] Problems with import

[Igor B. <be...@us...>]

Stefan Neumann wrote:

>Hi,
>
>I just have another problem:
>
>Whem I am importing keys from an file, i need the information, which
>keys are imported. This function looks like this:
>
>*************************************
>
>def importFromFile(data):
>    """
>    Importing a key from a string.
>
>    Parameters:
>
>    data - The data as a string
>    """
>
>    c=core.Context()
>    keydata = core.Data(data)
>    c.op_import(keydata)
>    result = c.op_import_result()
>    return result
>
>*************************************
>
>Now I have to examine the result:
>(I subsitute the >>> to $)
>
>$ result=crypto.importFromFile(keys)
>$ result.imported
>25
>
>
>Then I want iterate over the list of imported keys:
>
>
>$ print result.imports
><pyme.gpgme._gpgme_import_statusPtr; proxy of C _gpgme_import_status
>instance at _d0781408_p__gpgme_import_status>
>
>(It is not None)
>
>$ for imp in result.imports:
>...    print imp.fpr
>
>Traceback (most recent call last):
>  File "<stdin>", line 1, in ?
>TypeError: iteration over non-sequence
>
>This should be the first error. Like mentioned in the
>gpgme-documentation, it should be a list, so i should be able to iterate
>over the list.
>  
>
Well... In gpgme-documentation when then say 'list' they mean the 
'linked-list' where next element is refered by a 'next' pointer. It 
would probably be useful to convert this gpgme_import_status_t type 
field into a 'list' in Python meaning but this may require to have a 
separate PyMe class for the gpgme_import_result_t type as well. So far 
PyMe was successful in creating only a few classes allowing SWIG to 
create the rest of them automagically. I do like the good idea of 
converting all 'linked lists' into 'python lists'. I'll try to think of 
a solution for this which won't conflict with the PyMe idea of keeping 
the Python wrapper code small.

>The second problem is, that the result-information is totally corrupted:
>
>$ result.imports.fpr
>'`\xce\xbc\xb7\xb1'
>
># This is not a real fpr
>
>$ result.imports.next.fpr
>segmentation fault
>  
>
About that I don't know... If the data passed in the 'keys' variable was 
bad it was supposed to generate an exception during  import and not 
return a corrupt value as a result. Have you tried the 
examples/exportimport.py script? If you have a problem even with this 
script then something in pyme or python setup is wrong or at least 
different then in my setup. If not - it's the data you are passing into 
import which causes the problem and reveals a bug in pyme, gpgme, 
python, or in all three of them and it will be a good idea to show the 
data itself.

Cheers,
Igor