python2.6 -m site used to print some status information to the console.
python3.0 -m site and python2.5 -m site are still working as expected.
An initial debug session showed that the site module isn't imported a
second time under the name __main__. I suspect a regression in runpy or
related code.

I concur with the Christian's analysis:

$ python2.6 -m site
$ python2.6 -S -m site
[output....]

Platform? It works fine for me (system python is 2.5, local python is
trunk - the tildes aren't actually in the printout, I subbed them in for
my home directory):

~/devel/python$ python -m site
sys.path = [
    '~/devel/python',
    '/usr/lib/python25.zip',
    '/usr/lib/python2.5',
    '/usr/lib/python2.5/plat-linux2',
    '/usr/lib/python2.5/lib-tk',
    '/usr/lib/python2.5/lib-dynload',
    '/usr/local/lib/python2.5/site-packages',
    '/usr/lib/python2.5/site-packages',
    '/usr/lib/python2.5/site-packages/PIL',
    '/var/lib/python-support/python2.5',
    '/var/lib/python-support/python2.5/gtk-2.0',
]
~/devel/python$ ./python -m site
sys.path = [
    '~/devel/python',
    '/usr/local/lib/python27.zip',
    '~/devel/python/Lib',
    '~/devel/python/Lib/plat-linux2',
    '~/devel/python/Lib/lib-tk',
    '~/devel/python/Lib/lib-old',
    '~/devel/python/Modules',
    '~/devel/python/build/lib.linux-i686-2.7',
]
USER_BASE: '~/.local' (exists)
USER_SITE: '~/.local/lib/python2.7/site-packages' (doesn't
exist)
ENABLE_USER_SITE: True

It's an *installation* of Python 2.6.0 (r26:66714, Oct  2 2008) on
Ubuntu Linux AMD64. The feature is broken on the release26-maint branch
but it works fine on the trunk.

I'm setting up a 2.6 working area now - we'll see what's to be seen once
I have that up and running. None of the runpy or pkgutil stuff has been
touched in months though (since PEP 366 was implemented), so I'm a
little puzzled how it could be working on the trunk and not on the 2.6
maintenance branch.

No joy. 32-bit Ubuntu here, and "./python -m site" works fine on the 2.6
branch, as does "python2.6 -m site" after a "make altinstall".

Is this an installation you built yourself, or was it packaged by
someone else?

I build the installation myself and used "make altinstall", too. Even
the latest checkout of the 2.6 branch fails to print the site information.

$ ./configure
...
$ make
...
$ ./python -m site
$ ./python -m platform
Linux-2.6.24-19-generic-x86_64-with-debian-lenny-sid
$ uname -a
Linux hamiller 2.6.24-19-generic #1 SMP Wed Aug 20 17:53:40 UTC 2008
x86_64 GNU/Linux
$ LC_ALL=C svn info .
Path: .
URL: svn+ssh://pythondev@svn.python.org/python/branches/release26-maint
Repository Root: svn+ssh://pythondev@svn.python.org
Repository UUID: 6015fed2-1504-0410-9fe1-9d1591cc4771
Revision: 66863
Node Kind: directory
Schedule: normal
Last Changed Author: georg.brandl
Last Changed Rev: 66859
Last Changed Date: 2008-10-08 21:28:36 +0200 (Wed, 08 Oct 2008)

Hmm, that makes for absolutely identical base systems except that mine
is i686 where yours is x86_64.

What do you see if you stick some debugging messages at module level in
site.py? (e.g. printing out __name__)

(I'll be going offline shortly - I'll have another look tomorrow night,
but since I can't reproduce this locally I'm probably not going to be
much help in figuring out where it is losing the plot)

I already added a print __name__ right before the if __name__ ==
"__main__" block. Python 2.5, trunk and 3.0 print:

site
__main__

while Python 2.6 just prints:

site

Christian

Christian, is this still a problem for you after the release or can we
close it?

It's still an issue and I like to get it resolved. The site module lets
users access information related to my uesr site package directory. In
2.6 the information isn't accessible: 

$ python3.0 -m site --user-site
/home/heimes/.local/lib/python3.0/site-packages
$ python2.6 -m site --user-site
$

So what could be different between my x86 system and your x86_64 system
that it works for me and not for you?

Could you try doing "python -i -m site" and poke around in the main
namespace (which is where the interactive session will start) a bit to
see if anything looks strange? __file__, __package__ and __name__ are
probably of particular interest.

Nick Coghlan wrote:
> Nick Coghlan <ncoghlan@gmail.com> added the comment:
> 
> So what could be different between my x86 system and your x86_64 system
> that it works for me and not for you?
> 
> Could you try doing "python -i -m site" and poke around in the main
> namespace (which is where the interactive session will start) a bit to
> see if anything looks strange? __file__, __package__ and __name__ are
> probably of particular interest.

That didn't help much

$ ./python -i -m site
 >>> __name__
'__main__'
 >>> __package__
''
 >>> __file__
 >>> __file__ is None
True

However a pdb session has revealed some interesting things including the 
reason for the "bug".

$ ./python -m site
 > 
/home/heimes/dev/python/release26-maint/Lib/runpy.py(103)_run_module_as_main()
-> try:
(Pdb) w
 > 
/home/heimes/dev/python/release26-maint/Lib/runpy.py(103)_run_module_as_main()
-> try:
(Pdb) p mod_name, set_argv0
('site', 1)
(Pdb) n
 > 
/home/heimes/dev/python/release26-maint/Lib/runpy.py(104)_run_module_as_main()
-> loader, code, fname = _get_module_details(mod_name)
(Pdb) n
 > 
/home/heimes/dev/python/release26-maint/Lib/runpy.py(117)_run_module_as_main()
-> pkg_name = mod_name.rpartition('.')[0]
(Pdb) p loader, code, fname
(<zipimporter object 
"/usr/local/lib/python2.6/site-packages/setuptools-0.6c9-py2.6.egg">, 
<code object <module> at 0x7fe765e95f30, file 
"build/bdist.linux-x86_64/egg/site.py", line 1>, None)
(Pdb) p code
<code object <module> at 0x7fe765e95f30, file 
"build/bdist.linux-x86_64/egg/site.py", line 1>

Solution for my issue:
$ sudo rm -rf /usr/local/lib/python2.6/site-packages/

Thanks for listening ... :/ I'm feeling embarrassed

Christian

That does remind me of another problem though - __main__.__file__ isn't
currently set correctly when runpy picks up the module to run from
inside a zipfile (zipimporter doesn't support runpy/pkgutil's
non-standard get_filename() extension to the PEP 302 importer API)

Morphing the issue to refer to the __main__.__file__ problem I mentioned
in my previous comment.

See issue4512

Fixed for 2.7 in r67750.

Will be ported to 2.6, 3.0 and 3.1.

Final revisions for fix:
2.7 = r67751 (there was a new test file missing from the initial checkin)
2.6 = r67752
3.1 = r67753
3.0 = r67754