Verifique se o código não seguro não é usado acidentalmente

Uma função f()usa eval()(ou algo tão perigoso) com os dados que eu criei e armazenei na local_filemáquina executando meu programa:

import local_file

def f(str_to_eval):
    # code....
    # .... 
    eval(str_to_eval)    
    # ....
    # ....    
    return None


a = f(local_file.some_str)

f() é seguro de executar, pois as cordas que forneço são minhas.

No entanto, se eu decidir usá-lo para algo inseguro (por exemplo, entrada do usuário), as coisas podem dar muito errado . Além disso, se o local_filelocal deixar de ser local, isso criaria uma vulnerabilidade, pois eu precisaria confiar na máquina que fornece esse arquivo também.

Como devo garantir que nunca "esqueço" que esta função não é segura (a menos que critérios específicos sejam atendidos)?

_{Nota: eval()é perigoso e geralmente pode ser substituído por algo seguro.}

Defina um tipo para decorar entradas "seguras". Na sua função f(), afirme que o argumento tem esse tipo ou gere um erro. Seja esperto o suficiente para nunca definir um atalho def g(x): return f(SafeInput(x)).

Exemplo:

class SafeInput(object):
  def __init__(self, value):
    self._value = value

  def value(self):
    return self._value

def f(safe_string_to_eval):
  assert type(safe_string_to_eval) is SafeInput, "safe_string_to_eval must have type SafeInput, but was {}".format(type(safe_string_to_eval))
  ...
  eval(safe_string_to_eval.value())
  ...

a = f(SafeInput(local_file.some_str))

Embora isso possa ser facilmente contornado, torna mais difícil fazê-lo por acidente. As pessoas podem criticar esse tipo de verificação draconiana, mas não entenderiam o ponto. Como o SafeInputtipo é apenas um tipo de dados e não uma classe orientada a objetos que pode ser subclassificada, verificar a identidade do tipo com type(x) is SafeInputé mais seguro do que verificar a compatibilidade do tipo isinstance(x, SafeInput). Como queremos aplicar um tipo específico, ignorar o tipo explícito e apenas fazer a digitação implícita do pato também não é satisfatório aqui. O Python possui um sistema de tipos, então vamos usá-lo para detectar possíveis erros!

Como Joel apontou certa vez, faça com que o código errado pareça errado (role até a seção "A solução real", ou melhor, leia-o completamente; vale a pena, mesmo que ele endereça variáveis ​​ao invés de nomes de funções). Então, humildemente, sugiro renomear sua função para algo como f_unsafe_for_external_use()- você provavelmente criará algum esquema de abreviação.

Edit: Eu acho que a sugestão de amon é uma variação muito boa, baseada em OO, sobre o mesmo tema :-)

Complementando a sugestão de @amon, você também pode pensar em combinar o padrão de estratégia aqui, bem como o padrão de objeto do método.

class AbstractFoobarizer(object):
    def handle_cond(self, foo, bar):
        """
        Handle the event or something.
        """
        raise NotImplementedError

    def run(self):
        # do some magic
        pass

E então uma implementação 'normal'

class PrintingFoobarizer(AbstractFoobarizer):
    def handle_cond(self, foo, bar):
        print("Something went very well regarding {} and {}".format(foo, bar))

E uma implementação admin-input-eval

class AdminControllableFoobarizer(AbstractFoobarizer):
    def handle_cond(self, foo, bar):
        # Look up code in database/config file/...
        code = get_code_from_settings()
        eval(code)

(Nota: com um exemplo do mundo real, talvez eu possa dar um exemplo melhor).