The following command is broken on Python 2.5/2.6
python -m unittest test_file
It outputs

----------------------------------------------------------------------
Ran 0 tests in 0.000s

OK

But in Python 2.7 the same command works

----------------------------------------------------------------------
Ran 1 tests in 0.000s

OK

It is even more confusing with test class method on command line:
  python26 -m unittest test_file.SomeTest
Traceback (most recent call last):
  ...
  File "C:\~env\Python26\lib\unittest.py", line 598, in loadTestsFromName
    test = obj()
  File "C:\~env\Python26\lib\unittest.py", line 216, in __init__
    (self.__class__, methodName)
ValueError: no such test method in <class 'test_file.SomeTest'>: runTest

I know that our <...> policy denies backporting such fixes to Python 2.5/2.6, but such things that make an illusion that they work while in fact they never did - see bpo-6514, make Python really suxx. I can feel user frustration while trying to maintain 2.6 compatibility and wasting time trying to run test suite. I wouldn't mind if -m unittest won't work in non-supported versions, but it should at least point to bug report.

(if I'll ever switch to Ruby - this one will definitely be in the list reasons)

Isn't this an exact duplicate of bpo-6514? Or do you suggest something else?

Yes, this is a duplicate.

bpo-6514 is to make -m unittest work run on 2.5/2.6.

This bug is not to fix it, but to stop displaying confusing messages. It will be enough to exit with a message like:

"-m unittest call is not supported in Python 2.5/2.6 - use something else (nose?) instead"

2.5 / 2.6 are in security fix only mode. So this won't get fixed. Please don't reopen.

I need a "why-python-suxx" keyword to point people with dumb questions about why they should not use specific Python versions to a query that lists all sensitive issues for this specific version that won't be fixed due to security fix only mode.

At some point we have to draw the line, otherwise we would have to backport things to 2.3 and 2.4 too. We are already maintaining 4 branches (2.7, 3.1, 3.2, 3.3).

I know. But stuff like this is necessary for proper release management and future planning. Using "why-python-suxx per module" ™ metric, it is possible to pinpoint badly designed parts that should be removed or replaced in Python4.

I need a "why-python-suxx" keyword to point people with dumb
questions about why they should not use specific Python versions to a
query that lists all sensitive issues for this specific version that
won't be fixed due to security fix only mode.

You may not know it, but repeating over and other that Python, its docs, its development process and/or its developers suck does not raise the incentive to change things. We’re all volunteers doing our best in our free time, please keep that in mind. Also consider that when one person keeps saying that everything sucks while other people say that the overall quality is good, it may be that the first person is wrong.

As Ezio said, we have to draw the line. A constructive outcome of this bug would be a doc patch adding a versionadded directive to the 2.7 docs, which we can fix (and we know that people tend to use the latest version of the docs).

Leaving aside the inconsiderate comments about suckage, constructive proposals do help. A lot of things in the current process are good, and you should accept the word of the actual developers for it. Also remember that both PSF and python-dev are increasingly welcoming of contributors and trying to improve things. However, I think it’s best to let the people who actually manage the releases to judge whether changes are required for “proper release management and future planning”.

In other words, you catch more flies with wine than vinegar.