were failing due to inappropriate clipping of numbers larger than 2**31
with new-style classes. (typeobject.c) In reviewing the code for classic
classes, there were 2 problems. Any negative value return could be returned.
Always return -1 if there was an error. Also make the checks similar
with the new-style classes. I believe this is correct for 32 and 64 bit
boxes, including Windows64.
Add a test of classic classes too.
I modified this patch some by fixing style, some error checking, and adding
XXX comments. This patch requires review and some changes are to be expected.
I'm checking in now to get the greatest possible review and establish a
baseline for moving forward. I don't want this to hold up release if possible.
protected by "if verbose:", which caused the test to fail on
all non-Windows boxes.
Note that I deliberately didn't convert this to unittest yet,
because I expect it would be even harder to debug this on Tru64
after conversion.
appears to be utterly insane. Plug some theoretical
insecurities in the test script:
- Verify that the SIGALRM handler was actually installed.
- Don't call alarm() before the handler is installed.
- Move everything that can fail inside the try/finally,
so the test cleans up after itself more often.
- Try sending all the expected signals in
force_test_exit(), not just SIGALRM. Since that was
fixed to actually send SIGALRM (instead of invisibly
dying with an AttributeError), we've seen that sending
SIGALRM alone does not stop this from hanging.
- Move the "kill the child" business into the finally
clause, so the child doesn't survive test failure
to send SIGALRM to other tests later (there are also
baffling SIGALRM-related failures in test_socket).
- Cancel the alarm in the finally clause -- if the
test dies early, we again don't want SIGALRM showing
up to confuse a later test.
Alas, this still relies on timing luck wrt the spawned
script that sends the test signals, but it's hard to see
how waiting for seconds can so often be so unlucky.
test_threadedsignals: curiously, this test never fails
on Tru64, but doesn't normally signal SIGALRM. Anyway,
fixed an obvious (but probably inconsequential) logic
error.
The first hunk changes the colon to an ! like other Windows variants.
We need to always wait on the child so the lock gets released and
no other tests fail. This is the try/finally in the second hunk.
at stopping test_signal from hanging forever on the Tru64
buildbot. That could be because there's no such thing as
signal.SIGALARM. Changed to the idiotic (but standard)
signal.SIGALRM instead, and added some more debug output.
64-bit boxes. I have no idea what the ctypes docs mean
by "integers", and blind-guessing here that it intended to
mean the signed C "int" type, in which case perhaps I can
repair this by feeding the thread id argument to type
ctypes.c_long().
Also made the worker thread daemonic, so it doesn't hang
Python shutdown if the test continues to fail.
of quoted test data relied on preserving a single trailing
blank. Changed the string from raw to regular, and forced
in the trailing blank via an explicit \x20 escape.
PyThreadState_SetAsyncExc(): internal correctness changes wrt
refcount safety and deadlock avoidance. Also added a basic test
case (relying on ctypes) and repaired the docs.
directories each time it ran, at least on Windows.
Several changes: explicitly closed all files; wrapped long
lines; stopped suppressing errors when removing a file or
directory fails (removing /shouldn't/ fail!); and changed
what appeared to be incorrect usage of os.removedirs() (that
doesn't remove empty directories at and /under/ the given
path, instead it must be given an empty leaf directory and
then deletes empty directories moving /up/ the path -- could
be that the conceptually simpler shutil.rmtree() was really
actually intended here).
In the 2.5 development cycle, MAKE_CLOSURE as changed to take free
variables as a tuple rather than as individual items on the stack.
Closes patch #1534084.
on each iteration. I'm not positive this is the best way to handle
this. I'm also not sure that there aren't other cases where
the lnotab is generated incorrectly. It would be great if people
that use pdb or tracing could test heavily.
Also:
* Remove dead/duplicated code that wasn't used/necessary
because we already handled the docstring prior to entering the loop.
* add some debugging code into the compiler (#if 0'd out).
writing the crc to file on the "PPC64 Debian trunk" buildbot
when running test_tarfile.
This is again a case where the native zlib crc is an unsigned
32-bit int, but the Python wrapper implicitly casts it to
signed C long, so that "the sign bit looks different" on
different platforms.
buildbot (& possibly other 64-bit boxes) during test_gzip.
The native zlib crc32 function returns an unsigned 32-bit integer,
which the Python wrapper implicitly casts to C long. Therefore the
same crc can "look negative" on a 32-bit box but "look positive" on
a 64-bit box. This patch papers over that platform difference when
writing the crc to file.
It may be better to change the Python wrapper, either to make
the result "look positive" on all platforms (which means it may
have to return a Python long at times on a 32-bit box), or to
keep the sign the same across boxes. But that would be a visible
change in what users see, while the current hack changes no
visible behavior (well, apart from stopping the struct deprecation
warning).
Note that the module-level write32() function is no longer used.
Patch by Douglas Greiman.
The test_run_abort() testcase produces a core file on Unix systems,
even though the test is successful. This can be confusing or alarming
to someone who runs 'make test' and then finds that the Python
interpreter apparently crashed.
warning on Windows.
Afraid I can't detect a pattern to when the pack formats decide
to use a signed or unsigned format code -- appears nearly
arbitrary to my eyes. So I left all the pack formats alone and
changed the special-case data values instead.
warnings on Win32.
Also added an XXX about the line:
pos3 = self.fp.tell()
`pos3` is never referenced, and I have no idea what the code
intended to do instead.
These problems may mask more important, real problems.
One or both methods are known to fail on: Solaris, OpenBSD, Debian, Ubuntu.
They pass on Windows and some Linux boxes.
41667, 41668 - initial switch to xmlcore
47044 - mention of xmlcore in What's New
50687 - mention of xmlcore in the library reference
re-apply xmlcore changes to xml:
41674 - line ending changes (re-applied manually), directory props
41677 - add cElementTree wrapper
41678 - PSF licensing for etree
41812 - whitespace normalization
42724 - fix svn:eol-style settings
43681, 43682 - remove Python version-compatibility cruft from minidom
46773 - fix encoding of \r\n\t in attr values in saxutils
47269 - added XMLParser alias for cElementTree compatibility
additional tests were added in Lib/test/test_sax.py that failed with
the xmlcore changes; these relate to SF bugs #1511497, #1513611
with PEP 302. This was fixed by adding an ``imp.NullImporter`` type that is
used in ``sys.path_importer_cache`` to cache non-directory paths and avoid
excessive filesystem operations during imports.
concept, and that different ways of trying to find "the
hardware address" may return different results. Certainly
true on both of my Windows boxes, and in different ways
(see whining on python-dev).
inspect.py, and pydoc.py. Specifically, this allows for querying the type of
an object against these built-in C types and more importantly, for getting
their docstrings printed in the interactive interpreter's help() function.
This patch includes a new built-in module called _types which provides
definitions of getset and member descriptors for use by the types.py module.
These types are exposed as types.GetSetDescriptorType and
types.MemberDescriptorType. Query functions are provided as
inspect.isgetsetdescriptor() and inspect.ismemberdescriptor(). The
implementations of these are robust enough to work with Python implementations
other than CPython, which may not have these fundamental types.
The patch also includes documentation and test suite updates.
I commit these changes now under these guiding principles:
1. Silence is assent. The release manager has not said "no", and of the few
people that cared enough to respond to the thread, the worst vote was "0".
2. It's easier to ask for forgiveness than permission.
3. It's so dang easy to revert stuff in svn, that you could view this as a
forcing function. :)
Windows build patches will follow.
When a node number disagrees, keep track of all sources & the
node numbers they reported, and stick all that in the error message.
Changed all callers to supply a non-empty "source" argument; made
the "source" argument non-optional.
On my box, test_uuid still fails, but with the less confusing output:
AssertionError: different sources disagree on node:
from source 'getnode1', node was 00038a000015
from source 'getnode2', node was 00038a000015
from source 'ipconfig', node was 001111b2b7bf
Only the last one appears to be correct; e.g.,
C:\Code\python\PCbuild>getmac
Physical Address Transport Name
=================== ==========================================================
00-11-11-B2-B7-BF \Device\Tcpip_{190FB163-5AFD-4483-86A1-2FE16AC61FF1}
62-A1-AC-6C-FD-BE \Device\Tcpip_{8F77DF5A-EA3D-4F1D-975E-D472CEE6438A}
E2-1F-01-C6-5D-88 \Device\Tcpip_{CD18F76B-2EF3-409F-9B8A-6481EE70A1E4}
I can't find anything on my box with MAC 00-03-8a-00-00-15, and am
not clear on where that comes from.
Fix the DllGetClassObject and DllCanUnloadNow so that they forward the
call to the comtypes.server.inprocserver module.
The latter was never documented, never used by published code, and
didn't work anyway, so I think it does not deserve a NEWS entry (but I
might be wrong).
it into email 4.0. Specifically, in Message.get_content_charset(), handle RFC
2231 headers that contain an encoding not known to Python, or a character in
the data that isn't in the charset encoding. Also forward port the
appropriate unit tests.
This adds a new key definition for OSX, which is slightly different from the
classic mac definition.
Also add NEWS item for a couple of bugfixes I added recently.
to guess /which/ line the spawned thread is in at the time
sys._current_frames() is called: we know it finished
enter_g.set(), but can't know whether the instruction
counter has advanced to the following leave_g.wait().
The latter is overwhelming most likely, but not guaranteed,
and I see that the "x86 Ubuntu dapper (icc) trunk" buildbot
found it on the other line once. Changed the test so it
passes in either case.
that a 2.93 sec audio file will always take 3.1 sec (as it did on the
hardware I had when I first wrote the test), expect that it will take
2.93 sec +/- 10%, and only fail if it's outside of that range.
Compute the expected
points out there are really two types of continued headers defined in this
RFC (i.e. "encoded" parameters with the form "name*0*=" and unencoded
parameters with the form "name*0="), but we were were handling them both the
same way and that isn't correct.
This patch should be much more RFC compliant in that only encoded params are
%-decoded and the charset/language information is only extract if there are
any encoded params in the segments. If there are no encoded params then the
RFC says that there will be no charset/language parts.
Note however that this will change the return value for Message.get_param() in
some cases. For example, whereas before if you had all unencoded param
continuations you would have still gotten a 3-tuple back from this method
(with charset and language == None), you will now get just a string. I don't
believe this is a backward incompatible change though because the
documentation for this method already indicates that either return value is
possible and that you must do an isinstance(val, tuple) check to discriminate
between the two. (Yeah that API kind of sucks but we can't change /that/
without breaking code.)
Test cases, some documentation updates, and a NEWS item accompany this patch.
Moved the code for _PyThread_CurrentFrames() up, so it's no longer
in a huge "#ifdef WITH_THREAD" block (I didn't realize it /was/ in
one).
Changed test_sys's test_current_frames() so it passes with or without
thread supported compiled in.
Note that test_sys fails when Python is compiled without threads,
but for an unrelated reason (the old test_exit() fails with an
indirect ImportError on the `thread` module). There are also
other unrelated compilation failures without threads, in extension
modules (like ctypes); at least the core compiles again.
Do we really support --without-threads? If so, there are several
problems remaining.
of values in the time tuple passed in. Unfortunately people came to rely on
undocumented behaviour of setting unneeded values to 0, regardless of if it was
within the valid range. Now those values force the value internally to the
minimum value when 0 is passed in.
Specifically, instead of raising a ValueError when there is a single tick in
the parameter, simply return that the entire string unquoted, with None for
both the charset and the language. Also, if there are more than 2 ticks in
the parameter, interpret the first three parts as the standard RFC 2231 parts,
then the rest of the parts as the encoded string.
Test cases added.
Original fewer-than-3-parts fix by Tokio Kikuchi.
Resolves SF bug # 1218081. I will back port the fix and tests to Python 2.4
(email 3.0) and Python 2.3 (email 2.5).
Also, bump the version number to email 4.0.1, removing the 'alpha' moniker.
1. 'as' highlighted as builtin in comment string on import line
2. Comments such as "#False identity" which start with a keyword immediately
after the '#' character aren't colored as comments.
3. u or U beginning unicode string not correctly highlighted
Closes bug 1325071
already verified in .frombuf() on the lines above. If there was
a problem an exception is raised, so there was no way this condition
could have been true.
The hppa ubuntu box sometimes hangs forever in these tests. My guess
is that the wait is failing for some reason. Use WNOHANG, so we won't
wait until the buildbot kills the test suite.
I haven't been able to reproduce the failure, so I'm not sure if
this will help or not. Hopefully, this change will cause the test
to fail, rather than hang. That will be better since we will get
the rest of the test results. It may also help us debug the real problem.
*** The reason this originally failed was because there were many
zombie children outstanding before rev 47158 cleaned them up.
There are still hangs in test_subprocess that need to be addressed,
but that will take more work. This should close some holes.
Add a new function uses_seh() to the _ctypes extension module. This
will return True if Windows Structured Exception handling (SEH) is
used when calling functions, False otherwise.
str() or repr()) would work, just not multi-value tuples. Probably not a
backport candidate, since it changes the behaviour of passing a
single-element tuple:
>>> string.Template("$foo").substitute(dict(foo=(1,)))
'(1,)'
versus
'1'
will return True if Windows Structured Exception handling (SEH) is
used when calling functions, False otherwise.
Currently, only MSVC supports SEH.
Fix the test so that it doesn't crash when run with MingW compiled
_ctypes. Note that two tests are still failing when mingw is used, I
suspect structure layout differences and function calling conventions
between MSVC and MingW.
handler would cause a segfault. This merges in Expat's lib/xmlparse.c
revisions 1.154 and 1.155, which fix this and a closely related problem
(the later does not affect Python).
Moved the crasher test to the tests for xml.parsers.expat.
be called at the end of each test that spawns children (perhaps it
should be called from regrtest instead?). This will hopefully prevent
some of the unexplained failures in the buildbots (hppa and alpha)
during tests that spawn children. The problems were not reproducible.
There were many zombies that remained at the end of several tests.
In the worst case, this shouldn't cause any more problems,
though it may not help either. Time will tell.
(modified patch by Sam Ruby; changed to use separate REs for start and end
tags to reduce matching cost for end tags; extended tests; updated to avoid
breaking previous changes to support IPv6 addresses in unquoted attribute
values)
consistent with os.wait() returning immediately because some other
subprocess had previously exited; the test suite then immediately
tries to lock the mailbox and gets an error saying it's already
locked.
To fix this, do a waitpid() so the test suite only continues once
the intended child process has exited.
remove the flock() calls.
On FreeBSD, the two methods lockf() and flock() end up using the same
mechanism and the second one fails. A Linux man page claims that the
two methods are orthogonal (so locks acquired one way don't interact
with locks acquired the other way) but that clearly must be false.
Without this patch IDLE will get unresponsive when you open the debugger
window on OSX. This is both using the system Tcl/Tk on Tiger as the latest
universal download from tk-components.sf.net.
('[' and ']' were not accepted in unquoted attribute values)
- cleaned up tests of character and entity reference decoding so the
tests cover the documented relationships among handle_charref,
handle_entityref, convert_charref, convert_codepoint, and
convert_entityref, without bringing up Unicode issues that sgmllib
cannot be involved in
both a subclass of Warning and a subclass of types.ClassType. The latter is no
longer true thanks to new-style exceptions.
Closes bug #1510580. Thanks to AMK for the test.
The problem of checking too eagerly for recursive calls is the
following: if a RuntimeError is caused by recursion, and if code needs
to normalize it immediately (as in the 2nd test), then
PyErr_NormalizeException() needs a call to the RuntimeError class to
instantiate it, and this hits the recursion limit again... causing
PyErr_NormalizeException() to never finish.
Moved this particular recursion check to slot_tp_call(), which is not
involved in instantiating built-in exceptions.
Backport candidate.
constructor, meaning it is treated as *args, not as a single argument. This
means using the 'message' attribute won't work (until Py3K comes around),
and so one must grab from 'arg' to get the error number.
os.environ (setting envar COLUMNS), which at least caused
test_float_default() to fail if the tests were run more than once.
This repairs the test_optparse -R failures Neal reported on
python-dev. It also explains some seemingly bizarre test_optparse
failures we saw a couple weeks ago on the buildbots, when
test_optparse failed due to test_file failing to clean up after
itself, and then test_optparse failed in an entirely different
way when regrtest's -w option ran test_optparse a second time.
It's now obvious that make_parser() permanently changing os.environ
was responsible for the second half of that.
is that the wait is failing for some reason. Use WNOHANG, so we won't
wait until the buildbot kills the test suite.
I haven't been able to reproduce the failure, so I'm not sure if
this will help or not. Hopefully, this change will cause the test
to fail, rather than hang. That will be better since we will get
the rest of the test results. It may also help us debug the real problem.
issues that crop up from time to time, but this change seems to have been
pretty stable (no spurious warnings) for about a week.
Other modules which use threads may require similar use of
threading_setup/threading_cleanup from test_support.
of this test. It probably still requires more disk space
than most buildbots have, and in any case is still so
intrusive that if we don't find another way to test this I'm
taking my buildbot offline permanently ;-)
This will hopefully get the buildbots to pass. Not sure this
test will be feasible or even work. But everything is red now,
so it can't get much worse.
now works reliably. It has been updated to use automatic BerkeleyDB
deadlock detection and the bsddb.dbutils.DeadlockWrap wrapper to retry
database calls that would previously deadlock. [SF python bug #775414]
until Gerhard has time to fully debug the issue. This affects versions
before 3.2.1 (possibly only versions earlier than 3.1.3).
Based on discussion on python-checkins.
This backs out the test changes in 46962 which prevented crashes
by not running the tests via a version check. All the version checks
added in that rev were removed from the tests.
Code was added to the error handler in connection.c that seems
to work with older versions of sqlite including 3.1.3.
SQLite versions.
- Added version checks in test suite so that we don't execute tests that we
know will fail with older (buggy) SQLite versions.
Now, all tests should run against all SQLite versions from 3.0.8 until 3.3.6
(latest one now). The sqlite3 module can be built against all these SQLite
versions and the sqlite3 module does its best to not trigger bugs in SQLite,
but using SQLite 3.3.3 or later is recommended.
adjacent triples in the result list describe non-adjacent matching
blocks. That's _nice_ to have, and Guido said he wanted it.
Not a bugfix candidate: Guido or not ;-), this changes visible
endcase semantics (note that some tests had to change), and
nothing about this was documented before. Since it was working
as designed, and behavior was consistent with the docs, it wasn't
"a bug".
arguments in reverse, the interpreter would infinitely recourse trying to get a
coercion that worked. So put in a recursion check after a coercion is made and
the next call to attempt to use the coerced values.
Fixes bug #992017 and closes crashers/coerce.py .
Heavily revised, comprising revisions:
46640 - original trunk revision (backed out in r46655)
46647 - markup fix (backed out in r46655)
46692:46918 merged from branch aimacintyre-sf1454481
branch tested on buildbots (Windows buildbots had problems
not related to these changes).
more comments about why it's this way at all; and removed what looked
like needless expense (sorting (i, j, k) triples directly should give
exactly the same order as sorting (i, (i, j, k)) pairs).
when running with -O.
test_simple_validation_error still fails under -O. That appears to be because
wsgiref's validate.py uses `assert` statements all over the place to check
arguments for sanity. That should all be changed (it's not a logical error
in the software if a user passes bogus arguments, so this isn't a reasonable
use for `assert` -- checking external preconditions should generally raise
ValueError or TypeError instead, as appropriate).
a search path setup, some of these hosts resolve to the wrong address.
By appending a period to the hostname, the hostname should only resolve
to what we want it to resolve to. Hopefully this doesn't break different bots.
Also add more info to failure message to aid debugging test failure.
a search path setup, some of these hosts resolve to the wrong address.
By appending a period to the hostname, the hostname should only resolve
to what we want it to resolve to. Hopefully this doesn't break different bots.
versus generator period. While this was a real weakness of the
older WH generator for lists with just a few dozen elements,
and so could potentially bite the naive ;-), the Twister should
show excellent behavior up to at least 600 elements.
Module docstring: reflowed some jarringly short lines.
Summary of changes:
- support for 'variable sized' data
- support for anonymous structure/union fields
- fix severe bug with certain arrays or structures containing more than 256 fields
clean up files and directories the tests often leave behind by
mistake. This is the first time in history I don't have a bogus
"db_home" directory after running the tests ;-)
Also worked on runtest's docstring, to say something about all the
arguments, and to document the non-obvious return values.
New functions runtest_inner() and cleanup_test_droppings() in
support of the above.
run immediately after test_file. At least 8 buildbot
boxes passed since the underlying problem got fixed,
and they all failed before the fix, so there's no point
to this anymore.
test clean up after itself appears to fix the test failures
when test_optparse follows test_file.
test_main(): Get rid of TESTFN no matter what. That's
also enough to fix the mystery failures. Doesn't hurt
to fix them twice :-)
Since test_file is implicated in mysterious test failures
when followed by test_optparse, if I had any brains I'd
look at the checkin that last changed test_file ;-)
the char buffer was requested. Now it actually returns the char buffer if
available or raises a TypeError if it isn't (as is raised for the other buffer
types if they are not present but requested).
Not a backport candidate since it does change semantics of the buffer object
(although it could be argued this is enough of a bug to bother backporting).
Give a consistent behavior for comparison and hashing of method objects
(both user- and built-in methods). Now compares the 'self' recursively.
The hash was already asking for the hash of 'self'.
aborts the db transaction safely when a modifier callback fails.
Fixes SF python patch/bug #1408584.
Also cleans up the bsddb.dbtables docstrings since thats the only
documentation that exists for that unadvertised module. (people
really should really just use sqlite3)
sys.exutable that isn't usuable on an #!-line. That results in generated
applets that don't actually work. Work around this problem by resetting
sys.executable.
* argvemulator.py didn't work on intel macs. This patch fixes this
(bug #1491468)
from ?iga Seilnacht (sorry about the name, but Firefox
on my box can't display the first character of the name --
the SF "Unix name" is zseil).
This appears to cure the oddball intermittent leaks across
runs when running test_exceptions under -R. I'm not sure
why, but I'm too sleepy to care ;-)
The thrust of the SF patch was to remove randomness in the
pickle protocol used. I changed the patch to use
range(pickle.HIGHEST_PROTOCOL + 1), to try both pickle and
cPickle, and randomly mucked with other test lines to put
statements on their own lines.
Not a bugfix candidate (this is fiddling new-in-2.5 code).
Found them using::
find . -name '*.py' | while read i ; do grep 'def[^(]*( ' $i /dev/null ; done
find . -name '*.py' | while read i ; do grep ' ):' $i /dev/null ; done
(I was doing this all over my own code anyway, because I'd been using spaces in
all defs, so I thought I'd make a run on the Python code as well. If you need
to do such fixes in your own code, you can use xx-rename or parenregu.el within
emacs.)
structmember typecode for Py_ssize_t fields. This should fix some of
the errors on the PPC64 debian machine (64-bit, big endian).
Assigning to readonly fields now raises AttributeError instead of
TypeError, so the testcase has to be changed as well.
string_reverse(): Simplify.
assertRaises(): Raise TestFailed on failure.
test_unpack_from(), test_pack_into(), test_pack_into_fn(): never
use `assert` to test for an expected result (it doesn't test anything
when Python is run with -O).
Move the long-winded, multiply-nested -R support out
of runtest() and into some module-level helper functions.
This makes runtest() and the -R code easier to follow.
That in turn allowed seeing some opportunities for code
simplification, and made it obvious that reglog.txt
never got closed.
in BerkeleyDB >= 4.2 it tried to construct a list out of an uninitialized
char **log_list.
feature: export the DB_ARCH_REMOVE flag by name in the module on BerkeleyDB >= 4.2.
46640 Patch #1454481: Make thread stack size runtime tunable.
46647 Markup fix
The first is causing many buildbots to fail test runs, and there
are multiple causes with seemingly no immediate prospects for
repairing them. See python-dev discussion.
Note that a branch can (and should) be created for resolving these
problems, like
svn copy svn+ssh://svn.python.org/python/trunk -r46640 svn+ssh://svn.python.org/python/branches/NEW_BRANCH
followed by merging rev 46647 to the new branch.
- Following Guido's comments, renamed
* pack_to -> pack_into
* recv_buf -> recv_into
* recvfrom_buf -> recvfrom_into
- Made fixes to _struct.c according to Neal Norwitz comments on the checkins
list.
- Converted some ints into the appropriate -- I hope -- ssize_t and size_t.
the output required more than one line. "Small" dicts got
displayed in seemingly random order (the hash-induced order
produced by dict.__repr__). None of this was documented.
Now pprint functions always sort dicts by key, and the docs
promise it.
This was proposed and agreed to during the PyCon 2006 core
sprint -- I just didn't have time for it before now.
but disabled then because str and unicode strings gave different
results. The implementations were repaired later during the
sprint, but the new test remained disabled.
SimpleXMLRPCServer and DocXMLRPCServer don't look at
the path of the HTTP request at all; you can POST or
GET from / or /RPC2 or /blahblahblah with the same results.
Security scanners that look for /cgi-bin/phf will therefore report
lots of vulnerabilities.
Fix: add a .rpc_paths attribute to the SimpleXMLRPCServer class,
and report a 404 error if the path isn't on the allowed list.
Possibly-controversial aspect of this change: the default makes only
'/' and '/RPC2' legal. Maybe this will break people's applications
(though I doubt it). We could just set the default to an empty tuple,
which would exactly match the current behaviour.
are run in the order:
test_genexps (or any other doctest-based test)
test_struct
test_doctest
The `warnings` module needs an advertised way to save/restore
its internal filter list.
Renames functional extension module to _functools and adds a Python
functools module so that utility functions like update_wrapper can be
added easily.
Remove various dependencies on dictionary order in the standard library
tests, and one (clearly an oversight, potentially critical) in the
standard library itself - base64.py.
Remaining open issues:
* test_extcall is an output test, messy to make robust
* tarfile.py has a potential bug here, but I'm not familiar
enough with this code. Filed in as SF bug #1496501.
* urllib2.HTTPPasswordMgr() returns a random result if there is more
than one matching root path. I'm asking python-dev for
clarification...
invalid file paths for the built-in import machinery which leads to
fewer open calls on startup.
Also fix issue with PEP 302 style import hooks which lead to more open()
calls than necessary.
failures on Windows buildbots, but it's hard to know how since the regrtest
failure output is useless here, and it never fails when a buildbot slave runs
test_tarfile the second time in verbose mode.
The new split functions use a preallocated list. Added tests which exceed
the preallocation size, to exercise list appends/resizes.
Also added more edge case tests.
* Added socket.recv_buf() and socket.recvfrom_buf() methods, that use the buffer
protocol (send and sendto already did).
* Added struct.pack_to(), that is the corresponding buffer compatible method to
unpack_from().
* Fixed minor typos in arraymodule.
the Need For Speed sprint coding. Includes commented out overflow tests
which will be uncommented once the code is fixed.
This test will break the 8-bit string tests because
"".replace("", "A") == "" when it should == "A"
We have a fix for it, which should be added tomorrow.
In rare cases of strings specifying true values near sys.maxint,
and oddball bases (not decimal or a power of 2), int(string, base)
could deliver insane answers. This repairs all such problems, and
also speeds string->int significantly. On my box, here are %
speedups for decimal strings of various lengths:
length speedup
------ -------
1 12.4%
2 15.7%
3 20.6%
4 28.1%
5 33.2%
6 37.5%
7 41.9%
8 46.3%
9 51.2%
10 19.5%
11 19.9%
12 23.9%
13 23.7%
14 23.3%
15 24.9%
16 25.3%
17 28.3%
18 27.9%
19 35.7%
Note that the difference between 9 and 10 is the difference between
short and long Python ints on a 32-bit box. The patch doesn't
actually do anything to speed conversion to long: the speedup is
due to detecting "unsigned long" overflow more quickly.
This is a bugfix candidate, but it's a non-trivial patch and it
would be painful to separate the "bug fix" from the "speed up" parts.
This patchs makes it possible to create a universal build on OSX 10.4 and use
the result to build extensions on 10.3. It also makes it possible to override
the '-arch' and '-isysroot' compiler arguments for specific extensions.