Skip to main content
Solved

(Integer) values of constants in Python API FME

ronaldhummelink
Contributor
Forum|alt.badge.img+8

Today I was helping one of the users in my organisation with some code in a PythonCaller.

 

The value returned by fmeobjects.FMEFeature.getAttributeType — Python FME API FME 2023.0 b23309 documentation (safe.com) is an integer.

 

The list of possible values is defined by the list of constants here Features — Python FME API FME 2023.0 b23309 documentation (safe.com)

 

What I am missing is which constant represents which integer value.

Are these available somewhere?

 

This would have been helpful understanding me and my user what was happening.

Best answer by david_r

ronaldhummelink wrote:

Agree this is the right way when you want to perform different actions based on the data type, you should always compare to the defined constants, not their values.

 

My case was diagnostic, so knowing which constant the values represent (even if just in the context of the FME version) is very useful.

I usually won't know the data model my users are working with; and they are not software developers (Which is my background)

 

You could always use some introspection to iterate over and print the values to the FME log from a PythonCaller, e.g.

import fmeobjects
 
def ListFmeDataTypeConsts(feature):
    contents = dir(fmeobjects)
    for obj in contents:
        if obj.startswith('FME_ATTR'):
            print('{} = {}'.format(obj, getattr(fmeobjects, obj)))

Output:

FME_ATTR_BOOLEAN = 1
FME_ATTR_ENCODED_STRING = 12
FME_ATTR_INT16 = 4
FME_ATTR_INT32 = 6
FME_ATTR_INT64 = 13
FME_ATTR_INT8 = 2
FME_ATTR_LIST = 4
FME_ATTR_REAL32 = 8
FME_ATTR_REAL64 = 9
FME_ATTR_REAL80 = 10
FME_ATTR_STRING = 11
FME_ATTR_UINT16 = 5
FME_ATTR_UINT32 = 7
FME_ATTR_UINT64 = 14
FME_ATTR_UINT8 = 3
FME_ATTR_UNDEFINED = 0

 

View original
Did this help you find an answer to your question?

4 replies

david_r
Celebrity
  • david_rCelebrity
  • October 20, 2023

The utility of the constants is to avoid having to know the actual internal value, since it might potentially change between releases. Best practice would be to simply compare the returned value with the constants, e.g.

attr_type = feature.getAttributeType('my_attribute')
if attr_type == fmeobjects.FME_ATTR_STRING:
    # it's a string
elif attr_type == fmeobjects.FME_ATTR_INT64:
     # it's a 64-bit integer (bigint)

 That way your code automatically adapts even if, for some reason, the internal integer values associated with the constants should change.

ronaldhummelink
Contributor
Forum|alt.badge.img+8
david_r wrote:

The utility of the constants is to avoid having to know the actual internal value, since it might potentially change between releases. Best practice would be to simply compare the returned value with the constants, e.g.

attr_type = feature.getAttributeType('my_attribute')
if attr_type == fmeobjects.FME_ATTR_STRING:
    # it's a string
elif attr_type == fmeobjects.FME_ATTR_INT64:
     # it's a 64-bit integer (bigint)

 That way your code automatically adapts even if, for some reason, the internal integer values associated with the constants should change.

Agree this is the right way when you want to perform different actions based on the data type, you should always compare to the defined constants, not their values.

 

My case was diagnostic, so knowing which constant the values represent (even if just in the context of the FME version) is very useful.

I usually won't know the data model my users are working with; and they are not software developers (Which is my background)

 

david_r
Celebrity
  • david_rCelebrity
  • Best Answer
  • October 20, 2023
ronaldhummelink wrote:

Agree this is the right way when you want to perform different actions based on the data type, you should always compare to the defined constants, not their values.

 

My case was diagnostic, so knowing which constant the values represent (even if just in the context of the FME version) is very useful.

I usually won't know the data model my users are working with; and they are not software developers (Which is my background)

 

You could always use some introspection to iterate over and print the values to the FME log from a PythonCaller, e.g.

import fmeobjects
 
def ListFmeDataTypeConsts(feature):
    contents = dir(fmeobjects)
    for obj in contents:
        if obj.startswith('FME_ATTR'):
            print('{} = {}'.format(obj, getattr(fmeobjects, obj)))

Output:

FME_ATTR_BOOLEAN = 1
FME_ATTR_ENCODED_STRING = 12
FME_ATTR_INT16 = 4
FME_ATTR_INT32 = 6
FME_ATTR_INT64 = 13
FME_ATTR_INT8 = 2
FME_ATTR_LIST = 4
FME_ATTR_REAL32 = 8
FME_ATTR_REAL64 = 9
FME_ATTR_REAL80 = 10
FME_ATTR_STRING = 11
FME_ATTR_UINT16 = 5
FME_ATTR_UINT32 = 7
FME_ATTR_UINT64 = 14
FME_ATTR_UINT8 = 3
FME_ATTR_UNDEFINED = 0

 

ronaldhummelink
Contributor
Forum|alt.badge.img+8
ronaldhummelink wrote:

Agree this is the right way when you want to perform different actions based on the data type, you should always compare to the defined constants, not their values.

 

My case was diagnostic, so knowing which constant the values represent (even if just in the context of the FME version) is very useful.

I usually won't know the data model my users are working with; and they are not software developers (Which is my background)

 

Thank you, and a valuable bit of insight into Python possibilities too (My background is (/used to be) PHP and C# web application development)

Reply


Helpful Members This Week

Community Stats

31,299
Posts
118,692
Replies
38,878
Members

Latest FME

Terms & ConditionsCookie settings

Cookie policy

We use cookies to enhance and personalize your experience. If you accept you agree to our full cookie policy. Learn more about our cookies.

 
Cookie settings
A product of
Safe Software respectfully acknowledges that we live, learn and work on the traditional and unceded territories of the Kwantlen, Katzie, and Semiahmoo First Nations.