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.
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).
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.
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?
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.
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__.
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).
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.
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.
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)
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.
of ParserCreate().
Added assignment tests for the ordered_attributes and specified_attributes
values, similar to the checks for the returns_unicode attribute.
Obviously bad regexps, spotted by Jeffery Collins.
HELP! I can't run this on Windows, and the module test() function
probably doesn't work on anyone's box. Could a Unixoid please write
an at least minimal working test and add it to the std test suite?
new slot tp_iter in type object, plus new flag Py_TPFLAGS_HAVE_ITER
new C API PyObject_GetIter(), calls tp_iter
new builtin iter(), with two forms: iter(obj), and iter(function, sentinel)
new internal object types iterobject and calliterobject
new exception StopIteration
new opcodes for "for" loops, GET_ITER and FOR_ITER (also supported by dis.py)
new magic number for .pyc files
new special method for instances: __iter__() returns an iterator
iteration over dictionaries: "for x in dict" iterates over the keys
iteration over files: "for x in file" iterates over lines
TODO:
documentation
test suite
decide whether to use a different way to spell iter(function, sentinal)
decide whether "for key in dict" is a good idea
use iterators in map/filter/reduce, min/max, and elsewhere (in/not in?)
speed tuning (make next() a slot tp_next???)
I know some people don't like this -- if it's really controversial,
I'll take it out again. (If it's only Alex Martelli who doesn't like
it, that doesn't count as "real controversial" though. :-)
That's why this is a separate checkin from the iterators stuff I'm
about to check in next.
Weak*Dictionary.update(): No longer create a temporary list to hold the
things that will be stuffed into the underlying dictionary. This had
been done so that if any of the objects used as the weakly-held value
was not weakly-referencable, no updates would take place (TypeError
would be raised). With this change, TypeError will still be raised
but a partial update could occur. This is more like other .update()
implementations.
Thoughout, use of the name "ref" as a local variable has been removed. The
original use of the name occurred when the function to create a weak
reference was called "new"; the overloaded use of the name could be
confusing for someone reading the code. "ref" used as a variable name
has been replaced with "wr" (for 'weak reference').
The changes cause compilation failures in any file in the Python
installation lib directory to cause the install to fail. It looks
like compileall.py intended to behave this way, but a change to
py_compile.py and a separate bug defeated it.
Fixes SF bug #412436
This change affects the test suite, which contains several files that
contain intentional errors. The solution is to extend compileall.py
with the ability to skip compilation of selected files.
NB compileall.py is changed so that compile_dir() returns success only
if all recursive calls to compile_dir() also check success.
The changes cause compilation failures in any file in the Python
installation lib directory to cause the install to fail. It looks
like compileall.py intended to behave this way, but a change to
py_compile.py and a separate bug defeated it.
Fixes SF bug #412436
This change affects the test suite, which contains several files that
contain intentional errors. The solution is to extend compileall.py
with the ability to skip compilation of selected files.
In the test suite, rename nocaret.py and test_future[3..7].py to start
with badsyntax_nocaret.py and badsyntax_future[3..7].py. Update the
makefile to skip compilation of these files. Update the tests to use
the name names for imports.
NB compileall.py is changed so that compile_dir() returns success only
if all recursive calls to compile_dir() also check success.
file was deleted by a previous call to the visitor function.
This used to be the behavior in 1.5.2 and before, but a patch to avoid
making two stat() calls accidentally broke this in 2.0.
Moshe, this would be a good one for 2.0.1 too!
its first return statement returns a single value while its caller
always expects it to return a tuple of two items. Fix this by
returning (s, 0) instead.
This won't make the locale test on Irix succeed, but now it will fail
because of a bug in the platform's en_US locale rather than because of
a bug in the locale module.
than from module pickletester. Using the latter turned out to cause
the test to break when invoked as "import test.test_pickle" or "import
test.autotest".
