[Python-ideas] Re: Shouldn't this: ' myVar: "value" ' be a syntax error ?

2019-07-09 Thread Chris Angelico
On Wed, Jul 10, 2019 at 6:11 AM Shay Cohen  wrote:
>
>
> >>> a: 3
> >>> type(a: 3)
>   File "", line 1
> type(a: 3)
>   ^
> SyntaxError: invalid syntax
> >>> a: 3
> >>> type(a)
> Traceback (most recent call last):
>   File "", line 1, in 
> NameError: name 'a' is not defined
> >>> a
> Traceback (most recent call last):
>   File "", line 1, in 
> NameError: name 'a' is not defined

This kind of question is better asked on the main python-list, as this
one is about making suggestions for future changes.

What you've done there is create a type annotation (albeit a
meaningless one). On its own, that's not very useful, but there are
many great ways to use them:

@dataclass
class PackedItemData(ProtoBuf):
serial: bytes
quantity: int
equipped: int
mark: int

These annotations define the way that this structure is loaded and
saved in a file, but they don't actually give values to those
variables (which is why you still get the NameError). There's just a
record in the annotations dictionary saying "hey, mark is meant to be
an int", or in your case, "hey, a is meant to be a 3".

ChrisA
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/WEFN3XGL5YZLQQPIQYQD6W2FPP7P6LNN/
Code of Conduct: http://python.org/psf/codeofconduct/


[Python-ideas] Re: Shouldn't this: ' myVar: "value" ' be a syntax error ?

2019-07-09 Thread Andrew Barnert via Python-ideas
On Jul 9, 2019, at 13:09, Shay Cohen  wrote:
> 
> >>> a: 3

The reason this isn’t a syntax error is that Python allows any valid expression 
as an annotation. And “3” is just as valid an expression as “int”.

More generally, annotations don’t actually do anything at runtime, except get 
stored in an annotation dictionary. If you want to get errors related to type 
annotations, you need a separate tool, like mypy (or a library that processes 
the annotations dictionary for some special use, as dataclasses does). And of 
course mypy will give you an error for using 3 as a type.

Since this is python-ideas, not python-list, maybe you’re suggesting that 
Python _should_ require a type at runtime? If so, there are multiple reasons 
that won’t work:

* “Forward references”, like a Node class with a next element of type Node, 
work by putting the type name in a string, which only works because as far as 
Python is concerned the string “Node” is a perfectly valid value.

* Shortcuts like using None to mean NoneType again only work because Python 
only cares that None is a valid value.

* Annotations have been part of the language since 3.0, and it’s only since 3.5 
that it’s recommended to only use them for types. Changing that now could break 
working code, preventing people from upgrading to 3.8.

* If the compiler and interpreter aren’t going to check the types (which would 
require major changes to everything about the way Python works), all it would 
do is mislead people into thinking they’re getting static type checking when 
they aren’t.

> >>> type(a: 3)
>   File "", line 1
> type(a: 3)
>   ^
> SyntaxError: invalid syntax

This is invalid because annotations can only appear in a few specific places, 
like assignment statements, function parameters, and useless expression 
statements, not in the middle of an arbitrary expression.

> >>> a: 3
> >>> type(a)
> Traceback (most recent call last):
>   File "", line 1, in 
> NameError: name 'a' is not defined

The reason you get a NameError is that you haven’t actually created a variable 
named a. All you’ve done is said “if I create a variable named a later (or have 
already done so earlier), annotate it with int”. To create the variable, assign 
it a value.

But also, the annotation has nothing to do with the actual runtime type (the 
thing the type function returns). As far as Python is concerned, variables 
don’t have types, values do. Since you haven’t given a a value, there is 
nothing to ask for the type of (hence the NameError). But it may be more useful 
to look at this example:

>>> a: str = 5
>>> type(a)
int

If the value of a is 5, then the type of a is the type of 5, which is int. If 
you run this through the mypy checker, it will reject that assignment, because 
you’re trying to store an int value in a str-annotated variable. But as far as 
Python is concerned, that annotation means nothing, so the assignment is fine. 
And then, the type of a is the type of that value, 5, which is int.

___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/2O6Z2RGK4AYFE4IXKLMZABU7M5JPXJMA/
Code of Conduct: http://python.org/psf/codeofconduct/


[Python-ideas] Re: Shouldn't this: ' myVar: "value" ' be a syntax error ?

2019-07-10 Thread Nick Timkovich
On Tue, Jul 9, 2019 at 4:15 PM Andrew Barnert via Python-ideas <
python-ideas@python.org> wrote:

> On Jul 9, 2019, at 13:09, Shay Cohen  wrote:
> >
> > >>> a: 3
>
> The reason this isn’t a syntax error is that Python allows any valid
> expression as an annotation. And “3” is just as valid an expression as
> “int”.
>
> More generally, annotations don’t actually do anything at runtime, except
> get stored in an annotation dictionary.
>

If you're curious where those annotation "definitions" actually disappear
off to: `__annotations__`

>>> a: 3
>>> __annotations__
{'a': 3}
>>> class X:
... b: 42
...
>>> hasattr(X, 'b')
False
>>> X.__annotations__
{'b': 42}
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/U7EJB3K5UQSOA6DM3OH6RAGN3LFPCVZR/
Code of Conduct: http://python.org/psf/codeofconduct/