Gregory P. Smith [Fri, 12 May 2000 01:31:37 +0000 (01:31 +0000)]
In 'install_misc' class:
- renamed '_copydata()' to 'copy_files()'
- changed it to record complete output filenames
- dropped '_outputdata()' in favour of much simpler 'get_outputs()'
Gregory P. Smith [Fri, 12 May 2000 00:52:23 +0000 (00:52 +0000)]
Patch from Bastien Kleineidam:
adds the 'install_data' and 'install_scripts' commands; these two
are trivial thanks to the 'install_misc' base class in cmd.py.
(Minor tweaks and commentary by me; the code is untested so far.)
Gregory P. Smith [Fri, 12 May 2000 00:34:12 +0000 (00:34 +0000)]
Fix from Lyle Johnson: add the '--compiler' option.
Also added creation of 'implib_dir', a temporary directory specific to
MSVC++ -- but I checked in two ways of fixing it (Lyle's and mine),
because I'm not sure which is right.
Guido van Rossum [Thu, 11 May 2000 18:42:27 +0000 (18:42 +0000)]
The addition of rint() (by Peter Schneider-Kamp; I forgot to mention
that before) in the previous patch has one problem; rint() is not in
the C math library on all platforms (e.g. not for VC++). Make it
conditional on HAVE_RINT.
Fred Drake [Wed, 10 May 2000 20:33:18 +0000 (20:33 +0000)]
Section "The Module's Method Table and Initialization Function":
Explain that the name of the initialization function must be
init<module>(). Omission noted by Daniel Kozan
<crum@dev-group.com>.
Fred Drake [Wed, 10 May 2000 16:50:07 +0000 (16:50 +0000)]
EditorWindow.python_docs():
Instead of using Netscape through os.system(), use the new
browser.open() function to load the documentation on the
default browser. On Windows, this will use the installed
documentation if it exists, instead of hitting python.org.
Guido van Rossum [Wed, 10 May 2000 13:25:32 +0000 (13:25 +0000)]
Trent Mick:
Use "win32" for sys.platform on Win64 instead of "win32" because:
1. While it may be confusing to the Python scriptor on Win64 that he has to
check for win*32*, that is something that he will learn the first time. It
is better than the alternative of the scriptor happily using "win64" and
then that code not running on Win32 for no good reason.
2. The main question is: is Win64 so much more like Win32 than different from
it that the common-case general Python programmer should not ever have to
make the differentiation in his Python code. Or, at least, enough so that
such differentiation by the Python scriptor is rare enough that some other
provided mechanism is sufficient (even preferable). Currently the answer
is yes. Hopefully MS will not change this answer.
Fred Drake [Tue, 9 May 2000 21:50:00 +0000 (21:50 +0000)]
Trent Mick <trentm@activestate.com>:
Limit the 'b' formatter of PyArg_ParseTuple to valid values of an unsigned
char, i.e. [0,UCHAR_MAX]. It is expected that this is the common usage of 'b'.
An OverflowError is raised if the parsed value is outside this range.
Fred Drake [Tue, 9 May 2000 19:57:01 +0000 (19:57 +0000)]
M.-A. Lemburg <mal@lemburg.com>:
Added APIs to allow setting and querying the system's
current string encoding: sys.set_string_encoding()
and sys.get_string_encoding().
Fred Drake [Tue, 9 May 2000 19:53:39 +0000 (19:53 +0000)]
M.-A. Lemburg <mal@lemburg.com>:
Added support for user settable default encodings. The
current implementation uses a per-process global which
defines the value of the encoding parameter in case it
is set to NULL (meaning: use the default encoding).
New version from Jim Fulton to fix a problem that Eric Raymond ran
into. Jim writes:
The core dump was due to a C decrement operation
in a macro invocation in load_pop. (BAD)
I fixed this by moving the decrement outside
the macro call.
I added a comment to load_pop and load_mark
to document the fact that cPickle separates the
unpickling stack into two separate stacks, one for
objects and one for marks.
I also moved some increments out of some macro
calls (PyTuple_SET_ITEM and PyList_SET_ITEM).
This wasn't necessary, but made me feel better. :)
I tested these changes in *my* cPickle, which
doesn't have the new Unicode stuff.
Fred Drake [Tue, 9 May 2000 16:23:23 +0000 (16:23 +0000)]
Skip Montanaro <skip@mojam.com>:
The intent is that this diff adds a link to the rfc822 module doc and
an index reference to this module under the rfc822 heading.
Fred, based on a suggestion from Grant Griffin <grant.griffin@honeywell.com>:
Added link to the MIME FAQ, so people can more easily get more
information about the subject of the module.
Replace PyErr_BadArgument() error in PyInt_AsLong() with "an integer
is required" (we can't say more because we don't know in which context
it is called).
Fix the string methods that implement slice-like semantics with
optional args (count, find, endswith, etc.) to properly handle
indeces outside [INT_MIN, INT_MAX]. Previously the "i" formatter
for PyArg_ParseTuple was used to get the indices. These could overflow.
This patch changes the string methods to use the "O&" formatter with
the slice_index() function from ceval.c which is used to do the same
job for Python code slices (e.g. 'abcabcabc'[0:1000000000L]).
Fix overflow bug in ldexp(x, exp). The 'exp' argument maps to a C int for the
math library call [double ldexp(double, int)], however the 'd'
PyArg_ParseTuple formatter was used to yield a double, which was subsequently
cast to an int. This could overflow.
[GvR: mysteriously, on Solaris 2.7, ldexp(1, 2147483647) returns Inf
while ldexp(1, 2147483646) raises OverflowError; this seems a bug in
the math library (it also takes a real long time to compute the
Inf outcome). Does this point to a bug in the CHECK() macro? It
should have discovered that the result was outside the HUGE_VAL range.]
The following modules are specifically excluded in the Win64 build:
audioop, binascii, imageop, rgbimg. They are advertised as heavily 32-bit
dependent. [They should probably be fixed! --GvR]
Changes to PC\config.[hc] for Win64. MSVC defines _WINxx to differentiate the
various windows platforms. Python's MS_WINxx are keyed off of these. Note
that _WIN32 (and hence MS_WIN32 in Python) are defined on Win32 *and* on
Win64. This is for compatibility reasons. The idea is that the common case is
that code specific to Win32 will also work on Win64 rather than being
specific to Win32 (i.e. there is more the same than different in WIn32 and
Win64).
The following modules are specifically excluded in the Win64 build:
audioop, binascii, imageop, rgbimg. They are advertised as heavily 32-bit
dependent. [They should probably be fixed! --GvR]
The patch to config.h looks big but it really is not. These are the effective
changes:
- MS_WINxx are keyed off _WINxx
- SIZEOF_VOID_P is set to 8 for Win64
- COMPILER string is changed appropriately for Win64
Fix the string methods that implement slice-like semantics with
optional args (count, find, endswith, etc.) to properly handle
indeces outside [INT_MIN, INT_MAX]. Previously the "i" formatter
for PyArg_ParseTuple was used to get the indices. These could overflow.
This patch changes the string methods to use the "O&" formatter with
the slice_index() function from ceval.c which is used to do the same
job for Python code slices (e.g. 'abcabcabc'[0:1000000000L]). slice_index()
is renamed _PyEval_SliceIndex() and is now exported. As well, the return
values for success/fail were changed to make slice_index directly
usable as required by the "O&" formatter.
[GvR: shouldn't a similar patch be applied to unicodeobject.c?]
Changes the 'b', 'h', and 'i' formatters in PyArg_ParseTuple to raise an
Overflow exception if they overflow (previously they just silently
overflowed).
Changes by Guido: always accept values [0..255] (in addition to
[CHAR_MIN..CHAR_MAX]) for 'b' format; changed some spaces into tabs in
other code.
Jack Jansen [Sun, 7 May 2000 22:04:27 +0000 (22:04 +0000)]
Installer for 1.6a2. This is not the optimal location for the VCT file, it should be one level higher, but I can't be bothered fixing that this time around.
Jack Jansen [Fri, 5 May 2000 23:14:11 +0000 (23:14 +0000)]
Adding projects to the repository again, this time in MacBinary form. If you have added the MMPr filetype as "plain binary" in the MacCVS preferences you should revert this before doing this update.
Jack Jansen [Fri, 5 May 2000 23:10:58 +0000 (23:10 +0000)]
Auto-install on import, if NavServices is available. Unless a "no navservices" flag is set Python automagically imports this module so code that uses macfs.xxxGetFile will get NavServices dialogs.
The methods islower(), isupper(), isspace(), isdigit() and istitle()
gave bogus results for chars in the range 128-255, because their
implementation was using signed characters. Fixed this by using
unsigned character pointers (as opposed to using Py_CHARMASK()).
Alas, Vladimir's patch was too aggressive, and started causing really
weird errors. (E.g. see thread "weird bug in test_winreg" in python-dev.)
Since it's actually useful to be able to re-run an individual test
after running test.autotest, we keep the unloading code, but only for
modules whose full name starts with "test.".
Fast NonRecursiveMutex support by Yakov Markovitch, markovitch@iso.ru,
who wrote:
Here's the new version of thread_nt.h. More particular, there is a
new version of thread lock that uses kernel object (e.g. semaphore)
only in case of contention; in other case it simply uses interlocked
functions, which are faster by the order of magnitude. It doesn't
make much difference without threads present, but as soon as thread
machinery initialised and (mostly) the interpreter global lock is on,
difference becomes tremendous. I've included a small script, which
initialises threads and launches pystone. With original thread_nt.h,
Pystone results with initialised threads are twofold worse then w/o
threads. With the new version, only 10% worse. I have used this
patch for about 6 months (with threaded and non-threaded
applications). It works remarkably well (though I'd desperately
prefer Python was free-threaded; I hope, it will soon).
When the UTF-8 conversion to Unicode fails, return an 8-bit string
instead. This seems more robust than returning an Unicode string with
some unconverted charcters in it.
This still doesn't support getting truly binary data out of Tcl, since
we look for the trailing null byte; but the old (pre-Unicode) code did
this too, so apparently there's no need. (Plus, I really don't feel
like finding out how Tcl deals with this in each version.)
1. In Tcl 8.2 and later, use Tcl_NewUnicodeObj() when passing a Python
Unicode object rather than going through UTF-8. (This function
doesn't exist in Tcl 8.1, so there the original UTF-8 code is still
used; in Tcl 8.0 there is no support for Unicode.) This assumes that
Tcl_UniChar is the same thing as Py_UNICODE; a run-time error is
issued if this is not the case.
2. In Tcl 8.1 and later (i.e., whenever Tcl supports Unicode), when a
string returned from Tcl contains bytes with the top bit set, we
assume it is encoded in UTF-8, and decode it into a Unicode string
object.
Notes:
- Passing Unicode strings to Tcl 8.0 does not do the right thing; this
isn't worth fixing.
- When passing an 8-bit string to Tcl 8.1 or later that has bytes with
the top bit set, Tcl tries to interpret it as UTF-8; it seems to fall
back on Latin-1 for non-UTF-8 bytes. I'm not sure what to do about
this besides telling the user to disambiguate such strings by
converting them to Unicode (forcing the user to be explicit about the
encoding).
- Obviously it won't be possible to get binary data out of Tk this
way. Do we need that ability? How to do it?