What are the chances of ST3 including Py3?

[yields]

I understand that it might be hard to migrate to Py3, but what if sublime just added Py3 to the distribution and used some kind of metadata to invoke the plugin?

Sunsetting Python 2

[jfcherng]

ST3 still uses Py2?

[facelessuser]

No, ST3 does not use Py2. I’m not sure where this confusion is coming from… but it does use an extremely old Py3 .

[yields]

oh shoot yeah, got confused since I’m new to python.

It does use a very old py3, a lot of stuff got added and I wonder if it is time to upgrade the python version to ease on plugin developers, for example async is one cool addition I really wanted to use.

[OdatNurd]

This has been talked about many times previously; the short version is that it’s something that’s on the radar but care has to be taken to not break existing packages.

Updating the bundled python

Sublime text 3 comes bundled with python 3.3 since 2012, but we’re in 2019 now, python 3.3 is basically dead! I think sublime devs should consider updating it’s python interpreter once in a while, a good rate would be parallely to python versions (3.7, 3.8, 3.9, …) as the benefits are numerable: performance and startup time improvements wich by turn means sublime text performance and startup time improvements. fewer dependencies for packages, as more libraries now comes with python such as ty…

[ThomSmith]

Copy-pasting my comment from that thread:

---

tl;dr:

• Yes, we should upgrade to 3.7.
• The devs are aware of this.
• It will be a lot of work.
• It’s critical to maintain compatibility with 3.3-exclusive packages.
• Regularly updating the interpreter is problematic because minor Python releases don’t maintain binary compatibility.

[yields]

I agree that it’ll take a lot of time if we upgrade, but would it be possible to include py3.7 along with some flag that packages can use to opt-in?

[ThomSmith]

I would be surprised if that were not the ultimate solution. But this requires:

• Implementing and integrating another plugin host running Python 3.7.
• Implementing the Sublime API in that plugin host.
• Changing how plugins are loaded so that plugins are loaded in the correct runtime.
• Designing and implementing a mechanism for package authors to use to specify the desired runtime.
• Testing all of the above.
• Documenting all of the above.

Even that minimal list omits some critical points:

• What about dependencies? A user might install multiple packages in different runtimes that require the same dependency. There are several possible ways to resolve this:
  • Allow a dependency to support both runtimes, loading the same code for each runtime. This would mean that an existing dependency could not offer a 3.7-specific version, as this could break 3.3 packages.
  • Allow a dependency to offer multiple runtime-specific versions. This requires changing the way that Package Control loads dependencies.
  • Require authors to create a new dependency for 3.7 compatibility.
  • Change the whole way that dependencies are installed for 3.7 to allow separate runtime-specific installs for a single named dependency. This is probably the right answer. It also sounds like a lot of work.
• Do we take the opportunity to improve the API?
  • Yes, upgrade the API to take advantage of newer Python features and conventions.
  • No, leave it exactly as it is.
• How do we encourage package authors to migrate without breaking old packages?

In many cases, picking the easy option might hamstring the new runtime, locking in behavior that might not be desirable in the long run. For instance, it would be easy to port the existing Sublime API to 3.7, but this would waste a once-in-a-lifetime chance to address some of the API’s flaws and quirks.

[FichteFoll]

Change the whole way that dependencies are installed for 3.7 to allow separate runtime-specific installs for a single named dependency. This is probably the right answer. It also sounds like a lot of work.

ST’s plugin_host has had '~/.config/sublime-text-3/Lib/python3.3' in its sys.path for quite a few releases now and dependencies are destined to be moved over there. It’s just that nobody has done the work yet (and the testing demands of a PC release are too high for wbond currently). So that part should be easy to solve, albeit still work someone has to do. It’s also not considering that PC itself has to handle separate runtimes and allow packages and dependencies to specify which one they want to run in.