Início / coding / Perguntas / 78427983
Accepted
Waket Zheng
Asked: 2024-05-04 14:19:19 +0800 CST

Por que `dict(id=1, **{'id': 2})` às vezes gera `KeyError: 'id'` em vez de um TypeError?

  • 772

Normalmente, se você tentar passar vários valores para o mesmo argumento de palavra-chave, obterá um TypeError:

In [1]: dict(id=1, **{'id': 2})
---------------------------------------------------------------------------
TypeError                                 Traceback (most recent call last)
Input In [1], in <cell line: 1>()
----> 1 dict(id=1, **{'id': 2})

TypeError: dict() got multiple values for keyword argument 'id'

Mas se você fizer isso enquanto lida com outra exceção , você receberá um KeyError:

In [2]: try:
   ...:     raise ValueError('foo') # no matter what kind of exception
   ...: except:
   ...:     dict(id=1, **{'id': 2}) # raises: KeyError: 'id'
   ...: 
---------------------------------------------------------------------------
ValueError                                Traceback (most recent call last)
Input In [2], in <cell line: 1>()
      1 try:
----> 2     raise ValueError('foo') # no matter what kind of exception
      3 except:

ValueError: foo

During handling of the above exception, another exception occurred:

KeyError                                  Traceback (most recent call last)
Input In [2], in <cell line: 1>()
      2     raise ValueError('foo') # no matter what kind of exception
      3 except:
----> 4     dict(id=1, **{'id': 2})

KeyError: 'id'

O que está acontecendo aqui? Como uma exceção completamente não relacionada poderia afetar o tipo de exceção dict(id=1, **{'id': 2})lançada?

Para contextualizar, descobri esse comportamento ao investigar o seguinte relatório de bug: https://github.com/tortoise/tortoise-orm/issues/1583

Isso foi reproduzido no CPython 3.11.8, 3.10.5 e 3.9.5.

python

1 respostas

  1. Best Answer

    Isso parece um bug do Python.

    O código que deveria aumentar TypeErrorfunciona detectando e substituindo um inicial KeyError, mas esse código não funciona direito. Quando a exceção ocorre no meio de outro manipulador de exceção, o código que deveria gerar o TypeErrorarquivo KeyError. Acaba deixando passar KeyError, em vez de substituí-lo por um arquivo TypeError.

    O bug parece ter desaparecido na versão 3.12, devido a mudanças na implementação da exceção.

    Aqui está o aprofundamento do código-fonte do CPython 3.11.8. Código semelhante existe em 3.10 e 3.9.

    Como podemos ver usando o dismódulo para examinar o bytecode para dict(id=1, **{'id': 2}):

    In [1]: import dis

In [2]: dis.dis("dict(id=1, **{'id': 2})")
  1           0 LOAD_NAME                0 (dict)
              2 LOAD_CONST               3 (())
              4 LOAD_CONST               0 ('id')
              6 LOAD_CONST               1 (1)
              8 BUILD_MAP                1
             10 LOAD_CONST               0 ('id')
             12 LOAD_CONST               2 (2)
             14 BUILD_MAP                1
             16 DICT_MERGE               1
             18 CALL_FUNCTION_EX         1
             20 RETURN_VALUE

    Python usa o DICT_MERGEopcode para mesclar dois dictos, para construir o dict do argumento da palavra-chave final.

    A parte relevante do DICT_MERGE código é a seguinte:

                if (_PyDict_MergeEx(dict, update, 2) < 0) {
                format_kwargs_error(tstate, PEEK(2 + oparg), update);
                Py_DECREF(update);
                goto error;
            }

    Ele tenta _PyDict_MergeExmesclar dois dictos e, se isso falhar (e gerar uma exceção), ele tenta format_kwargs_errorgerar uma exceção diferente .

    Quando o terceiro argumento _PyDict_MergeExfor 2, essa função gerará um KeyErrorpara chaves duplicadas, dentro da dict_mergefunção auxiliar. É daí que KeyErrorvem.

    Uma vez que o KeyErroré gerado, format_kwargs_errortem a função de substituí-lo por um TypeError. Ele tenta fazer isso com o seguinte código :

        else if (_PyErr_ExceptionMatches(tstate, PyExc_KeyError)) {
        PyObject *exc, *val, *tb;
        _PyErr_Fetch(tstate, &exc, &val, &tb);
        if (val && PyTuple_Check(val) && PyTuple_GET_SIZE(val) == 1) {

    mas este código está procurando uma exceção não normalizada , uma forma interna de representar exceções que não está exposta ao código em nível Python. Ele espera que o valor da exceção seja uma tupla de 1 elemento contendo a chave para a qual KeyError foi gerado, em vez de um objeto de exceção real.

    Exceções levantadas dentro do código C geralmente não são normalizadas, mas não se ocorrerem enquanto o Python estiver lidando com outra exceção. Exceções não normalizadas não podem tratar o encadeamento de exceções , que ocorre automaticamente para exceções geradas dentro de um manipulador de exceções. Neste caso, a _PyErr_SetObjectrotina interna normalizará automaticamente a exceção:

        exc_value = _PyErr_GetTopmostException(tstate)->exc_value;
    if (exc_value != NULL && exc_value != Py_None) {
        /* Implicit exception chaining */
        Py_INCREF(exc_value);
        if (value == NULL || !PyExceptionInstance_Check(value)) {
            /* We must normalize the value right now */

    Como o KeyErrorfoi normalizado, format_kwargs_errornão entende o que está vendo. Ele deixa KeyErrorpassar, em vez de aumentar o TypeErrorque deveria.

    No Python 3.12, as coisas são diferentes. A representação da exceção interna foi alterada, portanto qualquer exceção levantada é sempre normalizada. Assim, a versão Python 3.12 format_kwargs_errorprocura uma exceção normalizada em vez de uma exceção não normalizada e, se _PyDict_MergeExgerou um KeyError, o código irá reconhecê-lo:

        else if (_PyErr_ExceptionMatches(tstate, PyExc_KeyError)) {
        PyObject *exc = _PyErr_GetRaisedException(tstate);
        PyObject *args = ((PyBaseExceptionObject *)exc)->args;
        if (exc && PyTuple_Check(args) && PyTuple_GET_SIZE(args) == 1) {
    • 22

relate perguntas