[Python-Dev] Is static typing still optional?

[Chris Barker]

On Fri, Dec 22, 2017 at 10:10 AM, Stephan Hoyer <shoyer at gmail.com> wrote:

> On Thu, Dec 21, 2017 at 6:39 AM Ivan Levkivskyi <levkivskyi at gmail.com>
> wrote:
>
>>

> * ... (ellipsis): this class may or may not be used with static type
>> checkers, use the inferred type in the latter case
>>
>

> * "field docstring": this class should not be used with static type
>> checkers
>>
>> Assuming this, the second option would be the "real" "don't care". If
>> this makes sense,
>> then we can go the way proposed in https://github.com/python/
>> typing/issues/276 and make ellipsis semantics "official" in PEP 484.
>> (pending Guido's approval)
>>
>
> I am a little nervous about using "..." for inferred types, because it
> could potentially cause confusion with other uses of ellipsis in typing.
>

Isn't that what "make ellipsis semantics "official"" means -- i.e. making
it clear how they are used in typing?

The core problem is that generic annotations are used in dataclasses
without the "type hints" use-case. But:

1) Python is moving to make (PEP 484) type hints be THE recommended usage
for annotations

2) We want the annotations in dataclasses to be "proper" PEP 484 type hints
if they are there.

The challenge is:

- Annotations require a value.
- Any value used might be interpreted by a static type checker.

So we need a way to spell "no type specified" that will not be
mis-interpreted by type checkers, and is in the built in namespace, and
will seem natural to users with no knowledge or interest in static typing.

The ellipses is tempting, because it's a literal that doesn't have any
other obvious meaning in this context. Bu tif it has an incompatible
meaning in PEP 484, then we're stuck.

Is there another Obscure literal that would work?

 - I assume None means "the None type" to type checkers, yes?

 - empty string is one option -- or more to the point, any string -- so
then it could be used as docs as well.

- Is there another Obscure literal that would work? (or not so obscure one
that doesn't have another meaning to type checkers)

Would it be crazy to bring typing.Any into the builtin namespace?

@dataclass:
    a: Any
    b: Any = 34
    c: int = 0

That reads pretty well to me....

And having Any available in the built in namespace may help in other cases
where type hints are getting introduced into code that isn't really being
properly type checked.

I don't LOVE it -- to me, Any means "any type will do", or "I don't care
what type this is" and what we really want is "no type specified" -- i.e.
the same thing as plain old Python code without type hints. But practically
speaking, it has the same effect, yes?

-CHB




-- 

Christopher Barker, Ph.D.
Oceanographer

Emergency Response Division
NOAA/NOS/OR&R            (206) 526-6959   voice
7600 Sand Point Way NE   (206) 526-6329   fax
Seattle, WA  98115       (206) 526-6317   main reception

Chris.Barker at noaa.gov
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20171222/1c803653/attachment.html>