| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
| |
remain deprecated in the documentation.
|
|
|
|
|
|
|
| |
comments about why both calls to cyclic gc here can cause problems.
I'll backport to 2.3 maint. Since the calls were introduced in 2.3,
that will be the end of it.
|
|
|
|
|
|
|
|
|
|
| |
and left shifts. (Thanks to Kalle Svensson for SF patch 849227.)
This addresses most of the remaining semantic changes promised by
PEP 237, except for repr() of a long, which still shows the trailing
'L'. The PEP appears to promise warnings for operations that
changed semantics compared to Python 2.3, but this is not
implemented; we've suffered through enough warnings related to
hex/oct literals and I think it's best to be silent now.
|
| |
|
| |
|
| |
|
|
|
|
| |
pre-carbon MacOS9 support.
|
| |
|
| |
|
|
|
|
|
|
|
|
| |
* Install the unittests, docs, newsitem, include file, and makefile update.
* Exercise the new functions whereever sets.py was being used.
Includes the docs for libfuncs.tex. Separate docs for the types are
forthcoming.
|
| |
|
| |
|
| |
|
|
|
|
|
| |
SF patch 825639
http://mail.python.org/pipermail/python-dev/2003-October/039445.html
|
|
|
|
| |
alone, because there can be no guarantee re the semantics of += vs + .
|
|
|
|
|
|
| |
no-cyclic-comparison patch at the same time as errors.c.
Reverting ceval.c to the previous revision.
|
| |
|
|
|
|
| |
a performance bug in sum(manylists)), same as in 2.3 maintenance branch.
|
| |
|
| |
|
|
|
|
| |
(From SF patch #810751)
|
|
|
|
| |
rename LOCAL_GLOBAL to PARAM_GLOBAL.
|
|
|
|
|
|
| |
* Py_BuildValue("(OOO)",a,b,c) --> PyTuple_Pack(3,a,b,c)
* Py_BuildValue("()",a) --> PyTuple_New(0)
* Py_BuildValue("O", a) --> Py_INCREF(a)
|
|
|
|
|
|
|
| |
Refactor code so that one helper routine sets error location and
increments st_errors.
Bug fix candidate.
|
| |
|
| |
|
| |
|
| |
|
|
|
|
| |
Will backport to 2.3.1
|
|
|
|
| |
interpreters. Fixes #698282. Will backport to 2.3.
|
|
|
|
|
|
| |
The embed2.diff patch solves the user's problem by exporting the missing
symbols from the Python core so Python can be embedded in another Cygwin
application (well, at lest vim).
|
|
|
|
|
| |
Make sure the inner function is not compiled when there is a syntax
error in the default arguments.
|
|
|
|
|
|
| |
NULL pointer. (Detected by Michael Hudson, patch provided by Neal Norwitz).
Fix refcounting leak in filtertuple().
|
|
|
|
|
| |
When parsing the constructor arguments failed, a
reference to the argument tuple was leaked.
|
| |
|
|
|
|
| |
UnicodeTranslateError message.
|
|
|
|
|
| |
If there is only one bad character it will now be printed in a
form that is a valid Python string.
|
|
|
|
| |
This should go onto release23-maint, too.
|
|
|
|
|
| |
Verify that the encoding actually exists. Fixes #775985.
Will backport to 2.3.
|
|
|
|
| |
by returning an empty list instead of raising a TypeError.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Cygwin's pthread_sigmask() implementation appears to be buggy. This
patch works around this problem by using sigprocmask() instead.
This patch is implemented in a general way so it could be used by other
platforms too. If this approach is deemed too risky, then I can work up
a patch that just hacks Python/thread_pthread.h for Cygwin.
Note that I tested this patch against 2.3c1 under Red Hat Linux 8.0 too.
[snip]
And finally, I need someone to regenerate pyconfig.h.in and configure
with the same versions of the autotools that are normally used by
Python.
Neal kindly regenerated pyconfig.h.in and configure for me.
|
|
|
|
| |
sys.__modules__.
|
|
|
|
|
|
| |
If the initial import of warnings fails, clear the error. When the module
is actually needed, if the original import failed, see if it has managed
to find its way to sys.modules yet and if so, remember it.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Fixes for three related bugs, including errors that caused a script to
be ignored without printing an error message. The key problem was a bad
interaction between syntax warnings and syntax errors. If an
exception was already set when a warning was issued, the warning could
clobber the exception.
The PyErr_Occurred() check in issue_warning() isn't entirely
satisfying (the caller should know whether there was already an
error), but a better solution isn't immediately obvious.
Bug fix candidate.
|
| |
|
|
|
|
|
| |
- there's a weird variable name here (zimpimport), but I'll leave that
for someone that's familiar with the ZIP import support
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
|
|
|
| |
Will backport.
|
|
|
|
|
|
|
|
|
| |
A new API (only accessible from C) to interrupt a thread by sending it
an exception. This is not always effective, but might help some people.
Requested by Just van Rossum and Alex Martelli. It is intentional
that you have to write your own C extension to call it from Python.
Docs will have to wait.
|