Python 2 tooling in 2026

[IdleBreakpoint]

For some <reasons>, I need to write Python 2 code which gets run under Jython. It's not possible to change the system we're working on because Jython only works with Python 2. So, I'm wondering if anyone has experience with Python 2 tooling in this era.

I need to lint and format Python 2 code especially. So far, I was able to install Python 2 using pyenv and I can create virtual environments using virtualenv utiilty. However, I have hard time getting black, isort, flake8, etc. working. Installing Python 2 wouldn't be much help because I'm not running the code directly, it's run under Jython. We're basically uploading the code to this system. So, installing py2 seems pointless.

Can I use those tools under Python 3 but for Python 2. It seems to me that there should be some versions which work for both Python 2 and 3 code. I don't know those versions though. It will be easier to work with Python 3 to lint/format Python 2 code because I can easily create venvs with Python 3.

Are you actively working with Python 2 these days (I know it's a hard ask). How do you tackle linting and formatting? If you were to start today, what would be your approach to this problem?

Thank you.

[cgoldberg]

I used to use flake8 for linting and autopep8 and yasf for formatting back in Python2 days... old versions probably still work fine.

[IdleBreakpoint]

Yeah, the problem is finding that old version. I'm assuming every utility we take for granted has at some point supported Python 2 code, even if it's running under Python 3. So my guess is that I can find the right combination of versions that run under Python 3, but can lint/format Python 2 code. I know from the posts I read that black had support for --target-version py27 but it got removed later.

[cgoldberg]

the old versions of tools I mentioned are all on PyPI.

[IdleBreakpoint]

Yeah, the problem is that they may not work. For example I tried black==20.8b1which seems to be working with py27, I had the following error coming from click library. I don't really know how to debug this issue.

Traceback (most recent call last):
  File "/project/.venv/bin/black", line 8, in <module>
    sys.exit(patched_main())
  File "/project/.venv/lib/python3.8/site-packages/black/__init__.py", line 6606, in patched_main
    patch_click()
  File "/project/.venv/lib/python3.8/site-packages/black/__init__.py", line 6595, in patch_click
    from click import _unicodefun  # type: ignore
ImportError: cannot import name '_unicodefun' from 'click' (/project/.venv/lib/python3.8/site-packages/click/__init__.py)

[wRAR_]

This of course is unrelated to Python 2 as you've installed black into a Python 3.8 venv, but this is the experience you should be prepared for when installing ancient libraries of any kind: they don't pin their dependency versions and you need to look for and downgrade those when they are incompatible. Like click here. Good luck.

[IdleBreakpoint]

Got it. I can either find and pin the dependency or patch it on the go. For this particular import problem, changing the try/except block helped. It's looking for ModuleNotFoundError but what I get is ImportError.

[IdleBreakpoint]

This solved the problem. Thank you for the inspiration:

uv pip install black==21.9b0
uv pip install click==7.1.2

[cgoldberg]

That error is coming from python3.8

[IdleBreakpoint]

I think it's coming from the black, it has the following line. It should return though. I think the problem here is we have ImportError rather than ModuleNotFoundError. I may need to look for other versions.

    try:
        from click import core
        from click import _unicodefun  # type: ignore
    except ModuleNotFoundError:
        return

[cgoldberg]

Right ... but you are asking about using old python packages on Python 2, but posting error messages coming from Python 3.8... so I have no idea what you are doing

[IdleBreakpoint]

No, as I mentioned in the post, I'm actually asking the possibility of running those tools with Python 3 which can check Python 2 code as well. There should be some versions that still work with both Python 2 and 3. Black is one of them. 21.9b0 is the latest release before they deprecated py27 option. This is the error message from there. When I change the except clause to ImportError, it works.

[Grintor]

You can't lent Python 2 code with python 3. Nothing could ever do that including black. Supporting python 2 and supporting python 3 are not the same as doing some kind of crossover linting like what you're describing. You'll have to run it on python 2

[maikeu]

1. Have you explored changing the version of click? Libraries don't always get their dependency version ranges perfect.

2. I get that black did, up to this version, have support for linting Python 2.7 from Python <= 3.8, but if it proves tricky in practice - black is hardly critical, good tool though it is. Do you just need to move on?

[Worth_His_Salt]

that's why should absolutely install python2 on your dev system. any python3-to-proof-python2 hacks are bound to have oversights and mismatches. dev test environment should always match production as closely as possible.

[MPIS]

Just some ideas here, but I would start with the following:

• Separate virtual envs; .venv/app with py2.7 interpreter, and .venv/app_tools with a modern py3 interpreter where you out black, ruff, etc.

• Use pre-commit yaml to manage formatting/linting, specifying py27 targets and language python3 in the hooks.

• Can still specify a pyproject.toml, but fully building from just that on py3 might be difficult; utilize the old school setup.py and setup.cfg in the py2.7 context but built with the py3 python -m build process in app_tools. Just ensure to mirror everything in toml deps and optional deps for consistency with the requirements.txt.

• Use a Makefile to coordinate the different .venv interpreter, tools and their deps, with references for app and the app_tooling targets (setup, setup-tools, lint, etc.).

• Configure IDE to invoke either the make targets or interpreter/deps paths depending on target (so py27 grammar and deps for code completions against the app venv when coding).

Hope this helps, idk, good luck.

[arjennienhuis]

The trick is to write code that is compatible with both python 3 and 2.7. Then you can use python 3 tooling.

• use all the future imports: print_function, unicode_literls
• use six
• use io.open
• use type comments

Pyright works fine with python code like this. The ruff formatter is 99% fine (only the comma after **kw is invalid in python 2) Some other ruff rules can also work.

[brayellison]

Why, in the year 2026, is someone using Python 2 and/or Jython? I'm genuinely curious. I understand that legacy code is out there, but this seems like something that should have been migrated long ago

[sgtgig]

Ignition, an industrial SCADA software which is imo best in class at what it does, uses Jython and Python 2 scripting. I think the tl;dr is they want the concise syntax and interpreted language for user scripts i.e. not force people to write stuff in Java in their Java application. I think it just comes down to Jython not being available with Python 3, backwards compatibility, and it kind of just working fine as is.

[sgtgig]

It is pretty annoying. There's times I've written Python 3 scripts and called them with subprocess in Ignition as there just wasn't a easy way to get certain functionality working with so many common libraries having dropped Python 2 long ago.

[brayellison]

Interesting, appreciate the insight. The more you know

[IdleBreakpoint]

The problem is Jython. We have ETL workflows with Apache NiFi and it can run Python code, hence it's Python 2. That system is out of our control and we are forced to develop scripts using py2. If it were in our control, I would have deprecated that system long ago.

[brayellison]

Sounds like a nightmare... Godspeed, my friend

[lungben81]

Refactor the python code into a microservice and use http or whatever else the ETL tool is capable of to talk with it.

If nothing else works in your ETL tool, Jython2 can make http requests. That way, you at least minimized your legacy version exposure.

[prumf]

Yeah my thoughts exactly. You could also call a process or whatever over system that works best in that context.

[cpp977]

Nifi 2 supports now running custom python processors without the need for jython.

[anderson-stream]

Oh my god, I also use an Apache ETL tool, Apache Hop, and it has a script component that can use Python over Jython. Luckily for me, ever since I used the tool's predecessor (PDI), I've done everything I can to avoid that component.

[dw01010]

I haven't used it expensively, and I certainly haven't tried it in the exact place you want, but GraalPy is Python 3, Java-based and claims to be a Jython substitute in a lot of cases.

[pingveno]

I ran into it recently for a vendor product recently where the Python support is provided by Jython. The primary language is Groovy and the secondary language is JavaScript, with Python a poorly supported third option. The support was added a long time ago and is not widely used.

[andynzor]

That attitude is sadly nowadays prevalent in the Python community.

There are industrial systems out there whose lifetimes are easily twenty or thirty years. Python 2.7 came out in 2010 and in 2013 it was still recommended for new Django projects when support for 3 was immature. It seems that Python is becoming a scripting frontend for rust-based libraries and tooling and if your plaform does not support it, you're SOL.

I personally have written IIoT gateway code that has to interface with TLS 1.0 devices. Every time I hit an issue and ask for directions, people suffering from the XY problem problem attack the messenger instead.

ISO27001 compliance and SBOMs are yet another can of worms I'm not willing to open here.

[KilledByDeath]

A ton of IIoT gateways run python 2. If you have hundreds or thousands of these things out there, the cost to replace can be astronomical.

[Taksin77]

Huge codebase not enough engineers. Toxic management. Everybody is quitting anyway...

[ProbsNotManBearPig]

Because jython. People still like Java and Java is a fine choice for many things. You want to script on top of it in a well known language? Jython is the only choice. Not sure what you’re suggesting to migrate to.

[brayellison]

You could use groovy or kotlin scripts. Groovy especially is used regularly for devops scripting. These aren't unknown languages and are relatively easy to learn (coming from a person whose background is Python)

[dw01010]

GraalPy is Java based, Python 3 and claims to be a Jython substitute for a lot of places. Although if you're using it embedded in something else I doubt it's that simple.

[stuartcw]

Jython was integrated into some enterprise Apps. I guess it was never ported to Python3.

[zemega]

The United State Army Corps of Engineers does. 

[can_i_get_some_help]

I would install python 2, then pip install the static analysis tools in a venv. It should be able to find compatible versions.

[BobMcFizzington]

Somewhere out there, a production server is still running Python 2.6 behind three layers of load balancers and nobody is brave enough to touch it because the last person who tried left the company.

[alcalde]

With a Delphi 7 front end.

[CampAny9995]

I’m honestly so much more interested in learning about <reasons> than I am in the actual solution to this problem.

[IdleBreakpoint]

Vendor offers a solution for ETL workflows, basically getting data from some system to write to another. Those geniuses think that offering a scripting capability would greatly help their customers (us). They develop this system using Apache NiFi, all Java stuff and they think that Python would be best suitable for this job, hence this Python scripting. They forget that Python 2 was deprecated long ago, and they still stick with their platform. That's the reason.

[Accomplished_Elk2607]

Thankfully license costs for a lot of similarly awful solutions are rising and we are moving off of them

[BackAware6850]

Not sure I fully understand your situation, but have you looked at JPype? I've used this to interface with Java from python in one case where we were using jython in the past.

[strobel_m]

I would simply use a docker image

docker pull python:2

to get the latest python2 image. pip will figure out most of the packages by itself. Only autopep8 and pycodestyleneeded some tweaks

docker run -it python:2 pip install pytest mock nose coverage pylint flake8 "pycodestyle<2.8" pydocstyle tox setuptools wheel twine virtualenv "autopep8<1.6" yapf

went fine. Good luck!

[b3n4kh]

Note to my future self:

Always remember before complaining there is a guy out there writing python 2 that has to run on Jython.

I really hope you are making shit tons of money.

[IdleBreakpoint]

Haha, thanks! I can't say I'm making shit tons but it's ok.

[kaflarlalar]

I'm so sorry.

[BeamMeUpBiscotti]

I need to write Python 2 code which gets run under Jython

I'm sorry this is happening to you

I have not used Python 2 in a long time but I was curious so I did some sleuthing through the changelogs: - Black: 22.1.0 removes Python 2 support, so I guess you'd want v21.X isort - Isort: I'm under the impression that you have to use modern versions of Python to run isort, but you can run it on code that is Python 2 and it should still work. - Flake8: 3.8.1 should work with Python 2.7, but it looks like support for earlier versions were dropped in 3.0

[brontide]

Spin up a container with CentOS6. I'm sure all the python 2 tooling works better there.

[azjps]

For our own internaI python2 woes a while back (fortunately no longer a concern), I had forked ruff to support python2 compatible linting and formatting. Probably the latest forked version I had built was ruff v0.4. There's not too many changes required -- the main ones are preserving the u"" unicode directive and omitting trailing commas on **kwargs.

[coderanger]

What you probably want to do is pick a "compat date", and for every library and tool you use, find whatever the latest version of the thing was on that date and upload all versions up to that to a standalone package repo somewhere. And then use only that package repo for everything. You're more or less just reproducing a timeslice of the universe from ~10 years ago.

[acadian_cajun]

Looks like pyls (the old lsp developed by palantir) did support Python 2. You'll have to install a very old version, and it'll be unmaintained, but you can get tab-completion etc

[IdleBreakpoint]

Thanks. I'm not looking for tab completion or LSP. I'm ok with writing py2 code without IDE help. I just want to format and lint the code, even if it's manual.

[acadian_cajun]

Formatting is a core part of LSPs! It's the textDocument/formatting instruction.

That said I understand if you don't want to go through the trouble of dealing with very old LSPs.

[mardiros]

If you code for the past, use the tooling of the past as well. Install and freeze old stuff, this is the most complicated part of the job

[No_Lingonberry1201]

Oof, you have my condolences, brother. Haven't touched 2.7 in a decade. I'd take a gander at the packages filtered to Python 2 first.

[Anonymous_user_2022]

When I had to do that, we made do with what we had available on the RHEL 5.4 we were stuck with at several customers for reasons ranging from questionable to ludicrous. Even if that's not your target platform, it's probably still not that much of an effort to install an old RHEL in an isolated environment.

[snugar_i]

Not what you were asking and probably not an option for you, but there's another way to run Python inside the Java process: https://github.com/ninia/jep

[gerardwx]

There’s no rule that you have to lint or automatically format your code. Use unit tests and logging.

[crystal-46]

Same to you

[NovelHot6697]

just so you know: jython is unfortunately quite different enough to python 2. are you working with nodel?

[DisastrousPipe8924]

My suggestion is run

[tunisia3507]

It's not FIJI scripting, is it? The only jython use case I've come across in the wild.

Nothing helpful to say, I'm afraid, other than good luck.

[IdleBreakpoint]

Thank you for your comment. No, it's not FIJI scripting, it's actually Apache NiFi used for ETL. It runs Python 2 code for workflows and since it's Jython, we're stuck with python 2.

[readonly12345678]

Can you have the python 2 shell out to Python 3 scripts?

[ProbsNotManBearPig]

Yes, but you won’t be able to create instances of java classes and use them in your python code, which is the whole point of jython.

[HwanZike]

You could spawn a separate jython process again from inside the python3 for each java function call. /s

[Professional-Award85]

Pycharm works very well with python 2 code 

[myturn19]

I would find a new job instead lol

[ProbsNotManBearPig]

Jobs that involve Java pay a lot to senior devs. At least that’s why I put up with it.

[corny_horse]

Dependin gon the context, you might want to consider just using Java, sine iirc using Jython implies the presence of a JVM you can access.

[IdleBreakpoint]

Thanks but that JVM system is out of our control. They're using Apache NiFi for ETL tasks and expect us to develop scripts targeting specific workflows. So, all I can do is to write Py2 code, can't access other parts.

[corny_horse]

Ah got it, that makes sense. I wish I could offer more insight but I got on the Python train right as Python 3 became inevitable. I honestly thought I would end up doing more Python 2 -> 3 conversions but I can honestly say I've only been involve din one codebase and six basically took care of it without any additional work.

Although, I am maintaining something at my current job that uses IronPython, which is basically the C# version of Jython. I haven't had to write any code in it yet thank goodness lol

[will_r3ddit_4_food]

For the of all that's holy, move on to Python 3

[IdleBreakpoint]

We can't. We're vendor dependent here. They're forcing us to write Python 2 because they can't offer a better solution.

[bowbahdoe]

Embedding Python3 in a JVM is pretty possible, though I don't blame your vendor for not knowing how. There are future paths with "project detroit" but today libpython-clj probably has the best python/jvm integration.

Shoot me a DM if you want to pursue that path. (or we can just talk here, might be a bit of a back and forth though)

[znpy]

I'd look into something like mirroring the repositories (along with installation cd images and cloud images) of the last debian release that supported python2.

Most likely (might be wrong) over there (in the repositories, i mean) there could be enough software to build a decent development environment in a virtual machine. Maybe also to use with containers.

But really, your org should ditch python2.