On Mon, Jan 13, 2020 at 6:43 PM Chad Dombrova wrote:
> > I agree with focusing one mypy for now, but I would propose soon after,
>> or in parallel if it will be different folks, to work on pytype and enable
>> it as a first class citizen similar to mypy. If there will be a large delta
>> between
>
> > I agree with focusing one mypy for now, but I would propose soon after,
> or in parallel if it will be different folks, to work on pytype and enable
> it as a first class citizen similar to mypy. If there will be a large delta
> between the two then we can decide on what to do next.
>
> If
> The most important gain would be compatibility with Google internal code.
I would like to clarify this. This refers to users of Beam who by default
are using pytype as part of the toolchain. Even though they are internal to
a one single company and not vocal on Beam, they still represent a large
On Mon, Jan 13, 2020 at 5:34 PM Chad Dombrova wrote:
>>
>> Pytype seems to detect attribute errors that mypy has not, so it acts as a
>> kind-of linter in this case.
>> Examples:
>> https://github.com/apache/beam/pull/10528/files#diff-0cb34b4622b0b7d7256d28b1ee1d52fc
>>
>
> Pytype seems to detect attribute errors that mypy has not, so it acts as a
> kind-of linter in this case.
> Examples:
>
> https://github.com/apache/beam/pull/10528/files#diff-0cb34b4622b0b7d7256d28b1ee1d52fc
>
>
The most important gain would be compatibility with Google internal code.
TLDR: I don't expect non-Googlers to fix pytype issues in Beam, nor would
they have access to internal code that is validated against pytype with
Beam.
Pytype seems to detect attribute errors that mypy has not, so it acts
Udi, what would we gain by using pytype?
Also, has anyone tried running pytype against Beam? If it's not too much
trouble, it might be helpful to diff the pytype and mypy results to get a
feel for exactly how big the discrepancy is.
On Mon, Jan 13, 2020 at 3:26 PM Kenneth Knowles wrote:
>
Looking at this from the outside, it seems like mypy is the obvious choice.
Also running pytype could potentially be informative in some cases but only
if there is a specific gap. What about maintenance/governance of the two
projects?
Kenn
On Sun, Jan 12, 2020 at 7:48 PM Chad Dombrova wrote:
>
I would rather we focus on doing well with one type checker and it seems
that mypy is significantly more popular than pytype so its more natural for
users. I would support pytype if it covered more PEPs and was the newer and
upcoming thing but that doesn't seem to be the case.
On Sun, Jan 12,
Hi folks,
I agree with Robert that we need to wait and see before making any
decisions, but I do have some opinions about the probable/desired outcome.
I haven't used pytype, but my experience working with mypy over the past
few years -- and following various issues and peps related to it and
I am fine with adding this as a linter. I would not want to block either
(let alone both) until we have some experience with them. Hopefully, if our
code is clean and correctly typed, it should pass both. Where it doesn't,
I'm hopeful that the looseness provided by gradual typing will allow us to
Hi,
We recently added mypy to the Jenkins Lint job for PRs (currently ignores
errors). Mypy is a static type checker.
There's a JIRA for adding another static type checker named pytype
https://issues.apache.org/jira/browse/BEAM-9064
I wanted to ask the community their thoughts on this. (see JIRA
12 matches
Mail list logo
