Hi, I have written a basic proposal <https://docs.google.com/document/d/1oWewLYjI_DzbOnfUPk1ZDHIik5XH6OikaUIfo7fEW3I/edit#heading=h.h2vvc2a48bi8> based on my understanding of the 'support static type-checking of gRPC Python' project. It is very grateful if you can take a look and give some guidance. Have a good day!
-Sword 在 2018年3月16日星期五 UTC+8上午3:13:50，Nathaniel Manista写道： > > On Wed, Mar 14, 2018 at 8:06 AM, Sword Chen <[email protected] > <javascript:>> wrote: > >> Thanks for your reply. >> >>> Cool! How long? With what programming languages? >> >> I have used gRPC for several weeks, and I have been building the stream >> algorithm test environment these weeks with gRPC in Python. >> >>> This sounds like it's going in the right direction - something that I >>> think we sort of expect is that there will be a certain incrementality to >>> static typing of gRPC Python, and having to add stubs describing the types >>> of lower-level systems so that the upper-level systems can have type >>> annotations added and checked is not a surprise. mypy and pytype are both >>> young enough, and gRPC Python is weird enough, that it is certainly not our >>> expectation that we can just throw either tool at our codebase and it will >>> figure types out without any further assistance. :-) >> >> You mean the gradual typing, which allows one to annotate only part of a >> program, thus leverage desirable aspects of both dynamic and static typing. >> > > Well... I don't think there are desirable aspects of dynamic typing, but > not everyone agrees with me. :-P > > PEP483 >> <https://www.python.org/dev/peps/pep-0483/#summary-of-gradual-typing>. >> If we don't use the other tools, I have tried some basic type check by >> using annotations and decorator PEP 3107 >> <https://www.python.org/dev/peps/pep-3107/#idle>, here is the decorator >> function which can do the type check: >> from inspect import signature >> from functools import wraps >> >> >> def typeassert(*ty_args, **ty_kwargs): >> def decorate(func): >> >> >> # Map function argument names to supplied types >> sig = signature(func) >> bound_types = sig.bind_partial(*ty_args, **ty_kwargs).arguments >> >> >> @wraps(func) >> def wrapper(*args, **kwargs): >> bound_values = sig.bind(*args, **kwargs) >> # Enforce type assertions across supplied arguments >> for name, value in bound_values.arguments.items(): >> if name in bound_types: >> if not isinstance(value, bound_types[name]): >> raise TypeError( >> 'Argument {} must be {}'.format(name, >> bound_types[name]) >> ) >> return func(*args, **kwargs) >> return wrapper >> return decorate >> >> Here is the example: >> @typeassert(int,int z=int) >> def spam(x, y, z=42): >> print(x, y, z) >> > > Huh. I actually don't know what the relationship is between 3107 and > 483/484, but... we definitely don't want to add dynamic type checks. gRPC > needs to be fast; correct code shouldn't have to pay a performance penalty > at run-time. > > So as you said, if we don't throw other tools into the codebase, I am >> considering that we could use this method to help do the type check. But I >> still have some confusions: >> 1. the idea is "Support static type-checking of both gRPC Python itself >> and of code that uses gRPC Python." when we use the gPRC python, we can >> add the decorator to our own function, but for gPRC Python itself, do we >> add type-checker to every defined function? this will >> 2. Does this need to support PEP 484 >> <https://www.python.org/dev/peps/pep-0484/#abstract> or just detect the >> errors using the gRPC Python? As I know, mypy verifies standard PEP 484 >> <https://www.python.org/dev/peps/pep-0484/#abstract> type hints. >> > > Yes to supporting what are called "type hints" and defined in 484. > > 3. About the grpc structure, actually, I am not quite Clear, is there some >> document to help me understand it? >> > > There's not enough! Building, running, and testing the code is probably > the best way to get to know it (especially changing parts here and there > and seeing what happens). We also have documentation for the gRPC Python > API <https://grpc.io/grpc/python/grpc.html#module-grpc>. > > These are my thoughts. Hope to get further guidance. >> > > Good to hear from you, > -N > -- You received this message because you are subscribed to the Google Groups "grpc.io" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at https://groups.google.com/group/grpc-io. To view this discussion on the web visit https://groups.google.com/d/msgid/grpc-io/37089101-0a32-4f8f-b882-77f2522ade92%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
