This is my first time on any mailing list... Please point out any mistakes..
I had a suggestion about the implementation of
unittest.TestCase.assert* methods. They all call failureException
separately. This is also what the unittest.TestCase.fail method does.
Is there any specific reason it is so?
If not, then is there any reason stopping them from calling the
unittest.TestCase.fail method? As then we have one point where all the
tests fail meaning that one can reimplement the unittest.TestCase.fail
method for handling test failures in their own custom way.
05.03.14 17:24, kristjan.jonsson написав(ла):
> changeset: 89477:3b2c28061184
> branch: 3.3
> parent: 89475:24d4e52f4f87
> user: Kristján Valur Jónsson <sweskman(a)gmail.com>
> date: Wed Mar 05 13:47:57 2014 +0000
> Make the various iterators' "setstate" sliently and consistently clip the
> index. This avoids the possibility of setting an iterator to an invalid
Why indexes are silently clipped instead of raising an exception?
> Lib/test/test_range.py | 12 ++++++++++
> Modules/arraymodule.c | 2 +
> Objects/bytearrayobject.c | 10 ++++++--
> Objects/bytesobject.c | 10 ++++++--
> Objects/listobject.c | 2 +
> Objects/rangeobject.c | 31 +++++++++++++++++++++++---
> Objects/tupleobject.c | 4 +-
> Objects/unicodeobject.c | 10 ++++++--
> 8 files changed, 66 insertions(+), 15 deletions(-)
And it would be better first discuss and review such large changes on
Python 3 now stores the traceback object in Exception.__traceback__
and exceptions can be chained through Exception.__context__. It's
convinient but it introduced tricky reference cycles if the exception
object is used out of the except block.
Refrences: Exception.__traceback__ -> traceback -> frames -> local variables
Exception.__traceback__ keeps strong references to local variables
which will only be deleted after the exception is destroyed.
It becomes worse if the exception is stored in an object which is also
a local variables somewhere in the traceback:
DebugObject -> Exception -> ... frame -> DebugObject
For a concrete example of object storing an exception, see
Future.set_exception() of the ayncio module.
Python 3.4 introduced frame.clear(), but frame.clear() raises an
RuntimeError if the frame is still running. And it doesn't break all
An obvious workaround is to store the traceback as text, but this
operation is "expensive" especially if the traceback is only needed in
I tried to write "views" of the traceback (and frames), but
Exception.__traceback__ rejects types other than traceback and
traceback instances cannot be created. It's possible to store the
traceback somewhere else and set Exception.__traceback__ to None, but
there is still the problem with chained exceptions.
Any idea for a generic fix to such problem?
Another workaround is to set Exception.__traceback__ to None in
release mode, and leaves it unchanged in debug mode. But it's not a
good solution because bugs also occur in production, and most tricky
bugs *only* occur in production :-)
For more info, see:
It's published here:
There's also a tarball at the old web site:
However, the "merge.status.html" page is broken. I'm not going to
bother to fix it, instead please just look at the hg repo above. I
think part of the problem is that some revisions I had to manually patch
in (instead of grafting) wound up with my name instead of the original
core dev's name, so the translation between the 3.4 and default branches
Anyway, it locally builds and runs tests without errors.
Suppose a 2.7 standard library function is documented as taking a
'string' argument, such as these examples from the turtle module.
Set pencolor to colorstring, which is a Tk color specification
string, such as "red", "yellow", or "#33cc8c".
Parameters: name – a string which is a valid shapename
class turtle.Shape(type_, data)
Parameters: type_ – one of the strings “polygon”, “image”, “compound”
from __future__ import unicode_literals
to a working program causes an exception, such as with turtle
(Note: unicode_literals is not indexed.)
Is this a programmer error for passing unicode instead of string, or a
library error for not accepting unicode?
Is changing 'isinstance(x, str)' in the library (with whatever other
changes are needed) a bugfix to be pushed or a prohibited API expansion?
Terry Jan Reedy
The discussion on http://bugs.python.org/issue20440 started me thinking that much of this
bikeshedding could be avoided if we weren't constrained to writing macros for all of this stuff.
For example, a
Py_INLINE(PyObject *) Py_Incref(PyObject *obj)
could be used in a Py_Assign() function, if a new reference were wanted:
Py_INLINE(void) Py_Assign(PyObject ** target, PyObject *obj)
PyObject *tmp = *target;
*target = tmp;
So that you could then safely write code like
This would also allow you to stop writing various super macros to try to cater to all possible permutations.
Now, Larry Hastings pointed out that we support C89 which doesn't support Inlines. Rather than suggesting here that we update that compatibility requirement,
how about adding a Py_INLINE() macro.? This would be like Py_LOCAL_INLINE() except that it would drop the "static" keyword, unless inline isn't supported:
#define Py_INLINE(type) __inline type
#define Py_INLINE(type) inline type
#define Py_INLINE(type) static type
The only question is with the last line. How many platforms actually _do_not_ have inlines? Would writing stuff like this be considered problematic for those platforms? Note, that I'm not suggesting replacing macros all over the place, only for new code.
Another question is: Is "static inline" in any practical way different from "inline"?
It would be great to get rid of macros in code. It would be great for debugging too!
-----BEGIN PGP SIGNED MESSAGE-----
On behalf of the Python development team, I'm happy to announce
the release of Python 3.3.5, release candidate 2.
Python 3.3.5 includes a fix for a regression in zipimport in 3.3.4
(see http://bugs.python.org/issue20621) and a few other bugs.
Python 3.3 includes a range of improvements of the 3.x series, as well
as easier porting between 2.x and 3.x. In total, almost 500 API items
are new or improved in Python 3.3. For a more extensive list of
changes in the 3.3 series, see
To download Python 3.3.5 visit:
This is a preview release, please report any bugs to
The final release is scheduled one week from now.
Georg Brandl, Release Manager
georg at python.org
(on behalf of the entire python-dev team and 3.3's contributors)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (GNU/Linux)
-----END PGP SIGNATURE-----