summaryrefslogtreecommitdiffstats
Commit message (Collapse)AuthorAgeFilesLines
* Generalize PySequence_Count() (operator.countOf) to work with iterators.Tim Peters2001-05-053-15/+70
|
* 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-055-33/+94
| | | | | | | | | | | | | 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-054-13/+65
| | | | | | | | 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.
* Fix a tiny and unlikely memory leak. Was there before too, and actuallyTim Peters2001-05-051-1/+3
| | | | several of these turned up and got fixed during the iteration crusade.
* Generalize tuple() to work nicely with iterators.Tim Peters2001-05-056-49/+89
| | | | | | | | | | | | | | | | | | | | | 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.
* Make PyIter_Next() a little smarter (wrt its knowledge of iteratorTim Peters2001-05-054-66/+35
| | | | internals) so clients can be a lot dumber (wrt their knowledge).
* Make the license GPL-compatible.Guido van Rossum2001-05-041-16/+5
|
* 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-043-12/+33
| | | | NEEDS DOC CHANGES.
* Purge redundant cut&paste line.Tim Peters2001-05-031-2/+1
|
* Generalize map() to work with iterators.Tim Peters2001-05-033-66/+104
| | | | | | | | | | | 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.
* The weakref support in PyObject_InitVar() as well; this should have come outFred Drake2001-05-031-4/+0
| | | | at the same time as it did from PyObject_Init() .
* Remove unnecessary intialization for the case of weakly-referencable objects;Fred Drake2001-05-031-4/+0
| | | | | | | the code necessary to accomplish this is simpler and faster if confined to the object implementations, so we only do this there. This causes no behaviorial changes beyond a (very slight) speedup.
* Remove an obsolete comment and a "return" before fallig off the end of aFred Drake2001-05-031-2/+0
| | | | void function.
* Since Py_TPFLAGS_HAVE_WEAKREFS is set in Py_TPFLAGS_DEFAULT, it does notFred Drake2001-05-032-21/+21
| | | | | | | need to be specified in the type structures independently. The flag exists only for binary compatibility. This is a "source cleanliness" issue and introduces no behavioral changes.
* Remove redundant copy+paste code.Tim Peters2001-05-031-3/+0
|
* Generalize max(seq) and min(seq) to work with iterators.Tim Peters2001-05-033-15/+61
| | | | NEEDS DOC CHANGES.
* InteractiveInterpreter.showsyntaxerror():Fred Drake2001-05-031-0/+1
| | | | | When replacing the exception object, be sure we stuff the new value in sys.last_value (which we already did for the original value).
* Added support for .__contains__(), .__iter__(), .iterkeys().Fred Drake2001-05-031-1/+8
|
* Added support for .iteritems(), .iterkeys(), .itervalues().Fred Drake2001-05-031-0/+3
|
* The general iteration support is part of 2.2, not 2.1 -- fixed the versionFred Drake2001-05-032-2/+3
| | | | | | annotations! Also fixed a typo noted by Neil S.
* Add documentation for the StopIteration exception.Fred Drake2001-05-031-0/+8
|
* State that Mailbox objects are iterator objects.Fred Drake2001-05-021-2/+2
|
* Make the Mailbox objects support iteration -- they already had theFred Drake2001-05-021-0/+9
| | | | | appropriate next() method, and this is what people really want to do with these objects in practice.
* Update the filter() and list() descriptions to include information aboutFred Drake2001-05-021-12/+14
| | | | the support for containers and iteration.
* Added section describing the iterator protocol.Fred Drake2001-05-021-0/+51
|
* Added new parser markers 'et' and 'et#' which do not recode stringMarc-André Lemburg2001-05-022-4/+32
| | | | | | | objects but instead assume that they use the requested encoding. This is needed on Windows to enable opening files by passing in Unicode file names.
* Mchael Hudson pointed out that the code for detecting changes inGuido van Rossum2001-05-021-4/+4
| | | | | | dictionary size was comparing ma_size, the hash table size, which is always a power of two, rather than ma_used, wich changes on each insertion or deletion. Fixed this.
* Fix for bug #417030: "print '%*s' fails for unicode string"Marc-André Lemburg2001-05-022-2/+9
|
* Generalize filter(f, seq) to work with iterators. This also generalizesTim Peters2001-05-023-48/+107
| | | | | filter() to no longer insist that len(seq) be defined. NEEDS DOC CHANGES.
* Plug a memory leak in list(), when appending to the result list.Tim Peters2001-05-021-5/+9
|
* Whitespace normalization.Tim Peters2001-05-022-3/+3
|
* Added tests for Weak*Dictionary iterator support.Fred Drake2001-05-021-10/+54
| | | | Refactored some object initialization to be more reusable.
* Added iterator support to the Weak*Dictionary classes.Fred Drake2001-05-021-0/+73
|
* Add more news about iterators.Guido van Rossum2001-05-011-0/+12
|
* Generalize list(seq) to work with iterators. This also generalizes list()Tim Peters2001-05-013-31/+99
| | | | | | | | | | | | | to no longer insist that len(seq) be defined. NEEDS DOC CHANGES. This is meant to be a model for how other functions of this ilk (max, filter, etc) can be generalized similarly. Feel encouraged to grab your favorite and convert it! Note some cute consequences: list(file) == file.readlines() == list(file.xreadlines()) list(dict) == dict.keys() list(dict.iteritems()) = dict.items() list(xrange(i, j, k)) == range(i, j, k)
* Discard a misleading comment about iter_iternext().Guido van Rossum2001-05-011-1/+0
|
* Printing objects to a real file still wasn't done right: if theGuido van Rossum2001-05-011-32/+14
| | | | | | | | | | | | | | | | | | | object's type didn't define tp_print, there were still cases where the full "print uses str() which falls back to repr()" semantics weren't honored. This resulted in >>> print None <None object at 0x80bd674> >>> print type(u'') <type object at 0x80c0a80> Fixed this by always using the appropriate PyObject_Repr() or PyObject_Str() call, rather than trying to emulate what they would do. Also simplified PyObject_Str() to always fall back on PyObject_Repr() when tp_str is not defined (rather than making an extra check for instances with a __str__ method). And got rid of the special case for strings.
* Add a proper implementation for the tp_str slot (returning self, ofGuido van Rossum2001-05-011-1/+8
| | | | | course), so I can get rid of the special case for strings in PyObject_Str().
* Add experimental iterkeys(), itervalues(), iteritems() to dictGuido van Rossum2001-05-011-11/+85
| | | | | | | objects. Tests show that iteritems() is 5-10% faster than iterating over the dict and extracting the value with dict[key].
* Well darnit! The innocuous fix I made to PyObject_Print() causedGuido van Rossum2001-04-301-1/+20
| | | | printing of instances not to look for __str__(). Fix this.
* SF bug #417093: Case sensitive import: dir and .py file w/ same nameTim Peters2001-04-291-8/+5
| | | | | | | | | | | | | | | | Directory containing Spam.py spam/__init__.py Then "import Spam" caused a SystemError, because code checking for the existence of "Spam/__init__.py" finds it on a case-insensitive filesystem, but then bails because the directory it finds it in doesn't match case, and then old code assumed that was still an error even though it isn't anymore. Changed the code to just continue looking in this case (instead of calling it an error). So import Spam and import spam both work now.
* Fix buglet reported on c.l.py: map(fnc, file.xreadlines()) blows up.Tim Peters2001-04-281-9/+19
| | | | | | | | | Also a 2.1 bugfix candidate (am I supposed to do something with those?). Took away map()'s insistence that sequences support __len__, and cleaned up the convoluted code that made it *look* like it really cared about __len__ (in fact the old ->len field was only *used* as a flag bit, as the main loop only looked at its sign bit, setting the field to -1 when IndexError got raised; renamed the field to ->saw_IndexError instead).
* A different approach to the problem reported inTim Peters2001-04-282-37/+54
| | | | | | | | | | | Patch #419651: Metrowerks on Mac adds 0x itself C std says %#x and %#X conversion of 0 do not add the 0x/0X base marker. Metrowerks apparently does. Mark Favas reported the same bug under a Compaq compiler on Tru64 Unix, but no other libc broken in this respect is known (known to be OK under MSVC and gcc). So just try the damn thing at runtime and see what the platform does. Note that we've always had bugs here, but never knew it before because a relevant test case didn't exist before 2.1.
* (Adding this to the trunk as well.)Guido van Rossum2001-04-271-1/+4
| | | | | | | | Fix a very old flaw in PyObject_Print(). Amazing! When an object type defines tp_str but not tp_repr, 'print x' to a real file object would not call the tp_str slot but rather print a default style representation: <foo object at 0x....>. This even though 'print x' to a file-like-object would correctly call the tp_str slot.
* Got rid of the whole event filtering mess again, I can't get it to work. ↵Jack Jansen2001-04-271-23/+1
| | | | Simply disabling the Tk event handling hook in _tkinter is not as nice, but at least it works.
* Fix 2.1 nested scopes crash reported by Evan SimpsonJeremy Hylton2001-04-273-6/+32
| | | | | | | | The new test case demonstrates the bug. Be more careful in symtable_resolve_free() to add a var to cells or frees only if it won't be added under some other rule. XXX Add new assertion that will catch this bug.
generated by cgit v0.12 at 2025-03-02 07:48:54 (GMT)