Introduce the ability to add Dynamic input ports to the PythonCaller.
Same. I'm imagining a second, optional parameter to the "input()" method that would give the name of the input port of the feature, but who knows.
+31- Influencer
I've previously had a process which was doing some list comparisons (one 'master' list, against lists on many features), for performance reasons I ended up having one of the lists written to a csv which was then read and turned back into a list in def __init__ and then the list comparison done for the list on each feature. Interested in whether multiple ports could handle this instead.
Yes, I've done similar stuff several times. I often end up using two PythonCallers and e.g. a global dict to share data between them. Not a solution I particularly like, but it works.
+28- Contributor
Interesting, I often just create dictionaries in the init, and then the input tests each feature for the value of an attribute (created in the appropriate stream before the pythoncaller) and appends it to the appropriate dictionary.
It's inefficient when there is 1 input_A and several thousand input_Bs.
Sure, I've done that as well, especially if the content is static. But if the content is e.g. from a database table then I find it's easier (and cleaner, imho) to let FME read it, rather than using Python modules to read the contents. Sending reader content into the __init__ is not something I know how to do using a single PythonCaller.
It's inefficient when there is 1 input_A and several thousand input_Bs.Why would that be inefficient? With connection runtime ordering it would be fairly simple to assure that input_A always comes before the input_Bs, which is something the code could reflect. Or am I missing something?
Reply
Rich Text Editor, editor1
Editor toolbars
Press ALT 0 for help
Helpful Members This Week
Enter your E-mail address. We'll send you an e-mail with instructions to reset your password.