When getting a string buffer for a string we just created, use
PyString_AS_STRING() instead of PyString_AsString() to avoid the
call overhead and extra type check.
meaning infinity -- but at least warn about it in the code! I pissed
away a couple hours on this today, and don't wish the same on the next
in line.
Bugfix candidate.
means "replace everything". But the string module, string.replace()
amd test_string.py believe a 0 count means "replace nothing".
"Nothing" wins, strop loses.
Bugfix candidate.
Platform blew up on "123".replace("123", ""). Michael Hudson pinned the
blame on platform malloc(0) returning NULL.
This is a candidate for all bugfix releases.
This closes SF bug #231328.
Added all constants needed to use the functions defined in this module
that are not defined elsewhere (the O_* symbols are available in the
os module). No additonal modules are needed to use this now.
PyObject_AsFileDescriptor() -- it does the same thing everywhere, so
use it the same way everyone else does so that exceptions are
consistent. This means we have less code here, and we do not need to
resort to hackish ways of getting the Python-visible function name to
fdconv().
this could cause invalid paths to be returned for AF_UNIX sockets on some
platforms (including FreeBSD 4.2-RELEASE), appearantly because there is
no assurance that the address will be nul-terminated when filled in by the
kernel.
PySocketSock_recvfrom(): Use PyString_AS_STRING() to get the data pointer
of a string we create ourselves; there is no need for the extra type
check from PyString_AsString().
This closes SF bug #416573.
This patch does several things to termios:
(1) changes all functions to be METH_VARARGS
(2) changes all functions to be able to take a file object as the
first parameter, as per
http://mail.python.org/pipermail/python-dev/2001-February/012701.html
(3) give better error messages
(4) removes a bunch of comments that just repeat the docstrings
(5) #includes <termio.h> before #including <sys/ioctl.h> so more
#constants are actually #defined.
(6) a couple of docstring tweaks
I have tested this minimally (i.e. it builds, and
doesn't blow up too embarassingly) on OSF1/alpha and
on one of the sf compile farm's solaris boxes, and
rather more comprehansively on my linux/x86 box.
It still needs to be tested on all the other platforms
we build termios on.
This closes the code portion of SF patch #417081.
while not generally a good idea, this is used by RDF users, and works
to implement RDF-style namespace+localname concatenation as defined
in the RDF specifications. (This also corrects a backwards-compatibility
bug.)
Be more conservative while clearing out handlers; set the slot in the
self->handlers array to NULL before DECREFing the callback.
Still more adjustments to make the code style internally consistent.
OpenSSL versions beore 0.9.5. This just is too experimental to be
worth it, especially since the user would have to do some severe
hacking of the Modules/Setup file to even enable the EGD code, and
without the EGD code it would always spit out a warning on some
systems -- even when socket.ssl() is not used. Fixing that properly
is not my job; the EGD patch is clearly not so important that it
should hold up the 2.1 release.
always:
- #undef HAVE_CONFIG_H (because otherwise chardefs.h tries to include
strings.h)
- #include readline.h and history.h
and we never declare any readline function prototypes ourselves.
This makes it compile with readline 4.2, albeit with a few warnings.
Some of the remaining warnings are about completion_matches(), which
is renamed to rl_completion_matches().
I've tested it with various other versions, from 2.0 up, and they all
seem to work (some with warnings) -- but only on Red Hat Linux 6.2.
Fixing the warnings for readline 4.2 would break compatibility with
3.0 (and maybe even earlier versions), and readline doesn't seem to
have a way to test for its version at compile time, so I'd rather
leave the warnings in than break compilation with older versions.
problem reported by Neil Schemenauer on python-dev on 4/12/01, wth
subject "Problem with SSL and socketmodule on Debian Potato?".
It's tentative because Moshe objected, but Martin rebutted, and Moshe
seems unavailable for comments.
(Note that with OpenSSL 0.9.6a, I get a lot of compilation warnings
for socketmodule.c -- I'm assuming I can safely ignore these until 2.1
is released.)
before calling any callbacks. This is important
since the callback objects only look at themselves
to determine that they are invalide. This change
avoids a segfault when callbacks use a different
reference to an object in the process of being
deallocated.
This fixes SF bug #415660.
(with modification of existing dict elements!).
This is part of SF patch #409864: lazy fix for Pings bizarre scoping
crash.
The adaptation I made to Michael's patch was to change the error
handling to avoid masking other errors (moving the specific error
message to inside test_dict_inner()), and to insert a test for
dict==NULL at the start.
Michael Hudson suggested this fox for the Tru64 problem (SF bug
232597). It looks reasonable, it works on Tru64, and it doesn't beak
anything on Linux, so I say go for it.
of 2-space and 4-space indents. Whatever, when I saw the checkin diff it
was clear that what my editor thinks a tab means didn't match this module's
belief. Removed all the tabs from the lines I added and changed, left
everything else alone.
pickled into the signed(!) 4-byte BININT format, so were getting unpickled
again as negative ints. Repaired that.
Added some minimal docs at the top about what I've learned about the pickle
format codes (little of which was obvious from staring at the code,
although that's partly because all the size-related bugs greatly obscured
the true intent of the code).
Happy side effect: because save_int() needed to grow a *proper* range
check in order to fix this bug, it can now use the more-efficient BININT1,
BININT2 and BININT formats when the long's value is small enough to fit
in a signed 4-byte int (before this, on a sizeof(long)==8 box it always
used the general INT format for negative ints).
test_cpickle works again on sizeof(long)==8 machines. test_pickle is
still busted big-time.
binary pickle, and the latter contains a pickle of a negative Python
int i written on a sizeof(long)==4 box (and whether by cPickle or
pickle.py), it's read incorrectly as i + 2**32. The patch repairs that,
and allows test_cpickle.py (to which I added a relevant test case earlier
today) to work again on sizeof(long)==8 boxes.
There's another (at least one) sizeof(long)==8 binary pickle bug, but in
pickle.py instead. That bug is still there, and test_pickle.py doesn't
catch it yet (try pickling and unpickling, e.g., 1 << 46).
where sizeof(long)==8. This *was* broken on boxes where signed right
shifts didn't sign-extend, but not elsewhere. Unfortunately, apart
from the Cray T3E I don't know of such a box, and Guido has so far
refused to buy me any Cray machines for home Python testing <wink>.
More immediately interesting would be if someone could please test
this on *any* sizeof(long)==8 box, to make sure I didn't break it.
handling of EAGAIN.
This may or may not fix the problem for me (Mandrake 7.2 on a Dell
Optiplex GX110 desktop): I can't hear the output, but it does pass the
test now. It doesn't fix the problem for Fred (Mandrake 7.2 on a Dell
Inspiron 7500 which has the Maestro sound drivers). Fred suspects
that it's the kernel version in combination with the driver.
gives the CVS revision of this file even if it does not include the
extra RCS "$Revision: " cruft.
initpyexpat(): Use get_version_string() instead of hard-coding magic
indexes into the RCS string (which may be affected by export options).
tracked as soon as it is clear; this can decrease the number of roots for
the cycle detector sooner rather than later in applications which hold on
to weak references beyond the time of the invalidation.
If a module has a future statement enabling nested scopes, they are
also enable for the exec statement and the functions compile() and
execfile() if they occur in the module.
If Python is run with the -i option, which enters interactive mode
after executing a script, and the script it runs enables nested
scopes, they are also enabled in interactive mode.
XXX The use of -i with -c "from __future__ import nested_scopes" is
not supported. What's the point?
To support these changes, many function variants have been added to
pythonrun.c. All the variants names end with Flags and they take an
extra PyCompilerFlags * argument. It is possible that this complexity
will be eliminated in a future version of the interpreter in which
nested scopes are not optional.