My code before was:
label = Label(Text = "blah blah")
label.Font = Font(label.Font.Name, 12, FontStyle.Bold)
But since I upgraded from 2-3 it no longer seems to work and I’ve had to change it to:
label = Label()
label.Text = "blah blah"
label.Font = Font(label.Font.Name, 12)
label.Font = Font(label.Font, FontStyle.Bold)
Anyone got any idea why? If I’ve got to trawl through all my previous nodes it’s going to be a total pain in the moose. 
Python 3 is different from 2, and CPython is different from IronPython.
The ‘misunderstood’ benefit of doing everything in Python is that you don’t have to manage packages. However this doesn’t avoid all technical debt of, but instead the technical debt is moved down the road from package deployment to graph versioning and more code re-writes. Instead of testing and modifying a bunch of custom nodes in a package, the Python route means you need to test and modify every graph. It’s a lot of work either way - and something that everyone should plan for investing annually.
I’m assuming we’re going to stay with Python 3 for ages now though - so hopefully I’ll not have to have the pain of upgrading for a very long time (if ever).
Python 4 isn’t coming for awhile; and one of the main leads indicated it would only come if a change at the C level required changes so significant that the loss of backwards compatibility would be worth it.
But… Revit and Dynamo changes are constant. Authoring once isn’t going to happen, so budgeting time annually for testing, maintenance and upkeep of your code library is recommended. The amount to budget will vary year to year, but it will always be present to some degree.
Net framework and the potential integration of IP3 (many people crossing their fingers for that) are going to challenge the place for CP3 in future I expect. No idea what the roadmap for either of those is like currently, but they would both be worth researching if you want to scale Python for Dynamo.
IP2 is still accessible in pyRevit or as a package (unsure how long that will be supported for in packages), with the caveats being around security and having to write entirely in Python and potentially cut off the introduction to programming for company users via the tools they have access to.
For me the hurdle of having to take on the quirks of CP3 was as monumental as just learning C/addins ultimately - if I abandon IP2 I just move to addins at that point. The core difference driving this is the sheer amount of documentation around C vs the CP3 gotchas.
The problem here is not Cpython3 (Ironpython3 is based on CPython3 and there are no major bugs).
The problem comes from PythonNet (bridge used by the CPython3 engine), especially the current version 2.5.x which has many bugs and no fully Net support.
Today I understand better why Rihno/Grasshopper directly implemented PythonNet 3.x without going through PythonNet 2.5.x, (cf Ehsan Iran-Nejad), and obviously it was not easy
However, Rhino is not abandoning IronPython