1. Extract Python-2.2.2b1.tgz into a directory
(E:\dev\python\src in this case).
2. Run 'python setup.py build' in the source root
directory.
3. Witness the bug (output shown at the bottom of this
message).

  The problem is that on line 81 of setup.py, the
srcdir is set to None rather than a meaningful
directory name
(distutils.sysconfig.get_config_vars('srcdir') returns
[None]).  The traceback below arises on line 84, when
None is passed as an argument to os.path.join.

  My operating system is Windows 2000, and I have MSVC
6 installed.  The compiler is configured properly; I've
built many other distutils-ified extensions without a
hitch.

  This bug arises regardless of whether the
Python-2.2.1 version of distutils or the Python-2.2.2b1
version of distutils is used (both versions are labeled
as distutils 1.0.3).  To generate the traceback shown
below, I used the official Windows binary distribution
of Python-2.2.1 (that is, the 'python' in 'python
setup.py build' referred to Python-2.2.1), but the
results are the same if I compile Python-2.2.2b1 by
other means and then attempt to use the resulting
executable to run its own distutils setup script.

----------------------------------------------------------
E:\dev\python\src\Python-2.2.2b1>python setup.py build
running build
running build_ext
Traceback (most recent call last):
  File "setup.py", line 792, in ?
    main()
  File "setup.py", line 787, in main
    scripts = ['Tools/scripts/pydoc']
  File "e:\dev\python\core\lib\distutils\core.py", line
138, in setup
    dist.run_commands()
  File "e:\dev\python\core\lib\distutils\dist.py", line
893, in run_commands
    self.run_command(cmd)
  File "e:\dev\python\core\lib\distutils\dist.py", line
913, in run_command
    cmd_obj.run()
  File
"e:\dev\python\core\lib\distutils\command\build.py",
line 107, in run
    self.run_command(cmd_name)
  File "e:\dev\python\core\lib\distutils\cmd.py", line
330, in run_command
    self.distribution.run_command(command)
  File "e:\dev\python\core\lib\distutils\dist.py", line
913, in run_command
    cmd_obj.run()
  File
"e:\dev\python\core\lib\distutils\command\build_ext.py",
line 256, in run

    self.build_extensions()
  File "setup.py", line 84, in build_extensions
    moddir = os.path.join(os.getcwd(), srcdir, 'Modules')
  File "E:\dev\python\core\Lib\ntpath.py", line 49, in join
    elif isabs(b):
  File "E:\dev\python\core\Lib\ntpath.py", line 35, in
isabs
    s = splitdrive(s)[1]
  File "E:\dev\python\core\Lib\ntpath.py", line 101, in
splitdrive
    if p[1:2] == ':':
TypeError: unsubscriptable object

Logged In: YES 
user_id=21627

This is by design, the Python distribution itself is not build 
using setup.py, except for Cygwin targets.

Logged In: YES 
user_id=414645

> This is by design, the Python distribution itself is not build
> using setup.py, except for Cygwin targets.

  I can accept that readily enough, but shouldn't setup.py
raise a more meaningful error message, instead of
gracelessly dumping a traceback that occurs when it tries to
pass an erroneous value (None) to os.path.join?  The current
behavior may be by design, but to the uninitiated, it *very*
strongly resembles a bug.

  Why not test srcdir (created on line 81 in the current
setup.py) to see if it's a meaningful value, and raise an
informative error message if not?   Like this (line width
ridiculously constrained for the sake of SF's forum):
##################################################
(srcdir,) = sysconfig.get_config_vars('srcdir')

if not srcDir:
    raise EnvironmentError("The system configuration"
        " variable 'srcdir' is not defined, so this"
        " setup script cannot continue.  This error"
        " probably arose because this setup script"
        " is only designed to run in the Cygwin"
        " environment, yet you are attempting to"
        " run it elsewhere."
      )
##################################################

Logged In: YES 
user_id=6380

Please submit an actual patch in context diff format. I'd be
happy to fix this in 2.3 but I've lowered the priority
appropriately.

Logged In: YES 
user_id=414645

Done:

http://sourceforge.net/tracker/index.php?
func=detail&aid=622704&group_id=5470&atid=305470

Logged In: YES 
user_id=6380

I'll fix this in 2.3.