exarkun@charm:~$ ls  .pythonstartup.py
.pythonstartup.py
exarkun@charm:~$ python
Python 2.5.2 (r252:60911, Jul 31 2008, 17:28:52) 
[GCC 4.2.3 (Ubuntu 4.2.3-2ubuntu7)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> __file__
'/home/exarkun/.pythonstartup.py'
>>> 
exarkun@charm:~$ mv .pythonstartup.py .not-pythonstartup.py
exarkun@charm:~$ python
Python 2.5.2 (r252:60911, Jul 31 2008, 17:28:52) 
[GCC 4.2.3 (Ubuntu 4.2.3-2ubuntu7)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> __file__
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
NameError: name '__file__' is not defined
>>>

Someone took the time machine and corrected this 18 months ago: r54189
is included in the 2.6 version.

Why wasn't it backported to 2.5?

I was not there, but the usual rules state that a backport is not
allowed to break working code, even if it relies on undocumented
features or side-effects.

Here, PyRun_SimpleFileExFlags changed its behaviour: it now deletes
__main__.__file__ and some applications may have used this attribute in
some way.

Any buggy behavior might be relied on by applications.  Taken to the
extreme, you can never have a bug-fix release of Python.

__file__ from PYTHONSTARTUP breaks the warnings module.  It would be
difficult for an application to rely on __main__.__file__ being set,
since $PYTHONSTARTUP is only read in interactive mode - when it's a
human using Python, not a program.  Of course another process could run
Python interactively in a child process and then rely on __file__, sure.
 But why is that valid?  It's not like __file__ *means* something there
- it's just the value of PYTHONSTARTUP.

But I guess I don't really care anymore.  I understand why warnings are
being reported incorrectly now, so I doubt this affects /me/ anymore. 
It seems like it'd be better to reduce confusion for other people too,
but that's not up to me.

Thanks for pointing out where it was fixed in 2.6.

I was thinking about an application that embeds an interpreter, and
calls PyRun_SimpleFile(). There are many ways to use python...

Jean-Paul, to find out why the specific patch was not backported, you
would have to ask the original committer (which happens to be Georg
Brandl). If you want to ask that question through the tracker, it's best
to add him to the nosy list, so that he can actually see that he is
being asked a question.

My guess is as good as everybody else's: most likely, he didn't have the
time to backport, or didn't consider it important enough.