Data type error in converting from Python 2 to Python 3
avatar par défaut
Lochan
Hi all.

We are working on converting code base from Python 2 to Python 3.
And, came to know that 'long' data type is not supported in P3. On executing one of the commands, where input argument is in DevVarLongSringArray type, we get an error as:

Description: TypeError: Expecting a numeric type, but it is not. If you use a numpy type instead of python core types, then it must exactly match (ex: numpy.int32 for PyTango.DevLong)
Reason: PyDs_PythonError

Similar error used to come with P2 also, but necessary updates were made in PyTango.
Refer this link.

We are using Python 3.5 and PyTango 9.2.5.

I wanted to check if anyone has faced the same issue, and if the necessary updates are made in PyTango 9.2.5.

-Lochan
Edited 5 years ago
rbourtembourg avatar
Reynald
Hi Lochan,

I am no Python expert, but could you please provide a simple code sample where we can reproduce the problem?

Thanks,
Reynald
Rosenberg's Law: Software is easy to make, except when you want it to do something new.
Corollary: The only software that's worth making is software that does something new.
avatar par défaut
JK
Hi Reynald,

Here is the code snippet:

 @command(
    dtype_in='DevVarLongStringArray',
    doc_in="Element logging level for selected devices",
    )
    @DebugIt()
    def SetElementLoggingLevel(self, argin):
        # PROTECTED REGION ID(SKALogger.SetElementLoggingLevel) ENABLED START #
        """
        A method to set Element logging level of source device.
        """
        element_logging_level = argin[0][:]
        print("Element logging level:", element_logging_level)
        print("Type is:", type(element_logging_level))
        element_logging_device = argin[1][:]
        i = 0
        while i < len(element_logging_level[:]):
            self.info_stream("Element Logging level : %s, Device : %s",
                             element_logging_level[i],
                             element_logging_device[i])
            dev_proxy = DeviceProxy(element_logging_device[i])
            dev_proxy.elementLoggingLevel = element_logging_level[i]
            i += 1
        # PROTECTED REGION END #    //  SKALogger.SetElementLoggingLevel

I am trying to send an array with log level and device name. In Python 2, I get type of element_logging_level as list while in Python 3 it is numpy.ndarray.

-Jayant
Edited 5 years ago
rbourtembourg avatar
Reynald
JK
I am trying to send an array with log level and device name. In Python 2, I get type of element_logging_level as list while in Python 3 it is numpy.ndarray.

It seems this is not due to the move to Python 3 but simply because the version of PyTango you're using with Python3 was compiled with numpy (which is a good thing as far as I understood because it has better performances).

This section of the documentation is explaining this:
https://pytango.readthedocs.io/en/latest/data_types.html

Note that if PyTango is compiled with numpy support the numpy type will be the used for the input arguments. Also, it is recommended to use numpy arrays of the appropriate type for output arguments as well, as they tend to be much more efficient.

Thanks to Emmanuel Taurel for the hint.

Hoping this helps.
Reynald
Rosenberg's Law: Software is easy to make, except when you want it to do something new.
Corollary: The only software that's worth making is software that does something new.
avatar par défaut
JK
Hi Reynald,

Thanks for the response. I believe I had gone through this link before. For my code, I need list to be used to take individual elements inside it. So I found a workaround as,

element_logging_level = argin[0][:]
element_logging_level = element_logging_level.tolist()

It converts the datatype from numpy.ndarray to list, which works fine.

I got similar issue here and found that PyTango 8 had this issue fixed for Python 2. I was just keen to know if some fix is required in PyTango 9 for Python 3 or the workaround should suffice.

-Jayant
rbourtembourg avatar
Reynald
In the documentation link I provided, it says also the following:

For SPECTRUM and IMAGES the actual sequence object used depends on the context where the tango data is used, and the availability of numpy.

[…]

for attribute/command values

  • numpy.ndarray if PyTango was compiled with numpy support (default) and numpy is installed.
  • list otherwise

So the difference in behaviour you have observed seems to come only from the fact the PyTango version you're using with Python2 was not compiled with numpy support.

About the issue you're reporting, I've seen there was a typo in the comments provided by Tiago.
The problem was fixed in revision 24332, not 24232.

Here is the patch which was introduced at that time:
https://sourceforge.net/p/tango-cs/code/24332/

Maybe this can help the PyTango experts to provide an improvement, if needed.
At first sight, it looks like this patch was introduced only to fix the issue when setting the value of an DEV_ULONG64 attribute.
In your case, you're dealing with commands. So maybe there is something which could be improved when dealing with commands?

I let the experts decide.
Rosenberg's Law: Software is easy to make, except when you want it to do something new.
Corollary: The only software that's worth making is software that does something new.
 
Register or login to create to post a reply.