Hi,
A friend of mine, Ruadhan O'Flanagan, came across a bug which turned out
to be the one noted in [http://bugs.python.org/issue18019], i.e.:
>>> d={}
>>> d[42]=d.viewvalues()
>>> d
<segmentation fault>
This issue has been fixed in hg; the behaviour now is that a
RuntimeError is produced for a recursive dictionary view:
>>> d={}
>>> d[42]=d.viewvalues()
>>> d # (output line-broken:)
{42: Traceback (most recent call last):
File "<stdin>", line 1, in <module>
RuntimeError: maximum recursion depth exceeded
while getting the repr of a list
Before finding this, though, I'd investigated and made a patch which
produces a similar "..." output to a recursive dictionary. Reworking
against current 2.7, the behaviour would be:
>>> x={}
>>> x[42]=x
>>> x # existing behaviour for dictionaries:
{42: {...}}
>>> d={}
>>> d[42]=d.viewvalues()
>>> d # new behaviour:
{42: dict_values([...])}
>>> d[43]=d.viewitems()
>>> d # (output line-broken:)
{42: dict_values([..., dict_items([(42, ...), (43, ...)])]),
43: dict_items([(42, dict_values([..., ...])), (43, ...)])}
Attached is the patch, against current 2.7 branch. If there is interest
in applying this, I will create a proper patch (changelog entry, fix to
Lib/test/test_dictviews.py, etc.).
Thanks,
Ben.
[re-sending to python-dev]
On 7/21/2013 4:27 PM, benjamin.peterson wrote:
> @@ -267,7 +267,7 @@
> Py_DECREF(io);
> Py_DECREF(binary);
> PyMem_FREE(found_encoding);
> - return PyErr_SetFromErrnoWithFilenameObject(PyExc_IOError, filename);
> + return 0;
> }
> fob = _PyObject_CallMethodId(io, &PyId_TextIOWrapper, "Os", binary, encoding);
> Py_DECREF(io);
Did you mean to remove the call to PyErr_SetFromErrnoWithFilenameObject?
Or just call it, then ignore its return value and return 0?
--
Eric.
_______________________________________________
Python-checkins mailing list
Python-checkins(a)python.org
http://mail.python.org/mailman/listinfo/python-checkins
While working on issue #18508 I stumbled across this:
Traceback (most recent call last):
...
File "/usr/local/lib/python3.4/enum.py", line 417, in __new__
if value in cls._value2member_map:
TypeError: unhashable type: 'list'
I'll wrap it in a try-except block, but I must admit I was surprised the answer wasn't False. After all, if the input
is unhashable then obviously it's not in the dict; furthermore, if I were to compare the number 5 with a set() I would
get False, not a TypeMismatch error, and dict keys are basically done by equality, the hash is just (?) a speed-up.
--
~Ethan~
In article <51ECAE41.5060403(a)udel.edu>, Terry Reedy <tjreedy(a)udel.edu>
wrote:
> On 7/21/2013 10:11 PM, R. David Murray wrote:
> > On Mon, 22 Jul 2013 02:13:47 +0200, terry.reedy
> > <python-checkins(a)python.org> wrote:
> >> +# If buildbot improperly sets gui resource (#18365, #18441), remove it
> >> +# so requires('gui') tests are skipped while non-gui tests still run.
> >> +if use_resources and 'gui' in use_resources:
> >
> > Note that the buildbot cannot "improperly" set the GUI resource.
>
> I disagree. I do understand though, that what I call improper setting on
> the command line cannot be prevented. So I think regrtest (and unittest
> if and when it supports resources) should intercept 'gui', test once and
> for all whether it was set 'properly' (or 'appropriately', if you
> prefer), which is to say, test whether there is a usable GUI, and ignore
> 'gui' if not.
>
> > Setting a resource on the regrtest command line says "please try to run
> > these tests".
Right.
> When doing so causes a failure at best and a crash at worst, and those
> consequences and the means of avoiding them are not documented, that is
> not a very considerate request. It has cost me over a day of my life.
Unfortunately, that's the way regrtest resources work.
> The printed out -h help says
> "gui - Run tests that require a running GUI."
> Not 'try', but 'run'. That implies to me that there *is* 'a running GUI'
> and that is it all right to run tests that *require* such. That was also
> what I understood from the discussion on
> http://bugs.python.org/issue18103 Create a GUI test framework for Idle
This is exactly what Issue8716 was about. The buildbot has no way of
knowing ahead of time whether a test will cause a crash or not. Yes, Tk
should not crash but it does in some cases. Speaking of #8716, that
reminds me that there is an open issue with it (documented in
Issue17496). There is the start of a patch there to use a more general
approach to testing for a working Tk that might be applicable on all
platforms.
--
Ned Deily,
nad(a)acm.org
On Mon, 22 Jul 2013 02:13:47 +0200, terry.reedy <python-checkins(a)python.org> wrote:
> +# If buildbot improperly sets gui resource (#18365, #18441), remove it
> +# so requires('gui') tests are skipped while non-gui tests still run.
> +if use_resources and 'gui' in use_resources:
Note that the buildbot cannot "improperly" set the GUI resource.
Setting a resource on the regrtest command line says "please try to run
these tests". If they can't be run, they should then be skipped for
whatever reason they can't run.
--David