summaryrefslogtreecommitdiffstats
path: root/Misc
Commit message (Collapse)AuthorAgeFilesLines
* Add xmlrpc.Guido van Rossum2001-07-121-0/+5
| | | | | | | (Tim & I should agree on where to add new additions: I add them at the top, Tim adds them at the bottom. I like the top better because folks who occasionally check out the NEWS file will see the latest news first.)
* (py-version): Hopefully fixed my XEmacs settings so this doesn't getBarry Warsaw2001-07-061-1/+1
| | | | clobbered on checkin.
* (py-continuation-offset): Update docstring to describe that thisBarry Warsaw2001-07-061-4/+9
| | | | | | | | additional offset is only applied to continuation lines for block opening statements. (py-compute-indentation): Only add py-continuation-offset if py-statement-opens-block-p is true.
* News about xrange().Guido van Rossum2001-07-051-0/+4
|
* Replace the text with a link to the PEP-ified version.Barry Warsaw2001-06-271-1113/+3
|
* Add an item about the extension to {}.update() to allow genericBarry Warsaw2001-06-261-0/+5
| | | | mapping objects as an argument.
* Teach the UNPACK_SEQUENCE opcode how to tease an iterable object intoTim Peters2001-06-211-0/+2
| | | | | giving up the goods. NEEDS DOC CHANGES
* (python-font-lock-keywords): Add "yield" as a keyword to support theBarry Warsaw2001-06-191-2/+2
| | | | new "simple generators" feature of 2.2. See PEP 255.
* (py-continuation-offset): New variable which controls how much toBarry Warsaw2001-06-181-3/+12
| | | | | | | indent continuation lines, defined as lines following those that end in backslash. (py-compute-indentation): Support for py-continuation-offset.
* Clarification in the fp appendix suggested on c.l.py by Michael Chermside.Tim Peters2001-06-171-0/+1
| | | | | Also replaced a *star* style emphasis in the Representation Error section with an \emph{} thingie.
* Reformat decl of new _PyString_Join. Add NEWS blurb about repr() speedup.Tim Peters2001-06-161-0/+3
|
* Add new built-in 'help' which invokes pydoc.help (with a twist).Guido van Rossum2001-06-121-0/+5
|
* Added q/Q standard (x-platform 8-byte ints) mode in struct module.Tim Peters2001-06-121-3/+6
| | | | | | | | | | | | | | This completes the q/Q project. longobject.c _PyLong_AsByteArray: The original code had a gross bug: the most-significant Python digit doesn't necessarily have SHIFT significant bits, and you really need to count how many copies of the sign bit it has else spurious overflow errors result. test_struct.py: This now does exhaustive std q/Q testing at, and on both sides of, all relevant power-of-2 boundaries, both positive and negative. NEWS: Added brief dict news while I was at it.
* Initial support for 'q' and 'Q' struct format codes: for now, only inTim Peters2001-06-101-0/+8
| | | | | | | | | | | | | | | | | | native mode, and only when config #defines HAVE_LONG_LONG. Standard mode will eventually treat them as 8-byte ints across all platforms, but that likely requires a new set of routines in longobject.c first (while sizeof(long) >= 4 is guaranteed by C, there's nothing in C we can rely on x-platform to hold 8 bytes of int, so we'll have to roll our own; I'm thinking of a simple pair of conversion functions, Python long to/from sized vector of unsigned bytes; that may be useful for GMP conversions too; std q/Q would call them with size fixed at 8). test_struct.py: In addition to adding some native-mode 'q' and 'Q' tests, got rid of unused code, and repaired a non-portable assumption about native sizeof(short) (it isn't 2 on some Cray boxes). libstruct.tex: In addition to adding a bit of 'q'/'Q' docs (more needed later), removed an erroneous footnote about 'I' behavior.
* SF bug 430991: wrong co_lnotabTim Peters2001-06-091-0/+1
| | | | | | | | | Armin Rigo pointed out that the way the line-# table got built didn't work for lines generating more than 255 bytes of bytecode. Fixed as he suggested, plus corresponding changes to pyassem.py, plus added some long overdue docs about this subtle table to compile.c. Bugfix candidate (line numbers may be off in tracebacks under -O).
* Added quopri codec.Guido van Rossum2001-06-061-0/+1
|
* Report on fnmatch.filter.Martin v. Löwis2001-06-061-0/+2
|
* Separate CFLAGS and CPPFLAGS. CFLAGS should not contain preprocessorNeil Schemenauer2001-06-021-2/+3
| | | | directives, which is the role of CPPFLAGS. Closes SF patch #414991.
* New collision resolution scheme: no polynomials, simpler, faster, lessTim Peters2001-06-021-8/+6
| | | | | | | code, less memory. Tests have uncovered no drawbacks. Christian and Vladimir are the other two people who have burned many brain cells on the dict code in recent years, and they like the approach too, so I'm checking it in without further ado.
* Cruft cleanup: Removed the unused last_is_sticky argument from the internalTim Peters2001-05-281-0/+6
| | | | _PyTuple_Resize().
* Implement an old idea of Christian Tismer's: use polynomial divisionTim Peters2001-05-271-0/+8
| | | | | | | | | | | | | | | instead of multiplication to generate the probe sequence. The idea is recorded in Python-Dev for Dec 2000, but that version is prone to rare infinite loops. The value is in getting *all* the bits of the hash code to participate; and, e.g., this speeds up querying every key in a dict with keys [i << 16 for i in range(20000)] by a factor of 500. Should be equally valuable in any bad case where the high-order hash bits were getting ignored. Also wrote up some of the motivations behind Python's ever-more-subtle hash table strategy.
* Change list.extend() error msgs and NEWS to reflect that list.extend()Tim Peters2001-05-261-1/+2
| | | | | | | now takes any iterable argument, not only sequences. NEEDS DOC CHANGES -- but I don't think we settled on a concise way to say this stuff.
* - calendar.py uses month and day names based on the current locale.Barry Warsaw2001-05-221-0/+2
|
* Added NEWS item for the UTF-16 change.Marc-André Lemburg2001-05-221-0/+5
|
* Add NEWS item for new string methods.Marc-André Lemburg2001-05-151-0/+25
|
* Add warnings to the strop module, for to those functions that reallyGuido van Rossum2001-05-151-0/+4
| | | | | | | | | *are* obsolete; three variables and the maketrans() function are not (yet) obsolete. Add a compensating warnings.filterwarnings() call to test_strop.py. Add this to the NEWS.
* SF patch #418147 Fixes to allow compiling w/ Borland, from Stephen Hansen.Tim Peters2001-05-141-0/+4
|
* pprint's workhorse _safe_repr() function took time quadratic in the # ofTim Peters2001-05-141-1/+4
| | | | | | | 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.
* Fix a typo, consistently spell ASCII in all caps, and insert blankGuido van Rossum2001-05-141-2/+4
| | | | | lines between paragraphs in Mark Hammond's news item about the default encoding in posixmodule. Resist the temptation to reflow paragraphs.
* SF bug[ #423781: pprint.isrecursive() broken.Tim Peters2001-05-141-7/+25
|
* Add mention of the default file system encoding for Windows.Mark Hammond2001-05-141-0/+17
|
* Get rid of the superstitious "~" in dict hashing's "i = (~hash) & mask".Tim Peters2001-05-131-0/+10
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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.
* Variant of patch #423262: Change module attribute get & setTim Peters2001-05-111-0/+3
| | | | | | Allow module getattr and setattr to exploit string interning, via the previously null module object tp_getattro and tp_setattro slots. Yields a very nice speedup for things like random.random and os.path etc.
* SF bug #422121 Insecurities in dict comparison.Tim Peters2001-05-101-0/+5
| | | | | | | 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.
* Blurb about the increased precision of float literals in .pyc/.pyo files.Tim Peters2001-05-081-0/+20
|
* SF patch #421922: Implement rich comparison for dicts.Tim Peters2001-05-081-2/+4
| | | | | | 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).
* Generalize zip() to work with iterators.Tim Peters2001-05-061-8/+4
| | | | | | | | 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?
* Generalize PySequence_Count() (operator.countOf) to work with iterators.Tim Peters2001-05-051-2/+4
|
* Remove redundant line.Tim Peters2001-05-051-1/+0
|
* Make 'x in y' and 'x not in y' (PySequence_Contains) play nice w/ iterators.Tim Peters2001-05-051-2/+2
| | | | | | | | | | | | | 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-1/+1
| | | | | | | | 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).
* Mark string.join() as done. Turns out string_join() works "for free" now,Tim Peters2001-05-051-1/+2
| | | | | | because PySequence_Fast() started working for free as soon as PySequence_Tuple() learned how to work with iterators. For some reason unicode.join() still doesn't work, though.
* Generalize tuple() to work nicely with iterators.Tim Peters2001-05-051-2/+2
| | | | | | | | | | | | | | | | | | | | | 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.
* Add TODO item about x in y -- this should use iterators too, IMO.Guido van Rossum2001-05-041-0/+1
|
* Added reminders to make some remaining functions iterator-friendly. FeelTim Peters2001-05-041-1/+3
| | | | free to do one!
* Generalize reduce() to work with iterators.Tim Peters2001-05-041-0/+1
| | | | NEEDS DOC CHANGES.
* Generalize map() to work with iterators.Tim Peters2001-05-031-0/+1
| | | | | | | | | | | 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.
* Generalize max(seq) and min(seq) to work with iterators.Tim Peters2001-05-031-0/+2
| | | | NEEDS DOC CHANGES.
* Generalize filter(f, seq) to work with iterators. This also generalizesTim Peters2001-05-021-8/+9
| | | | | filter() to no longer insist that len(seq) be defined. NEEDS DOC CHANGES.
* Add more news about iterators.Guido van Rossum2001-05-011-0/+12
|
generated by cgit v0.12 at 2024-11-25 18:56:26 (GMT)