open source tools to generate mypy stubs from protobufs

Overview

mypy-protobuf: Generate mypy stub files from protobuf specs

CI pypi license

We just released a new major release mypy-protobuf 2. on 02/02/2021! It includes some backward incompatible changes. See Changelog for recent changes.

Requirements

mypy >= v0.800 protoc 3.14.0 or greater python-protobuf >= 3.14.0 python >= 3.6 - for running mypy-protobuf plugin. Generated stubs will compatible back to python2.

Other configurations may work, but are not supported in testing currently. We would be open to expanding this list if a need arises - file an issue on the issue tracker.

Installation

The plugin can be installed with

pip install mypy-protobuf

To install unreleased

REV=master  # or whichever unreleased git rev you'd like
pip install git+https://github.com/dropbox/mypy-protobuf.git@$REV

# Prior to directory structure flattening, you may need
pip install git+https://github.com/dropbox/mypy-protobuf.git@$REV#subdirectory=python

Implementation

The implementation of the plugin is in mypy_protobuf/main.py, which installs to a posix executable protoc-gen-mypy. On windows you will have to use protoc_gen_mypy.bat for the executable.

On posix, ensure that the protoc-gen-mypy script installed onto your $PATH. Then run.

protoc --python_out=output/location --mypy_out=output/location

Alternately, you can explicitly provide the path:

protoc --plugin=protoc-gen-mypy=path/to/protoc-gen-mypy --python_out=output/location --mypy_out=output/location

On windows, provide the bat file:

protoc --plugin=protoc-gen-mypy=path/to/protoc_gen_mypy.bat --python_out=output/location --mypy_out=output/location

Features

See Changelog for full listing

Types enum int values more strongly

Enum int values produce stubs which wrap the int values in NewType

enum MyEnum {
  FOO = 0;
  BAR = 1;
}

Will yield an enum type wrapper whose methods type to MyEnum.V rather than int. This allows mypy to catch bugs where the wrong enum value is being used.

mypy-protobuf autogenerates an instance of the EnumTypeWrapper as follows.

class _MyEnum(google.protobuf.internal.EnumTypeWrapper[MyEnum.V], builtins.type):
    DESCRIPTOR: google___protobuf___descriptor___EnumDescriptor = ...
    FOO = MyEnum.V(0)
    BAR = MyEnum.V(1)
class MyEnum(metaclass=_OuterEnum):
    V = typing___NewType('V', builtins.int)
FOO = MyEnum.V(0)
BAR = MyEnum.V(1)

Calling code may be typed as follows. Note that the type of x must be quoted until upstream protobuf supports V

def f(x: 'MyEnum.V'):
    print(x)

f(MyEnum.Value("FOO"))

Supports generating type wrappers for fields and maps

M.proto

message M {
  uint32 user_id = 1 [(mypy_protobuf.casttype)="mymod.UserId"
  map<uint32, string> email_by_uid = 2 [
    (mypy_protobuf.keytype)="path/to/mymod.UserId",
    (mypy_protobuf.valuetype)="path/to/mymod.Email"
  ];
}

mymod.py

UserId = NewType("UserId", int)
Email = NewType("Email", Text)

py_generic_services

If py_generic_services is set in your proto file, then mypy-protobuf will generate service stubs. If you want GRPC stubs instead - use the GRPC instructions.

readable_stubs

If readable_stubs is set, mypy-protobuf will generate easier-to-read stubs. The downside to this approach - is that it's possible to generate stubs which do not pass mypy - particularly in the case of name collisions. mypy-protobuf defaults to generating stubs with fully qualified imports and mangled global-level identifiers to defend against name collisions between global identifiers and field names.

If you're ok with this risk, try it out!

protoc --python_out=output/location --mypy_out=readable_stubs:output/location

relax_strict_optional_primitives

If you are using proto3, then primitives cannot be represented as NULL on the wire - only as their zero value. By default mypy-protobuf types message constructors to have non-nullable primitives (eg int instead of Optional[int]). python-protobuf itself will internally convert None -> zero value, and if you intentionally want to use this behavior, set this! We recommend avoiding this, but it may be helpful when migrating existing proto2 code.

protoc --python_out=output/location --mypy_out=relax_strict_optional_primitives:output/location

Output suppression

To suppress output, you can run

protoc --python_out=output/location --mypy_out=quiet:output/location

GRPC

This plugin provides stubs generation for grpcio generated code.

protoc \
    --python_out=output/location \
    --mypy_out=output/location \
    --grpc_out=output/location \
    --mypy_grpc_out=output/location

Note that generated code for grpc will work only together with code for python and locations should be the same. If you need stubs for grpc internal code we suggest using this package https://github.com/shabbyrobe/grpc-stubs

Contributing

Contributions to the implementation are welcome. Please run tests using ./run_test.sh. Ensure code is formatted using black.

pip3 install black
black mypy_protobuf/main.py test/

Contributors

Dropboxers

Others

Licence etc.

  1. License: Apache 2.0.
  2. Copyright attribution: Copyright (c) 2017 Dropbox, Inc.
  3. External contributions to the project should be subject to Dropbox's Contributor License Agreement (CLA): https://opensource.dropbox.com/cla/
Comments
  • Cyclical reference prevents generated code from being used with pyright

    Cyclical reference prevents generated code from being used with pyright

    Recent versions of mypy-protobuf generate code that includes a cyclical reference that prevents the code from being used with pyright.

    The problem can be seen here:

    class Colors(metaclass= _Colors):
        V = NewType('V', int)
    
    class _Colors(_EnumTypeWrapper[Colors.V], type):
        RED = Colors.V(0)
        GREEN = Colors.V(1)
        BLUE = Colors.V(2)
    

    The generated code is using _Colors as a metaclass for Colors, but it's using Colors in the base class definition for _Colors. The type evaluation for the expression Colors.V depends potentially on metaclass behavior, but the metaclass can't be defined without accessing Colors.V. It's a cyclical dependency, and I don't see any way to break it.

    I'm not sure why mypy is OK with this construct. I'm guessing that it happens to work because mypy is a multi-pass analyzer and silently gives up after n passes of trying to resolve this dependency? Or it simply fails to detect that there is a dependent cycle and proceeds as though everything is OK? Pyright is a lazy evaluator, so it can deal with dependencies in any order, but it cannot break a hard dependency like this, and I don't see a way to make it work, even in theory.

    Do you have any thoughts or advice? Is there another way you could accomplish this without generating a cyclical dependency?

    For example, could you define the type for V outside of the namespace of the class, like this? This appears to work fine with both mypy and pyright.

    from typing import Generic, NewType, TypeVar
    
    T = TypeVar("T")
    
    class _EnumTypeWrapper(Generic[T]): ...
    
    _Colors_V = NewType("_Colors_V", int)
    
    class Colors(metaclass=_Colors):
        V = _Colors_V
    
    class _Colors(_EnumTypeWrapper[_Colors_V], type):
        RED = Colors.V(0)
        GREEN = Colors.V(1)
        BLUE = Colors.V(2)
    
    opened by erictraut 25
  • grpc stubs lack annotations for experimental API methods

    grpc stubs lack annotations for experimental API methods

    Just trying out the grpc stub generation, as per #46.

    It seems like the gRPC stubs don't have the native gRPC methods added.

    For example from grpc .pyi:

    def GetSomething(self,
        request: global___GetSomethingRequest,
    ) -> global___GetSomethingResponse: ...
    

    However, the grpc .py:

    @staticmethod
    def GetSomething(request,
            target,
            options=(),
            channel_credentials=None,
            call_credentials=None,
            insecure=False,
            compression=None,
            wait_for_ready=None,
            timeout=None,
            metadata=None):
    

    Not totally certain if I'm using it correctly, but when using the grpc.pyi files I am getting mypy errors like this, on code where it was definitely working:

    Unexpected keyword argument "metadata" for "GetSomething" of "GetSomethingStub"
    

    Would appreciate any insights you can offer.

    Thank you!

    opened by gitpushdashf 15
  • Support inner enum constants

    Support inner enum constants

    In Python protobufs, enum members can be accessed both as module.ENUM_MEMBER or module.MyEnum.ENUM_MEMBER.

    This commit adds support for the latter style.

    It also fixes a problem with using reserved keywords as an enum member name (declarations for those are skipped).

    opened by jaens 14
  • Plugin does not generate gRPC stubs to *_pb2_grpc.py

    Plugin does not generate gRPC stubs to *_pb2_grpc.py

    Starting from some version of the protoc compiler, gRPC service stubs are no longer generated into *_pb2.py files. Now they are generated into separate *_pb2_grpc.py files. So to properly support grpcio library *_pb2_grpc.pyi files should be generated for service stubs.

    And it would be great to generate gRPC stubs optionally, this would be possible if two separate CLI options (plugins) for protoc were created:

    • --mypy_out for messages
    • --mypy_gprc_out for gRPC stubs

    I'm asking for this feature because I'm the author of the grpclib library, which is an alternative gRPC implementation for asyncio, and users of this library don't need gRPC stubs for grpcio.

    help wanted 
    opened by vmagamedov 13
  • proto3 Extensions defined at module level produce bad mypy ExtensionDict types

    proto3 Extensions defined at module level produce bad mypy ExtensionDict types

    I'm trying the new versions of mypy-protobuf 2.6 together with types-protobuf 3.17.0 and I'm getting some errors when using extensions.

    syntax = "proto3";
    
    extend google.protobuf.FieldOptions {
      // Give a bit more semantics to a field so that we can programatically
      // identify sensitive fields to handle with care.
      FieldUsage field_usage = 50000;
    }
    
    enum FieldUsage {
      // Many fields are not tagged, this is either because they have not been
      // tagged yet or because they define the user's project and as such do not
      // need special care yet. In the future we might add a tag for those if there
      // is a need.
      UNKNOWN_FIELD_USAGE = 0;
    
      // A field that may uniquely identify a user.
      PERSONAL_IDENTIFIER = 1;
    
      // A field that is only used for the app's UX or UI: it does not contain
      // actual user data.
      APP_ONLY = 2;
    
      // A field whose value is provided by the user as a feedback.
      USER_FEEDBACK = 3;
    
      // A field populated by the app as a result of an algorithm.
      ALGORITHM_RESULT = 4;
    }
    
            extensions = field_descriptor.GetOptions().Extensions
            field_usage = extensions[options_pb2.field_usage]
    

    Here's what mypy tells me for line 1 and 2 (respectively)

    Need type annotation for "field_usage"
    Invalid index type "FieldDescriptor" for "_ExtensionDict[FieldOptions]"; expected type "_ExtensionFieldDescriptor[FieldOptions, <nothing>]"
    

    I've dug a bit and it seems that mypy-protobuf types options_pb2.field_usage as a generic google.protobuf.descriptor.FieldDescriptor instead of having a _ExtensionFieldDescriptor[FieldOptions, options_pb2.FieldUsage>].

    Does someone else have this issue? Should I change the generated type?

    opened by pcorpet 11
  • The split enum value types break type checks when used with dataclasses

    The split enum value types break type checks when used with dataclasses

    Changes made in https://github.com/dropbox/mypy-protobuf/pull/120 are breaking typechecks when compiled types are used with dataclasses, or in general when enums are used as parameters or return values.

    Quick example: proto:

    syntax = "proto3";
    
    package bikes;
        
    enum EngineType {
        TWO_STROKE = 0;
        FOUR_STROKE = 1;
    }
    
    message Motorcycle {
        string name = 1;
        EngineType engine_type = 2;
    }
    

    python:

    from dataclasses import dataclass
    from motorcycles_pb2 import Engine, EngineType, Motorcycle
    
    @dataclass
    class DemoEngine:
        engine_type: EngineType
        name: str
    
        def __init__(self, engine_type: EngineType, name: str):
            self.engine_type = engine_type
            self.name = name
    
    d = DemoEngine(EngineType.TWO_STROKE, "demo")
    

    type check failure:

    motorcycles/__main__.py:17: error: Argument 1 to "DemoEngine" has incompatible type "EngineTypeValue"; expected "EngineType"
    

    Protos compiled with protoc 3.12.2 using python -m grpc_tools.protoc

    opened by sagar-infinitus-ai 11
  • Changed stubs to use callable instead of def

    Changed stubs to use callable instead of def

    Changed type generation for grpcio stubs to use the MultiCallable API (see here) . This requires using the grpc-stubs typings for grpcio. This change should allow calling stub methods with common parameters (timeout, metadata, etc.) as well as calling methods on the MultiCallable object (e.g. my_stub.MyRpcMethod.future()).

    Fixes #209

    opened by MHDante 10
  • Add support for optional proto3 fields

    Add support for optional proto3 fields

    This adds support for optional proto3 fields, introduced as an experimental feature in 3.12. The only really noticeable difference in the API is that since they track field presence they can be used in HasFields, so besides declaring support for the feature the only change is allowing fields with proto3_optional set to True in HasFields.

    Closes https://github.com/dropbox/mypy-protobuf/issues/146

    See https://github.com/protocolbuffers/protobuf/blob/v3.12.0/docs/field_presence.md and https://github.com/protocolbuffers/protobuf/blob/v3.12.0/docs/implementing_proto3_presence.md for more info.

    Note that some changes were required for the protobuf types in typeshed: https://github.com/python/typeshed/pull/4680 While it's merged, it hasn't made its way into the stubs bundled with mypy yet.

    opened by henribru 9
  • Add support for proto2 extensions

    Add support for proto2 extensions

    Adds support for message extensions. Now if there is a message

    message Bar {
      extend Foo { optional Bar ext = 2020; }
      
      optional bool flag = 1;
    }
    

    then Bar.ext will no longer raise a mypy error. Furthermore, we are able to correctly type extension messages, so for something like

    foo = Foo()
    bar = foo.Extensions[Bar.ext]
    

    the inferred type for bar is Bar.

    opened by EPronovost 9
  • The global___ name mangling breaks my type check

    The global___ name mangling breaks my type check

    With mypy-protobuf 1.19, mypy passed my code. Upgrading to mypy-protobuf 1.20 changes the output to add some global___ prefixes to types, breaking the type check. If I pin my dependency to 1.19, or just strip out these prefixes, mypy passes my code again. Is there another alternative? Perhaps an option to disable the name mangling?

    opened by thejohnfreeman 9
  • Generated constructors incorrectly accept positional arguments

    Generated constructors incorrectly accept positional arguments

    The annotated __init__ method generated for a protobuf message accepts positional arguments, but the underlying implementation accepts only named arguments. The first parameter after self should be a nameless * parameter. This will tell mypy and other type checkers that positional arguments are not allowed when calling the constructor.

    For example, a protobuf message with a string: name field will generate the following annotated stub:

    class MyMessage(google___protobuf___message___Message):
        name = ... # type: typing___Text
    
        def __init__(self,
            name : typing___Optional[typing___Text] = None) -> None: ...
    

    If callers attempt to construct this message by calling MyMessage('bob'), a runtime error occurs indicating that positional arguments are not allowed for this call.

    To match the underlying implementation, it should be:

        def __init__(self, *,
            name : typing___Optional[typing___Text] = None) -> None: ...
    
    opened by erictraut 9
  • Bump pyright from 1.1.281 to 1.1.286 in /.github

    Bump pyright from 1.1.281 to 1.1.286 in /.github

    Bumps pyright from 1.1.281 to 1.1.286.

    Release notes

    Sourced from pyright's releases.

    Published 1.1.286

    Bug Fix: Reverted a recent update to the TOML parser that resulted in a regression. This reversion means that some TOML 1.0 features will not be handled correctly.

    Bug Fix: Fixed a bug that resulted in incorrect handling of literals in the TypeVar constraint solver. This involved a pretty significant change to the constraint solver logic — one that eliminated some heuristics and special cases.

    Bug Fix: Fixed a bug that caused target expressions within a chained assignment to be evaluated in the wrong order (right to left instead of left to right). This resulted in false positives and negatives in some cases where one target referred to another target. This change also makes it illegal to use a Python 2-style type comment on a line containing a chained assignment statement, reflecting the fact that Python 3-style variable type annotations are not legal here either.

    Enhancement: Improved handling of TypeVarTuple constraint solving. Previously, if a TypeVarTuple appeared more than once, the corresponding tuple types needed to be identical. The constraint solver now supports the same sort of narrowing/widening within the tuple entries to find the best solution.

    Bug Fix: Fixed a bug that led to a false negative during protocol matching if the protocol class refers to itself within an invariant type argument.

    Enhancement: Improved handling of generic functions passed as arguments to generic higher-order functions. Pyright is now able to solve the type variables for both the generic callback and the called function.

    Enhancement: Updated typeshed stubs to the latest version.

    Enhancement: Improved handling of generic functions passed as arguments to generic higher-order functions that use a ParamSpec. Pyright is now able to solve the type variables for both the generic callback and the called function.

    Bug Fix: Fixed a bug in the code flow engine that resulted in incorrect type evaluation in some cases involving double nested loops.

    Bug Fix: Improved the method override consistency checks to detect the case where an override uses an *args parameter that is not type compatible with the overridden method's parameter types. Thanks to @​mehdigmira for this contribution.

    Enhancement: Improved handling of TypeVars that appear only within a Callable within a return type annotation for a function. By a strict reading of PEP 484, these should be bound to the function's scope, but practically, they are bound to the Callable. This allows a function to return a generic callable type. When TypeVars are rescoped in this manner, the TypeVar cannot be referenced within the function body because it is no longer in scope in that context.

    Enhancement: Improved error handling for NewType calls

    Enhancement: Completed initial implementation of PEP 696. Added support for default TypeVar types that refer to other TypeVars.

    Published 1.1.285

    Enhancement: Implemented a new --level command-line option that allows filtering of 'information' and 'warning' diagnostics.

    Enhancement: Updated TOML parser to one that is compliant with the TOML 1.0 spec.

    Enhancement: Added logic to detect uses of PEP 604 | syntax that generate exceptions due to runtime limitations. In particular, if one of the operands is a string (i.e. a forward reference) and the other is also a string or a class that is not explicitly specialized, this will result in an exception.

    Bug Fix: Fixed recent regression in completion provider that resulted in garbled type information for a symbol that is declared as a function (using a def statement) but transformed into a non-function type using a decorator.

    Bug Fix: Fixed a bug that resulted in a false positive error when an index expression with a numeric literal subscript was used in a loop that included a del statement targeting the same index expression.

    Behavior Change: Modified the overload matching algorithm to match the behavior of mypy when the overload match is ambiguous because an argument evaluates to Any or Unknown. In this case, the call expression evaluates to Unknown. Previously, pyright used the first of the matching overloads in this case.

    Bug Fix: Fixed a bug that led to extremely long type analysis times when determining type compatibility between an recursive type alias and a recursive protocol.

    Bug Fix (contribution from @​parched): Fixed recent regression that caused reportImportCycles diagnostic reporting to no longer work.

    Bug Fix: Fixed a bug that resulted in a false positive error when a property setter or deleter contained function-scoped type variables.

    Published 1.1.284

    Bug Fix: Fixed a bug that resulted in an incorrect type evaluation when using a literal integer index into a tuple that includes an unpacked TypeVarTuple element.

    Behavior Change: Removed diagnostic check that detects a non-ellipsis default value in a stub file. This check was based on a now-outdated best practice. We now recommend that stubs include default values for better usability in language servers.

    ... (truncated)

    Commits

    Dependabot compatibility score

    Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.


    Dependabot commands and options

    You can trigger Dependabot actions by commenting on this PR:

    • @dependabot rebase will rebase this PR
    • @dependabot recreate will recreate this PR, overwriting any edits that have been made to it
    • @dependabot merge will merge this PR after your CI passes on it
    • @dependabot squash and merge will squash and merge this PR after your CI passes on it
    • @dependabot cancel merge will cancel a previously requested merge and block automerging
    • @dependabot reopen will reopen this PR if it is closed
    • @dependabot close will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually
    • @dependabot ignore this major version will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)
    • @dependabot ignore this minor version will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)
    • @dependabot ignore this dependency will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)
    dependencies javascript 
    opened by dependabot[bot] 0
  • Not generating .py files from protouf file using this plugin

    Not generating .py files from protouf file using this plugin

    Hello,

    I have cloned this repo locally and installed all required packages as you have mentioned in your readme. I am trying to generate .py files from protobuf but it's throwing a Missing input file error.

    Here is the execution command I'm using while compiling the protobuf file in the windows system.

    protoc --python_out=*.proto --mypy_out=.
    

    Can you please clarify more in your readme and also give any working example in the readme to replicate the same example?'

    Thank you, Vishal

    opened by vishaldhanani 1
  • Bump protobuf from 4.21.9 to 4.21.12

    Bump protobuf from 4.21.9 to 4.21.12

    Bumps protobuf from 4.21.9 to 4.21.12.

    Commits

    Dependabot compatibility score

    Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.


    Dependabot commands and options

    You can trigger Dependabot actions by commenting on this PR:

    • @dependabot rebase will rebase this PR
    • @dependabot recreate will recreate this PR, overwriting any edits that have been made to it
    • @dependabot merge will merge this PR after your CI passes on it
    • @dependabot squash and merge will squash and merge this PR after your CI passes on it
    • @dependabot cancel merge will cancel a previously requested merge and block automerging
    • @dependabot reopen will reopen this PR if it is closed
    • @dependabot close will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually
    • @dependabot ignore this major version will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)
    • @dependabot ignore this minor version will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)
    • @dependabot ignore this dependency will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)
    dependencies python 
    opened by dependabot[bot] 0
  • Bump types-protobuf from 4.21.0.1 to 4.21.0.2

    Bump types-protobuf from 4.21.0.1 to 4.21.0.2

    Bumps types-protobuf from 4.21.0.1 to 4.21.0.2.

    Commits

    Dependabot compatibility score

    Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.


    Dependabot commands and options

    You can trigger Dependabot actions by commenting on this PR:

    • @dependabot rebase will rebase this PR
    • @dependabot recreate will recreate this PR, overwriting any edits that have been made to it
    • @dependabot merge will merge this PR after your CI passes on it
    • @dependabot squash and merge will squash and merge this PR after your CI passes on it
    • @dependabot cancel merge will cancel a previously requested merge and block automerging
    • @dependabot reopen will reopen this PR if it is closed
    • @dependabot close will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually
    • @dependabot ignore this major version will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)
    • @dependabot ignore this minor version will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)
    • @dependabot ignore this dependency will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)
    dependencies python 
    opened by dependabot[bot] 0
  • Bump grpcio-tools from 1.50.0 to 1.51.1

    Bump grpcio-tools from 1.50.0 to 1.51.1

    Bumps grpcio-tools from 1.50.0 to 1.51.1.

    Release notes

    Sourced from grpcio-tools's releases.

    Release v1.51.1

    This is release gRPC Core 1.51.1 (galaxy).

    For gRPC documentation, see grpc.io. For previous releases, see Releases.

    This release contains refinements, improvements, and bug fixes.

    Python

    • Revert "Build with System OpenSSL on Mac OS arm64 (#31096)". (#31739)

    Release v1.51.0

    This is release gRPC Core 1.51.0 (galaxy).

    For gRPC documentation, see grpc.io. For previous releases, see Releases.

    This release contains refinements, improvements, and bug fixes.

    Core

    • Bump core version 202211082118. (#31585)
    • c-ares DNS resolver: fix logical race between resolution timeout/cancellation and fd readability. (#31443)
    • [log] Longer space for filenames. (#31432)
    • c-ares DNS resolver: remove unnecessary code in SRV callback. (#31426)
    • Correct the domain-socket client address read out from the ServerContext. (#31108)
    • outlier detection: remove env var protection. (#31251)
    • EventEngineFactoryReset - remove custom factory and reset default engine. (#30554)
    • [tls] Remove support for pthread tls. (#31040)

    C++

    • Added version macros to gRPC C++. (#31033)
    • OpenCensus: Move measures, views and CensusContext to include file. (#31341)
    • GcpObservability: Add experimental public target. (#31339)

    C#

    • Fix msbuild failing when '@' is present in path (2nd attempt). (#31527)
    • Revert "Fix msbuild failing when '@' is present in path". (#31464)
    • Fix msbuild failing when '@' is present in path. (#31133)

    PHP

    • fixing php 8.2 deprecations. (#30997)

    ... (truncated)

    Commits

    Dependabot compatibility score

    Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.


    Dependabot commands and options

    You can trigger Dependabot actions by commenting on this PR:

    • @dependabot rebase will rebase this PR
    • @dependabot recreate will recreate this PR, overwriting any edits that have been made to it
    • @dependabot merge will merge this PR after your CI passes on it
    • @dependabot squash and merge will squash and merge this PR after your CI passes on it
    • @dependabot cancel merge will cancel a previously requested merge and block automerging
    • @dependabot reopen will reopen this PR if it is closed
    • @dependabot close will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually
    • @dependabot ignore this major version will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)
    • @dependabot ignore this minor version will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)
    • @dependabot ignore this dependency will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)
    dependencies python 
    opened by dependabot[bot] 0
  • Add version to header comment.

    Add version to header comment.

    It would be useful if the generated header comment would contain the version of the plugin, e.g.

    """
    @generated by mypy-protobuf 3.3.0/libprotoc 3.19.5.  Do not edit manually!
    isort:skip_file
    """
    
    opened by jenstroeger 3
Owner
Dropbox
Dropbox
PEP-484 typing stubs for SQLAlchemy 1.4 and SQLAlchemy 2.0

SQLAlchemy 2 Stubs These are PEP-484 typing stubs for SQLAlchemy 1.4 and 2.0. They are released concurrently along with a Mypy extension which is desi

SQLAlchemy 139 Dec 30, 2022
Pymxs, the 3DsMax bindings of Maxscript to Python doesn't come with any stubs

PyMXS Stubs generator What Pymxs, the 3DsMax bindings of Maxscript to Python doe

Frieder Erdmann 19 Dec 27, 2022
A plugin for flake8 integrating Mypy.

flake8-mypy NOTE: THIS PROJECT IS DEAD It was created in early 2017 when Mypy performance was often insufficient for in-editor linting. The Flake8 plu

Łukasz Langa 103 Jun 23, 2022
An open-source, mini imitation of GitHub Copilot for Emacs.

Second Mate An open-source, mini imitation of GitHub Copilot using EleutherAI GPT-Neo-2.7B (via Huggingface Model Hub) for Emacs. This is a much small

Sam Rawal 238 Dec 27, 2022
Tools for improving Python imports

imptools Tools for improving Python imports. Installation pip3 install imptools Overview Detailed docs import_path Import a module from any path on th

Danijar Hafner 7 Aug 7, 2022
A simple program which checks Python source files for errors

Pyflakes A simple program which checks Python source files for errors. Pyflakes analyzes programs and detects various errors. It works by parsing the

Python Code Quality Authority 1.2k Dec 30, 2022
Mypy stubs, i.e., type information, for numpy, pandas and matplotlib

Mypy type stubs for NumPy, pandas, and Matplotlib This is a PEP-561-compliant stub-only package which provides type information for matplotlib, numpy

Predictive Analytics Lab 194 Dec 19, 2022
Collection of library stubs for Python, with static types

typeshed About Typeshed contains external type annotations for the Python standard library and Python builtins, as well as third party packages as con

Python 3.3k Jan 2, 2023
PEP-484 stubs for Django

pep484 stubs for Django This package contains type stubs and a custom mypy plugin to provide more precise static types and type inference for Django f

TypedDjango 1.1k Dec 30, 2022
PEP-484 stubs for django-rest-framework

pep484 stubs for Django REST framework Mypy stubs for DRF 3.12.x. Supports Python 3.6, 3.7, 3.8 and 3.9. Installation pip install djangorestframework-

TypedDjango 303 Dec 27, 2022
Re-apply type annotations from .pyi stubs to your codebase.

retype Re-apply type annotations from .pyi stubs to your codebase. Usage Usage: retype [OPTIONS] [SRC]... Re-apply type annotations from .pyi stubs

Łukasz Langa 131 Nov 17, 2022
PEP-484 typing stubs for SQLAlchemy 1.4 and SQLAlchemy 2.0

SQLAlchemy 2 Stubs These are PEP-484 typing stubs for SQLAlchemy 1.4 and 2.0. They are released concurrently along with a Mypy extension which is desi

SQLAlchemy 139 Dec 30, 2022
Stubmaker is an easy-to-use tool for generating python stubs.

Stubmaker is an easy-to-use tool for generating python stubs. Requirements Stubmaker is to be run under Python 3.7.4+ No side effects during

Toloka 24 Aug 28, 2022
python package for generating typescript grpc-web stubs from protobuf files.

grpc-web-proto-compile NOTE: This package has been superseded by romnn/proto-compile, which provides the same functionality but offers a lot more flex

Roman Dahm 0 Sep 5, 2021
Pymxs, the 3DsMax bindings of Maxscript to Python doesn't come with any stubs

PyMXS Stubs generator What Pymxs, the 3DsMax bindings of Maxscript to Python doe

Frieder Erdmann 19 Dec 27, 2022
A plugin for flake8 integrating Mypy.

flake8-mypy NOTE: THIS PROJECT IS DEAD It was created in early 2017 when Mypy performance was often insufficient for in-editor linting. The Flake8 plu

Łukasz Langa 103 Jun 23, 2022
Mypy static type checker plugin for Pytest

pytest-mypy Mypy static type checker plugin for pytest Features Runs the mypy static type checker on your source files as part of your pytest test run

Dan Bader 218 Jan 3, 2023
A shim for the typeshed changes in mypy 0.900

types-all A shim for the typeshed changes in mypy 0.900 installation pip install types-all why --install-types is annoying, this installs all the thin

Anthony Sottile 28 Oct 20, 2022
A Fast API style support for Flask. Gives you MyPy types with the flexibility of flask

Flask-Fastx Flask-Fastx is a Fast API style support for Flask. It Gives you MyPy types with the flexibility of flask. Compatibility Flask-Fastx requir

Tactful.ai 18 Nov 26, 2022