Hacker News Reader

Comment by worik | Hacker News Reader

> There have been breaking changes, especially going from 2.x to 3.x.

That would be tolerable. That is what major version changes are for.

Crudly put Debian 11 to Debian 12 introduced breaking changes that I (from memory) tracked down to things introduced in 3.10 or 3.11

> I'm not sure what converting tabs to spaces had to do with Python.

This is a minor gripe but I do not like tabs, I like tab stops, so I convert tabs to the spaces required to reach a tab stop. Tabs are the syntax required for Python. A bunch of spaces are not enough.

Or do I have that horribly wrong (would not be the first time)

It is the breaking changes in version 3 that have made me an anti evangelist for Python. Not being able to run `mod-ui`, and friends in particular.

I dug around trying to make it work, and it was a mess. (Not mod-ui, love your work, but the Python).

View on HN

> Tabs are the syntax required for Python. A bunch of spaces are not enough.

Yes, you got this very wrong. Yes, whitespace is significant in Python, but it can be either tabs or spaces, as long as it's consistent; although PEP8 [0] recommends using 4 spaces per level of indentation.

It's hard to tell what your issue with backward compatibility was exactly without examples. You are not wrong, Python does occasionally introduces backward incompatible changes - but in most cases they follow a clear deprecation process, announcing a change long before it is eventually introduced.

[0] https://pep8.org/

> It's hard to tell what your issue with backward compatibility was exactly without examples.

I can't speak for worik, but it sounds like they are talking about backwards compatibility as a user of applications written in Python. I.e. you can't just go to python.org, download the latest version of Python, and expect run any Python program because that code could be using a function or library that was recently removed (or in their case, upgrade Debian which presumably packaged a newer version of Python by default). This is compared to a Windows application where the same .exe will generally work everywhere (and failing that, there are compatibility options).

It's also common in Python to declare minimum versions but not usually maximum, so requirements end up looking like "Python 3.8+". So from a user, or Linux package maintainer, perspective, they wouldn't even know it uses something that has since been removed.

Generally speaking, these kinds of issues are considered a bug in the application and should be filed when the maintainer. Though that's of little help if the maintainer is slow to act.

Of course, it's also relatively easy to just install multiple versions of Python these days, then have specific binaries, e.g. python3.10 and python3.11, or a launcher like built into the Windows installer, e.g. py -3.10 or py -3.11

I have said two examples: mod-ui: https://github.com/moddevices/mod-ui/issues/145#issue-203423... and Yocto, no link for that.

Installing multiple versions of Python? You have got to be kidding. But I did try that. I cannot remember the details, all I remember was the inability (a software hellscape) to get a system that had to be built with one version of Python to play well with a package that had to be built with a later version.

It is 2024, what have they learnt? Just keep backward compatibility, it is not that hard.

> Installing multiple versions of Python? You have got to be kidding.

Why? There's some overhead because it's not like everything has changed between versions, but otherwise it's a very clean way to provide exactly what you need without having to maintain backwards compatibility in future development.

Mind, as long the the Python code you're running _isn't_ using removed or significantly changed function, you can absolutely run code written for Python 3.6 with the 3.8 interpreter, and so on. If I recall correctly, this is _why_ it's uncommon to specify maximum versions in Python packages: unless it is specifically incompatible with a change in a newer version it should generally be assumed to work, and pinning a maximum version would just cause it to fail for no reason.

In your Issue with mod-ui, they specifically say

> mod-ui is not compatible with python3.11, so this wont work.

but your second attempt is still using 3.11 based on your output. It's a shame this isn't better documented since it seems to be known, but that seems like an issue with the project, not Python?

Reply on news.ycombinator.com