5

I made a typo in my code that went completely silent syntactically.

dict_args : {"arg1":1,"arg2":2,"arg3":3}
# .... Some more code
some_function(**dict_args)
# .... Some more code

If you haven't noticed it, it's the use of : instead of = when declaring the variable dict_args.

So my question is, does the python syntax : a:1, by itself, hold any meaning ? Or should it hypothetically be considered a syntax error?

Imad
  • 2,358
  • 5
  • 26
  • 55

1 Answers1

3

PEP-526 introduced variable annotations, which provide programmers a way to add type information to variables. This allows, among other things, statements like

x: int

to indicate that there is a local variable of type int, without initializing it. In PEP-484 - Acceptable Type Hints, we can see that annotations "must be valid expressions that evaluate without raising exceptions", which your dictionary literal is.

If you look at the Python grammar itself you can see that the expr_stmt and annassign rules make the example you show legal.

If you're using an IDE/other type hinting tools, they should definitely complain about this, but it doesn't break the rules that Python has set up.

Patrick Haugh
  • 59,226
  • 13
  • 88
  • 96
  • Although I understand your answer, I don't actually agree that it should be acceptable. Why annotate something that doesn't exist yet? it should at least be limited to the scope of parameters or to variable assignment. E.g: `x: int = 1` would absolutely make sense. Annotating before defining a value is like me trying to tell you, without any context that `Victor works as a vendor`.. Yeah okay, but who is Victor and why would I care? – Imad Mar 06 '19 at 15:28
  • I'm inclined to agree with you, though this is the syntax that makes dataclasses possible in their current form. Guiod's reasoning [here](https://github.com/python/typing/issues/258) is that it makes cases where assignment could happen in multiple places easier, but I'm not sure that excuses how error-prone it is – Patrick Haugh Mar 06 '19 at 15:51
  • 1
    @Aetos Since only values, not names, have types, think of `a: int` as a hint that *when* a value is assigned to `a`, it has to be an `int`. There's no reason an `int` has to be assigned *immediately* for the hint to be valid. – chepner Mar 06 '19 at 16:24
  • @chepner what i find odd is that the annotation is so permissive, why not enforce that the annotation is a type like str, int etc., are there obvious use cases i'm missing? – Chris_Rands Mar 06 '19 at 18:56
  • 1
    Such annotations were not originally, and continue to not be, intended to be limited to type hints. Function annotations were originally left open to see what uses people could find for them. For example, you could simply provide a short doc string describing the purpose of the variable. In Python 4, I believe, the annotations will no longer even be evaluated as expressions, but stored as literal strings in the appropriate `__annotations__` attribute. – chepner Mar 06 '19 at 19:00
  • 1
    (See https://www.python.org/dev/peps/pep-0563/, regarding the delayed evaluation of annotations. I notice, though, that it does deprecate non-type-hint usage of annotations. In the future, it's possible that such uses could formally be banned, although since the parser simply at that time will treat an annotation effectively as a string literal, there doesn't seem to be much reason to go to the trouble to do so.) – chepner Mar 06 '19 at 19:05