[Python-ideas] Trial balloon: adding variable type declarations in support of PEP 484

[Daniel Moisset]

I'll post here another wild idea (based on the https://github.com/python/
mypy/blob/master/mypy/build.py#L976 example), just thinking on instance
attributes. I myself am not fully sold on it but it's quite different so
perhaps adds a new angle to the brainstorming and has some nice upsides:

class State:

    def __instancevars__(
        manager: BuildManager,
        order: int,  # Order in which modules were encountered
        id: str,  # Fully qualified module name
        path: Optional[str],  # Path to module source
        xpath: str,  # Path or '<string>'
        source: Optional[str],  # Module source code
        meta: Optional[CacheMeta],
        data: Optional[str],
        tree: Optional[MypyFile],
        dependencies: List[str],
        suppressed: List[str],  # Suppressed/missing dependencies
        priorities: Dict[str, int]
    ): ...


The benefits of this is:
* No need to add new syntax or keywords here, this works in any 3.x
* This part of the change can be done right now without waiting for python
3.6
* it's guaranteed to be consistent with function annotations
* The instance vars annotations end up in a standard place on runtime if
someone needs them (run time checking, documentation generators, etc).
* No confusing access to a name that may look like a NameError
* Very obvious runtime behaviour for python users even if they don't use a
typechecker.
* This can even be used in python 2.x, by changing the annotation to a "#
type: T" along the argument.

The downsides are:
* There is a bit of boilerplate (the parenthesis, the ellipsis, the extra
commas)
* It's unclear what the body of this function is supposed to do, but
probably the typechecker can ensure it's always "..." (I'm assuming that
whoever writes this wants to use a type checker anyway)
* It's also unclear what a default argument would mean here, or *args, or
**kwargs (again, the typechecker could enforce proper usage here)
* It doesn't cover locals and class variables, so it's still necessary the
new syntax for "type declaration and initialization assignment" (but not
the "declaration without assignment")

As a second order iterations on the idea
* If this idea works well now it's easier to add nicer syntax later that
maps to this (like a block statement) and specify the runtime semantics in
term of this (which is what I see the traditional way in python)
* It could be possible to give semantic to the body (like a post __new__
thing where locals() from this function are copied to the instance dict),
and this would allow setting real instance defaults () but this is new
class creation semantics and can have a performance cost on instantiation
when having types declared

Hope this adds to the discussion,


On Thu, Aug 4, 2016 at 9:46 AM, Sven R. Kunze <srkunze at mail.de> wrote:

> Another thought:
>
> Can it be used for something else than type declarations like function
> annotations allow?
>
>
> On 01.08.2016 23:31, Guido van Rossum wrote:
>
>> PEP 484 doesn't change Python's syntax. Therefore it has no good
>> syntax to offer for declaring the type of variables, and instead you
>> have to write e.g.
>>
>> a = 0  # type: float
>> b = []  # type: List[int]
>> c = None  # type: Optional[str]
>>
>> I'd like to address this in the future, and I think the most elegant
>> syntax would be to let you write these as follows:
>>
>> a: float = 0
>> b: List[int] = []
>> c: Optional[str] = None
>>
>> (I've considered a 'var' keyword in the past, but there just are too
>> many variables named 'var' in my code. :-)
>>
>> There are some corner cases to consider. First, to declare a
>> variable's type without giving it an initial value, we can write this:
>>
>> a: float
>>
>> Second, when these occur in a class body, they can define either class
>> variables or instance variables. Do we need to be able to specify
>> which?
>>
>> Third, there's an annoying thing with tuples/commas here. On the one
>> hand, in a function declaration, we may see (a: int = 0, b: str = '').
>> On the other hand, in an assignment, we may see
>>
>> a, b = 0, ''
>>
>> Suppose we wanted to add types to the latter. Would we write this as
>>
>> a, b: int, str = 0, ''
>>
>> or as
>>
>> a: int, b: str = 0, ''
>>
>> ??? Personally I think neither is acceptable, and we should just write it
>> as
>>
>> a: int = 0
>> b: str = ''
>>
>> but this is a slight step back from
>>
>> a, b = 0, ''   # type: (int, str)
>>
>>
> _______________________________________________
> Python-ideas mailing list
> Python-ideas at python.org
> https://mail.python.org/mailman/listinfo/python-ideas
> Code of Conduct: http://python.org/psf/codeofconduct/
>



-- 
Daniel F. Moisset - UK Country Manager
www.machinalis.com
Skype: @dmoisset
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20160804/bf41f531/attachment-0001.html>