return a tuple.  (this also implies that nobody uses this method; the
bug has been here for a long time)

newline

PyObject_HEAD, not PyObject_VAR_HEAD.

- added bundle_id/--bundle-id option, to specify the CFBundleIndentifier
#765615:
- in the appropriate situation, prepend $PATH with our path instead of
  setting it.

strings, non-standard naming of things in bundles, etc.

- In the top level Makefile, the argument to -install_name should be
  prepended with /System/Library/Frameworks/, so it is an absolute path.
- In the top level Makefile, because of 2), RUNSHARED needs to be set to
  DYLD_FRAMEWORK_PATH=<path to local framework> and $(RUNSHARED) prepended
  to the $(MAKE) lines in the frameworkinstallmaclib and
  frameworkinstallapps targets.

line also use this as the executable in the bundle.

behavior, creating many threads very quickly.  A long debugging session
revealed that the Windows implementation of PyThread_start_new_thread()
was choked with "laziness" errors:

1. It checked MS _beginthread() for a failure return, but when that
   happened it returned heap trash as the function result, instead of
   an id of -1 (the proper error-return value).

2. It didn't consider that the Win32 CreateSemaphore() can fail.

3. When creating a great many threads very quickly, it's quite possible
   that any particular bootstrap call can take virtually any amount of
   time to return.  But the code waited for a maximum of 5 seconds, and
   didn't check to see whether the semaphore it was waiting for got
   signaled.  If it in fact timed out, the function could again return
   heap trash as the function result.  This is actually what confused
   the test program, as the heap trash usually turned out to be 0, and
   then multiple threads all got id 0 simultaneously, confusing the
   hell out of threading.py's _active dict (mapping id to thread
   object).  A variety of baffling behaviors followed from that.

WRT #1 and #2, error returns are checked now, and "thread.error: can't
start new thread" gets raised now if a new thread (or new semaphore)
can't be created.  WRT #3, we now wait for the semaphore without a
timeout.

Also removed useless local vrbls, folded long lines, and changed callobj
to a stack auto (it was going thru malloc/free instead, for no discernible
reason).

Bugfix candidate.

time.tzname[1] and not time.daylight`` is true when it should only when
time.daylight is true.  Tests are also fixed.

Closes bug #763047 and its cohort #763052.

default application" but doesn't give a clue on how to do this. Refer to
Apple Help.

by Skip.

longer.  Pointed out by Alex Martelli.

Use isinstance() instead of comparing types directly, to enable
subclasses of str and unicode to be used as patterns.
Blessed by /F.

mode.  Note that the only restriction on the csvfile passed to writer
objects is that it have a write method.

Clarify parameter name.

this in SF patch #732174.

elsewhere (lines between columns).

(which is not to say it's right), so re-enable it.

Documenting Python and Installing Python Modules still have problems
when converting to GNU info, so we'll continue to leave them out for
now.

Some of this is still pretty iffy.

because it was still looking in the ossaudiodev module namespace for
this symbol.

As the symbol has already been rebound as a global, use that instead.

scope of the _XOPEN_SOURCE and _POSIX_C_SOURCE symbols, including:
- getloadavg()
- typedefs for u_int, u_long, u_char, u_short, ushort & uint

These are now all defined under the control of a __BSD_VISIBLE symbol.

The lack of the typedefs causes several extension modules to build
incorrectly or not at all, and is the cause of failures reported for
test_socket and test_tempfile on this platform
(see python-dev: 29/6/03, pieterb@gewis.nl, "Running tests on freebsd5")

This change does not appear to be needed in the 2.2 branch.

implementation, so remove this decoy (it break formatting of the GNU
info version of the docs).

name was giving problems with some tar implementations.

Tk 8.4 may return different values than 8.3.  This fix should handle
either version.

  version of plistlib.py (r1.2)