IcePy: sequence<long> issues migrating to Python 3

joshmoorejoshmoore GermanyMember Josh MooreOrganization: Glencoe Software, Inc.Project: OME, http://openmicroscopy.org

Under Python 3, the long basic type listed under the basic type mappings no longer exists. API methods which take a sequence<long> are now failing with:

self = ..., colNumbers = [0, 1, 2, 3, 4, 5], start = 0, stop = 1, _ctx = None

    def read(self, colNumbers, start, stop, _ctx=None):
>       return _M_omero.grid.Table._op_read.invoke(self, ((colNumbers, start, stop), _ctx))
E       Ice.UnknownException: exception ::Ice::UnknownException
E       {
E           unknown = builtins.ValueError: invalid value for element 0 of sequence<string>
E       }

where the definition of read is:

            idempotent
            Data
                readCoordinates(omero::api::LongArray rowNumbers)
                throws omero::ServerError;

and of LongArray is simply:

        sequence<long> LongArray;

Turning those values into strings prints the expected exception of:

E       ValueError: invalid value for element 0 of sequence<long>

which for me suggests a case statement which is falling through to the string default.

I imagine Ice.Long would be one solution as with JavaScript. Additionally or alternatively, would it be possible for the conversion to be similarly flexible for longs as with floats? (cf. https://forums.zeroc.com/discussion/4450/icepy-accept-integers-where-floats-are-expected) Or even better, does a workaround exist? e.g. is there a way to use the TypeInfo definitions to generate a sequence that will be appropriately detected?

Thanks in advance,
~Josh

Best Answer

Answers

  • xdmxdm La Coruña, SpainAdministrators, ZeroC Staff Jose Gutierrez de la ConchaOrganization: ZeroC, Inc.Project: Ice Developer ZeroC Staff

    Hi Josh,

    Sequence of longs should work with Python 3.x we test this in Ice/operations tests

    https://github.com/zeroc-ice/ice/blob/3.7/python/test/Ice/operations/Twoways.py#L434

    https://github.com/zeroc-ice/ice/blob/3.7/python/test/Ice/operations/Test.ice#L127

    What is the Slice definition of read you show us the definition of readCoordinates but that is not the one being used.

    You might be interested in https://doc.zeroc.com/ice/3.7/language-mappings/python-mapping/client-side-slice-to-python-mapping/python-mapping-for-sequences

    Ice 3.7 have some improvements for marshal sequences of basic types using python buffer protocol

  • joshmoorejoshmoore GermanyMember Josh MooreOrganization: Glencoe Software, Inc.Project: OME, http://openmicroscopy.org

    What is the Slice definition of read you show us the definition of readCoordinates but that is not the one being used.

    Sorry, it's essentially the same:

                idempotent
                Data
                    read(omero::api::LongArray colNumbers, long start, long stop)
                    throws omero::ServerError;
    
    

    Sequence of longs should work with Python 3.x we test this in Ice/operations tests

    Thanks. I'll look through the examples and see if I can pointpoint a difference.

    some improvements for marshal sequences

    Am I right in assuming this would impact end users? If possible, I'd much appreciate a non-breaking solution.

    ~Josh

  • xdmxdm La Coruña, SpainAdministrators, ZeroC Staff Jose Gutierrez de la ConchaOrganization: ZeroC, Inc.Project: Ice Developer ZeroC Staff

    What is the Slice definition for Data?

  • joshmoorejoshmoore GermanyMember Josh MooreOrganization: Glencoe Software, Inc.Project: OME, http://openmicroscopy.org
    edited November 4
    class Column {
    
        string name;
        string description;
    
    };
    
    sequence<Column> ColumnArray;
    
    class Data {
    
        long lastModification;
        omero::api::LongArray rowNumbers;
        ColumnArray columns;
    
    };
    
  • joshmoorejoshmoore GermanyMember Josh MooreOrganization: Glencoe Software, Inc.Project: OME, http://openmicroscopy.org

    @xdm: good morning & thanks. Apparently I had lost the forest for the tress. The problem was indeed server-side with bytes needing to be decoded to native strings.

    All the best,
    ~Josh

Sign In or Register to comment.