summaryrefslogtreecommitdiffstats
path: root/Lib
Commit message (Collapse)AuthorAgeFilesLines
* pprint's workhorse _safe_repr() function took time quadratic in the # ofTim Peters2001-05-142-39/+44
| | | | | | | elements when crunching a list, dict or tuple. Now takes linear time instead -- huge speedup for even moderately large containers, and the code is notably simpler too. Added some basic "is the output correct?" tests to test_pprint.
* Convert the pprint test to use PyUnit.Fred Drake2001-05-141-35/+57
|
* SF bug[ #423781: pprint.isrecursive() broken.Tim Peters2001-05-143-21/+66
|
* A disgusting "fix" for the test___all__ failure under Windows.Tim Peters2001-05-131-0/+11
|
* Add support for Windows using "mbcs" as the default Unicode encoding when ↵Mark Hammond2001-05-134-13/+91
| | | | dealing with the file system. As discussed on python-dev and in patch 410465.
* Get rid of the superstitious "~" in dict hashing's "i = (~hash) & mask".Tim Peters2001-05-139-36/+52
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The comment following used to say: /* We use ~hash instead of hash, as degenerate hash functions, such as for ints <sigh>, can have lots of leading zeros. It's not really a performance risk, but better safe than sorry. 12-Dec-00 tim: so ~hash produces lots of leading ones instead -- what's the gain? */ That is, there was never a good reason for doing it. And to the contrary, as explained on Python-Dev last December, it tended to make the *sum* (i + incr) & mask (which is the first table index examined in case of collison) the same "too often" across distinct hashes. Changing to the simpler "i = hash & mask" reduced the number of string-dict collisions (== # number of times we go around the lookup for-loop) from about 6 million to 5 million during a full run of the test suite (these are approximate because the test suite does some random stuff from run to run). The number of collisions in non-string dicts also decreased, but not as dramatically. Note that this may, for a given dict, change the order (wrt previous releases) of entries exposed by .keys(), .values() and .items(). A number of std tests suffered bogus failures as a result. For dicts keyed by small ints, or (less so) by characters, the order is much more likely to be in increasing order of key now; e.g., >>> d = {} >>> for i in range(10): ... d[i] = i ... >>> d {0: 0, 1: 1, 2: 2, 3: 3, 4: 4, 5: 5, 6: 6, 7: 7, 8: 8, 9: 9} >>> Unfortunately. people may latch on to that in small examples and draw a bogus conclusion. test_support.py Moved test_extcall's sortdict() into test_support, made it stronger, and imported sortdict into other std tests that needed it. test_unicode.py Excluced cp875 from the "roundtrip over range(128)" test, because cp875 doesn't have a well-defined inverse for unicode("?", "cp875"). See Python-Dev for excruciating details. Cookie.py Chaged various output functions to sort dicts before building strings from them. test_extcall Fiddled the expected-result file. This remains sensitive to native dict ordering, because, e.g., if there are multiple errors in a keyword-arg dict (and test_extcall sets up many cases like that), the specific error Python complains about first depends on native dict ordering.
* Fix one bare except: clause.Fred Drake2001-05-111-1/+1
|
* Remove a bare try/except completely -- it just did not make sense!Fred Drake2001-05-111-12/+12
| | | | Add a comment elsewhere making clear an assumption in the code.
* When guarding an import, only catch ImportError.Fred Drake2001-05-111-1/+1
|
* Clean up a bare except where we only expect to catch pcre.error.Fred Drake2001-05-111-1/+1
|
* Clean up bare except where only IOError makes sense.Fred Drake2001-05-111-1/+1
|
* Clean up bare except: when determining whether a file is seekable.Fred Drake2001-05-111-2/+2
|
* Opening a file for reading can raise IOError, so only catch that.Fred Drake2001-05-111-1/+1
|
* int() of a string is only expected to through ValueError, so do not useFred Drake2001-05-111-2/+2
| | | | a bare except clause.
* <socket>.getsockopt() and <socket>.setsockopt() can only raise socket.error,Fred Drake2001-05-111-1/+1
| | | | so only catch that specific exception.
* Catch only the relevant exceptions instead of using a bare except clause.Fred Drake2001-05-111-1/+1
|
* unlink() would normally be found in the "os" module, so use it from there.Fred Drake2001-05-111-5/+7
| | | | | | | | Remove unused import of "sys". If the file TESTFN exists before we start, try to remove it. Add spaces around the = in some assignments.
* Make test_mutants stronger by also adding random keys during comparisons.Tim Peters2001-05-101-2/+17
| | | | | | | | A Mystery: test_mutants ran amazingly slowly even before dictobject.c "got fixed". I don't have a clue as to why. dict comparison was and remains linear-time in the size of the dicts, and test_mutants only tries 100 dict pairs, of size averaging just 50. So "it should" run in less than an eyeblink; but it takes at least a second on this 800MHz box.
* Change test_mmap.py to use test_support.TESTFN instead of hardcoded "foo",Tim Peters2001-05-101-108/+119
| | | | | and wrap the body in try/finally to ensure TESTFN gets cleaned up no matter what.
* Repair typos in comments.Tim Peters2001-05-101-4/+4
|
* Change some text just a little to avoid font-lock hell.Fred Drake2001-05-101-1/+1
|
* Extend the weakref test suite to cover the complete mapping interface forFred Drake2001-05-101-4/+61
| | | | | | both weakref.Weak*Dictionary classes. This closes SF bug #416480.
* Do no regenerate modules that should no longer be here.Fred Drake2001-05-103-11/+0
|
* Remove all remaining uses of the FCNTL module from the standard library.Fred Drake2001-05-103-30/+29
|
* SF bug #422121 Insecurities in dict comparison.Tim Peters2001-05-102-0/+139
| | | | | | | Fixed a half dozen ways in which general dict comparison could crash Python (even cause Win98SE to reboot) in the presence of kay and/or value comparison routines that mutate the dict during dict comparison. Bugfix candidate.
* Update to reflect deprecation of the FCNTL module: The fcntl module doesFred Drake2001-05-101-4/+4
| | | | *not* define O_RDWR; get that from the os module.
* patch 418489 from Andrew Dalke for string format bugSteve Purcell2001-05-101-1/+1
|
* Guido has Spoken. Restore strop.replace()'s treatment of a 0 count asTim Peters2001-05-101-1/+3
| | | | | | | 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.
* The strop module and test_strop.py believe replace() with a 0 countTim Peters2001-05-101-1/+1
| | | | | | | 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.
* SF bug #422088: [OSF1 alpha] string.replace().Tim Peters2001-05-091-0/+6
| | | | | | 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.
* Remove the old platform-specific FCNTL.py modules; these are no longerFred Drake2001-05-0915-1993/+0
| | | | needed now that fcntl exports the constants.
* Add a new FCNTL.py backward compatibility module that issues a deprecationFred Drake2001-05-091-0/+14
| | | | warning. This is similar to the TERMIOS backward compatbility module.
* Update the tests for the fcntl module to check passing in file objects,Fred Drake2001-05-091-11/+21
| | | | and using the constants defined there instead of FCNTL.
* Trivial tests of urllib2 for recent SF bugJeremy Hylton2001-05-092-0/+18
|
* Raise useful exception when called with URL for which request typeJeremy Hylton2001-05-091-1/+2
| | | | | | cannot be determined. Pseudo-fix for SF bug #420724
* SF bug #422177: Results from .pyc differs from .pyTim Peters2001-05-081-0/+3
| | | | | | | | Store floats and doubles to full precision in marshal. Test that floats read from .pyc/.pyo closely match those read from .py. Declare PyFloat_AsString() in floatobject header file. Add new PyFloat_AsReprString() API function. Document the functions declared in floatobject.h.
* SF patch #421922: Implement rich comparison for dicts.Tim Peters2001-05-081-0/+28
| | | | | | d1 == d2 and d1 != d2 now work even if the keys and values in d1 and d2 don't support comparisons other than ==, and testing dicts for equality is faster now (especially when inequality obtains).
* SF patch 419176 from MvL; fixed bug 418977Jeremy Hylton2001-05-082-0/+21
| | | | Two errors in dict_to_map() helper used by PyFrame_LocalsToFast().
* This is a test showing SF bug 422177. It won't trigger until I check inTim Peters2001-05-081-0/+30
| | | | | | another change (to test_import.py, which simply imports the new file). I'm checking this piece in now, though, to make it easier to distribute a patch for x-platform checking.
* Generalize zip() to work with iterators.Tim Peters2001-05-062-2/+48
| | | | | | | | NEEDS DOC CHANGES. More AttributeErrors transmuted into TypeErrors, in test_b2.py, and, again, this strikes me as a good thing. This checkin completes the iterator generalization work that obviously needed to be done. Can anyone think of others that should be changed?
* Get rid of silly 5am "del" stmts.Tim Peters2001-05-051-2/+0
|
* Reimplement PySequence_Contains() and instance_contains(), so they workTim Peters2001-05-051-18/+6
| | | | | | | | | safely together and don't duplicate logic (the common logic was factored out into new private API function _PySequence_IterContains()). Visible change: some_complex_number in some_instance no longer blows up if some_instance has __getitem__ but neither __contains__ nor __iter__. test_iter changed to ensure that remains true.
* Generalize PySequence_Count() (operator.countOf) to work with iterators.Tim Peters2001-05-051-0/+35
|
* Make 'x in y' and 'x not in y' (PySequence_Contains) play nice w/ iterators.Tim Peters2001-05-052-2/+57
| | | | | | | | | | | | | NEEDS DOC CHANGES A few more AttributeErrors turned into TypeErrors, but in test_contains this time. The full story for instance objects is pretty much unexplainable, because instance_contains() tries its own flavor of iteration-based containment testing first, and PySequence_Contains doesn't get a chance at it unless instance_contains() blows up. A consequence is that some_complex_number in some_instance dies with a TypeError unless some_instance.__class__ defines __iter__ but does not define __getitem__.
* Make unicode.join() work nice with iterators. This also required a changeTim Peters2001-05-051-0/+41
| | | | | | | | to string.join(), so that when the latter figures out in midstream that it really needs unicode.join() instead, unicode.join() can actually get all the sequence elements (i.e., there's no guarantee that the sequence passed to string.join() can be iterated over *again* by unicode.join(), so string.join() must not pass on the original sequence object anymore).
* Generalize tuple() to work nicely with iterators.Tim Peters2001-05-053-6/+39
| | | | | | | | | | | | | | | | | | | | | NEEDS DOC CHANGES. This one surprised me! While I expected tuple() to be a no-brainer, turns out it's actually dripping with consequences: 1. It will *allow* the popular PySequence_Fast() to work with any iterable object (code for that not yet checked in, but should be trivial). 2. It caused two std tests to fail. This because some places used PyTuple_Sequence() (the C spelling of tuple()) as an indirect way to test whether something *is* a sequence. But tuple() code only looked for the existence of sq->item to determine that, and e.g. an instance passed that test whether or not it supported the other operations tuple() needed (e.g., __len__). So some things the tests *expected* to fail with an AttributeError now fail with a TypeError instead. This looks like an improvement to me; e.g., test_coercion used to produce 559 TypeErrors and 2 AttributeErrors, and now they're all TypeErrors. The error details are more informative too, because the places calling this were *looking* for TypeErrors in order to replace the generic tuple() "not a sequence" msg with their own more specific text, and AttributeErrors snuck by that.
* Generalize reduce() to work with iterators.Tim Peters2001-05-041-0/+13
| | | | NEEDS DOC CHANGES.
* Purge redundant cut&paste line.Tim Peters2001-05-031-2/+1
|
* Generalize map() to work with iterators.Tim Peters2001-05-031-0/+35
| | | | | | | | | | | NEEDS DOC CHANGES. Possibly contentious: The first time s.next() yields StopIteration (for a given map argument s) is the last time map() *tries* s.next(). That is, if other sequence args are longer, s will never again contribute anything but None values to the result, even if trying s.next() again could yield another result. This is the same behavior map() used to have wrt IndexError, so it's the only way to be wholly backward-compatible. I'm not a fan of letting StopIteration mean "try again later" anyway.
* Remove redundant copy+paste code.Tim Peters2001-05-031-3/+0
|