python / python/typing

Annotating functions which don't raise exceptions

Ouverte
#604 7 commentaires 7 réactions 0 personnes assignées Voir sur GitHub

Personne n'a encore pris cette issue.

topic: feature
Langage dominant
Python
Étoiles
1.8k
Forks
302
Merge moyen
23 h
PR mergées (30 j)
8

Description

I would find it interesting to be able to annotate functions which never throw exceptions. "Never" can be either in the absolute sense, or in the sense of "checked exceptions", with some subset of exception designated as "unchecked" (details of this designation are perhaps up to the actual tool to process annotations).

Example of a function which absolutely never raises exceptions (well, at least per language semantics, particular implementations might still have means to break with some implementation-related exceptions):

def foo(l):
    if isinstance(l, list) and len(l) > 0:
        return l[0]

Example of a function which may throw (unchecked) exception if API contract is violated:

def foo(l: list):
    if len(l) > 0:
        return l[0]

So, hopefully these examples show that the notion does exist in Python.

Now the question how to annotate it. Following the existing NoReturn, it would be called NoRaise or NoThrow. "nothrow" terminology if familiar from C++ (and it seems to be replaced even there), so perhaps sticking with native Python terminology makes sense (but "throw" is native to Python too, re: exception handling with generators).

More interesting question is where to put that annotation. Taking the example above, a natural annotation would be:

def foo(l) -> Optional(Any), NoRaise:

And I was quite surprised that the usual "implicit tuple" syntax rule doesn't apply here, and the above is SyntaxError as of CPy3.7:

Python 3.7.1 (default, Oct 22 2018, 11:21:55) 
[GCC 8.2.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> def foo() -> list, int:
  File "<stdin>", line 1
    def foo() -> list, int:
                     ^
SyntaxError: invalid syntax

I wonder if that warrants a separate issue report. And whether it was a cunning design choice mere mortals need to decipher, because that seems too obvious thing to overlook with an implicit tuple syntax, again (neither problematic from forma grammar perspective, even in LL it's "->" expr ("," expr)* ":", which is trivial, Python has more complex grammar rules in many places.

So, all in all, now it would need to be written as:

def foo(l) -> (Optional(Any), NoRaise):

Which is of course not as pretty as without parens.

Guide de contribution

Aucun guide de contribution indexé pour ce dépôt

Par où commencer

  1. Lisez l'issue en entier, puis le guide de contribution du projet.
  2. Signalez en commentaire que vous la prenez — cela évite que deux personnes fassent le même travail.
  3. Forkez le dépôt et travaillez sur une branche.
  4. Ouvrez une pull request qui référence le numéro de l'issue.

Piste de recherche

Aucun fichier du dépôt ni aucun test n’est nommé. Commencez par examiner l’annotation NoReturn existante et le comportement de la grammaire de Python 3.7 décrit ici, puis déterminez si l’objectif concerne la sémantique des exceptions, la syntaxe des annotations, ou les deux. La tâche sera considérée comme terminée lorsqu’une signification convenue pour NoRaise ou NoThrow et une syntaxe valide spécifiée seront établies.

Rédigé par le modèle d'indexation à partir du texte de l'issue.

Évaluation

Stack technique
python
Domaine
devtools
Type d'issue
Fonctionnalité
Difficulté
5/5
Temps estimé
Plus d'une semaine
Activité
À l'abandon
Clarté
À clarifier
Accessibilité débutants
25/100

Recevez les nouvelles issues par e-mail

Un résumé court des issues GitHub adaptées aux débutants.