Skip to main content
Solved

(Integer) values of constants in Python API FME

  • October 20, 2023
  • 4 replies
  • 87 views
ronaldhummelink
Contributor
Forum|alt.badge.img+9

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

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

 

This post is closed to further activity.
It may be an old question, an answered question, an implemented idea, or a notification-only post.
Please check post dates before relying on any information in a question or answer.
For follow-up or related questions, please post a new question or idea.
If there is a genuine update to be made, please contact us and request that the post is reopened.

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

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

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

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)

Community Stats

32,128
Posts
121,966
Replies
39,779
Members

Latest FME

Terms & ConditionsCookie settingsAccessibility statement
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.