Skip to main content
  • EN

Hi FME'er,

At this time of year - American Thanksgiving to be precise - the support team at Safe takes a couple of days on something we call "Demo Daze". It's like a mini-hackathon for us. Because of that, this question of the week is going to be a little shorter, and in fact, the question is really one I am asking you:

Have you upgraded all your v2.7 Python scripts to v3 yet?

Let's see why...

Question of the Week

Actually, I was inspired to ask by a couple of questions on Python this week:

As it turned out, neither issue was really related to Python, but what if they were? It got me wondering about Python versions.

Python 2.7

If you weren't aware, Python v2 is being deprecated in favour of v3. In fact it's only 1 month, 2 days, 14 hours and 30 minutes away (and counting down...)

Why? Because it's older technology now, and contains a lot of security holes. Plus it relies on the Visual Studio 2008 (VS2008) runtime, which Microsoft no longer supports.

Is FME Ready?

Yes, it is. We've been working on this for quite a while now. We use Python in various places in FME, and it's all been updated where necessary.

But, obviously, you can tie in Python with FME too, as an author. In previous versions of FME (say 2017, 2018), we supported both v2 and v3 of Python, using a compatibility setting in the Navigator window.

In FME 2019 we still supported v2 but it became an optional installation.

And if you do now try and make or edit a workspace set to be compatible with a v2 script, you would have seen this warning dialog:

If this - or a log warning - appears, and there is no user-defined Python in the workspace, it should be safe to simply change the Python Compatibility parameter of the workspace to 3.4+.

This article explains the situation in a bit more detail.

Are You Ready?

So, we're ready, but are you?

I've not seen a definitive statement, but I strongly suspect that v2 soon won't ship at all with FME, starting with FME 2020. So if you have FME-specific v2 Python code, you'll want to look at it now as a matter of urgency.

You can find Python in a number of places in your workspace. It might be a startup script or it might be in a PythonCaller transformer. You'll want to make sure that all this code is valid for Python v3, and that you change the Compatibility parameter in FME; otherwise FME will still think it's v2 specific and complain to you!

Another place you can find Python code is in custom transformers, which is why I have another thought...

FME Hub Submissions

Do you have any work on the FME Hub? Does it use Python, or is its compatibility set to Python 2?

If so, you may want to download and check/edit those components before FME 2020 releases. It's not just custom transformers, you may also have workspace templates uploaded too.

Already I've downloaded a couple of transformers and been hit with a pop-up error when I do. So for the sake of your users/fans, make sure you have everything ready for them.

FAQ
  • What about other packages I link to?
  • What about other platforms than Windows?

All of these questions - and more - are answered in the article I mentioned above.

This article.

Yes, this one.

Seriously, that page is the source of all good information, so go check it out. And if you do still have questions, then let us know through the usual channels. But be quick about it (1 month, 2 days, 14 hours and 3 minutes...)

Answer of the Week

I don't normally have an answer of the week, but there was a great answer to a question I highlighted last week: how to find neighbors mathematically to improve performance.

Well done to @bwn for coming up with a solution, then implementing and testing it. It's the folk like you who do this for other users that make this community what it is. Thank you for contributing (and yes, I saw your comments, I just haven't had a chance to think about it yet. I will).

Other Notable Questions

Here are some other notable questions this week:

 

 

  • How do I prevent a transformer running until a writer has finished?
    • @ramcgreg asked the question and @erik_jan noted that this would need a FeatureWriter transformer to do the writing, not an actual "writer".
    • Of course, you still need to make sure that the features wait for the summary to exit the FeatureWriter. To do this requires a transformer that needs input from both streams. Then it is forced to wait. Having a bit of free time, I made a custom transformer to do that: the SequenceController.

 

OK, so this turned out to be not much of a shorter post than usual! But in brief, what I hope you take from this post is to check your Python scripts and ensure that they are all ready for v2 deprecation in.... 1 month, 2 days, 13 hours and 45 minutes!!!

One thing I find currently annoying with FME desktop and python based custom transformers, is that if your workspace is set to python 3.x and you try to add a custom transformer using 2.7, your choices are change the workspace compatibility to 2.7 or cancel adding the transformer.

Why can't I just add the transformer without messing with my python settings? 90% of the time, all I need to do is change the setting back to 3.7+ and it works fine.

 

 

Absolutely warn me about it, but the options should be "Change workspace compatibility to 2.7" or "Add it anyways."

How is the python setting in a custom transformer stored? I see the warning when adding certain custom transformers, but within the custom transformer itself the markdown suggests it's been updated to work with python 3 and it works fine once you change the python settings back, but as @jdh says you're forced to temporarily change the workspace compatibility and then change it back again.

The one in particular I'm thinking about is the ListCombiner which i like to recommend quite often and which it looks like @takashi updated in May 2019 to support python 3.x

How is the python setting in a custom transformer stored? I see the warning when adding certain custom transformers, but within the custom transformer itself the markdown suggests it's been updated to work with python 3 and it works fine once you change the python settings back, but as @jdh says you're forced to temporarily change the workspace compatibility and then change it back again.

The one in particular I'm thinking about is the ListCombiner which i like to recommend quite often and which it looks like @takashi updated in May 2019 to support python 3.x

So... I believe the setting needs to be changed by editing the fmx file in Workbench. Under the Navigator window you can find and change Scripting > Python Compatibility.

That would stop it returning the error each time you used the local copy. But only @takashi can make that change and then publish it back to the hub, because it's his transformer.

One thing I find currently annoying with FME desktop and python based custom transformers, is that if your workspace is set to python 3.x and you try to add a custom transformer using 2.7, your choices are change the workspace compatibility to 2.7 or cancel adding the transformer.

Why can't I just add the transformer without messing with my python settings? 90% of the time, all I need to do is change the setting back to 3.7+ and it works fine.

 

 

Absolutely warn me about it, but the options should be "Change workspace compatibility to 2.7" or "Add it anyways."

That's a good point. I'll pass that on to the developers. I don't know if it will be changed, because I don't know what will happen in 2020. Presumably the option (or rather forcing you) to set the workspace compatibility to 2.7 won't be allowed any more because 2.7 isn't supported. I'll check out what will happen and let you know.

Thanks for the kind words @mark2atsafe. Truth be told, I get to most of my answers/ideas by reading through the huge number of excellent contributions by a very capable and active User and Developer Community. Their posted examples and solutions have shortened the learning curve on FME considerably!

Reply


Community Stats

30,162
Posts
114,481
Replies
37,809
Members
Terms & ConditionsCookie 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.